¿Realmente escribes 'código limpio'? [cerrado]

He visto a algunos programadores ajustar su código una y otra vez no solo para que funcione bien, sino también para que se vea bien.

En mi opinión, el "código limpio" es en realidad un cumplido que indica que su código es elegante, perfectamente comprensible y fácil de mantener. Y la diferencia surge cuando tienes que elegir entre un código estéticamente atractivo frente a un código estresante de ver.

Entonces, ¿cuántos de ustedes realmente escriben 'código limpio'? ¿Es una buena práctica? ¿Cuáles son los otros beneficios o inconvenientes de esto?

Yo diría que muchos de nosotros no escribimos código limpio . Y en general, ese no es nuestro trabajo . Nuestro trabajo como desarrolladores de software es entregar un producto que funcione a tiempo.

Recuerdo la publicación del blog de Joel Spolsky: The Duct Tape Programmer .

Cita de codificadores en el trabajo :

Al final del día, ¡envía la maldita cosa! Es genial reescribir su código y hacerlo más limpio y, por tercera vez, en realidad será bonito. Pero ese no es el punto: no estás aquí para escribir código; Estás aquí para enviar productos. - Jamie Zawinsky

También recuerdo la respuesta del blog de Robert Martin :

Entonces. Se inteligente. Estar limpio Ser simple. ¡Embarcacion! Y tenga listo un pequeño rollo de cinta adhesiva, y no tenga miedo de usarlo. - Tío Bob

Si el código, un desarrollador escribe pasa a ser limpio Y funciona (es entregable), que así sea, bueno para todos. Pero si un desarrollador está tratando de crear un código limpio y legible a expensas de poder entregarlo a tiempo, entonces eso es malo. Haga que funcione, use cinta adhesiva y envíela. Puede refactorizarlo más tarde y hacerlo súper hermoso y eficiente.

Sí, es una buena práctica escribir código limpio, pero nunca a expensas de poder entregar. El beneficio de entregar un producto con cinta adhesiva a tiempo supera con creces los beneficios del código limpio que nunca se terminó y entregó.

Una buena parte del código que he encontrado no está limpia. Algunos son francamente feos. Pero todos fueron lanzados y utilizados en la producción. Algunos pueden decir que no es profesional escribir código desordenado. Estoy en desacuerdo. Lo profesional es entregar código que funcione, ya sea limpio o desordenado. El desarrollador debe hacer lo mejor que pueda, dado el tiempo asignado antes de la entrega. Luego, vuelve a limpiar, eso es profesional. Con suerte, el código entregado no es cinta adhesiva pura y es "lo suficientemente limpio".

Debe asegurarse de que su código sea muy legible, limpio y fácil de mantener. Eso es lo que todos los programadores deben hacer.

Pero usted está hablando over styling(como ese término mejor que el código de niña ) que no sirve más que el ego de su autor.

He visto a muchos desarrolladores en el pasado tan orgullosos de su creación (ya sabes, como en los baños;)), pasaron horas limpiando y puliendo su código. Algunos de ellos fueron tan meticulosos que se aseguraron de que se respetaran los espacios en blanco correctos entre los miembros.

Es demasiado.

Encuentro ese tipo de comportamiento contraproducente. En un contexto profesional , debes ser profesional . Puede obtener su satisfacción escribiendo un código limpio, muy legible y fácil de mantener y hablando con usuarios o colegas felices.

No estoy de acuerdo con la respuesta aceptada sobre esta pregunta.

Obviamente, su responsabilidad es enviar, pero generalmente también tiene la responsabilidad de enviar algo que pueda mantener de la manera más rentable posible para usted y los futuros desarrolladores.

He pasado períodos como ese pobre programador de mantenimiento o consultor en el sitio que tiene que comprender y depurar un gran sistema indocumentado, y puedo decirle que los diseños deficientes y el código confuso y desordenado pueden generar horas o incluso días de esfuerzo desperdiciado. Puedo pensar en muchas situaciones en las que un esfuerzo adicional de N horas por parte del desarrollador inicial podría haber llevado a un ahorro de 5N en términos de mi tiempo.

Sé que hay una estadística flotando sobre esto, pero en mi experiencia en múltiples proyectos, cada línea de código que se escribe se lee 5-20 veces durante la extensión y el mantenimiento.

Entonces diría que limpie el código a una pulgada de su vida útil . Lleva tiempo, pero es probable que ahorre costos netos durante la vida del proyecto.

¿Alguno de nosotros compraría un automóvil si supiéramos que debajo del capó todo es desordenado y difícil de solucionar, mantener o arreglar y requiere más recursos para funcionar de lo que debería?

¿Por qué debería ser diferente para una pieza de software?

El hecho de que los usuarios finales no puedan mirar debajo del capó no significa que nunca lo sabrán. Tarde o temprano aparecerá.

Respondiendo a la pregunta "¿Realmente escribes 'código limpio'?" -- Oh si.!

Si por "código limpio" quieres decir, ¿hago todo lo posible para asegurarme de que el código sea lo más claro posible?

Diablos si.

Cuanto más limpio, más claro sea el código, más fácil será mantenerlo y, por lo tanto, le ahorrará tiempo a largo plazo. No mire el código limpio como vanidad; Míralo como una inversión para ahorrar esfuerzo y tiempo en el futuro.

Honestamente depende. Me gusta cómo todos dicen en voz alta sobre cómo "¡nada menos que limpiar un código bien documentado es una pura parodia!", Pero trabajo en un negocio con ciclos de implementación ridículos y cero supervisión: hago lo mejor que puedo, pero lo escribo Para muchos códigos es extremadamente difícil escribir el código limpio perfecto que todos los demás afirman que escriben.

Intento escribir código que pueda ser mantenido fácilmente por alguien que tenga aproximadamente mi capacidad. Comento las partes difíciles, nombro los nombres amigables de los programas, variables y clases, despliego y sigo adelante. No tengo tiempo para hacer otra cosa.

A veces me siento un poco culpable por eso, pero no muy. Deberías ver algunos de los horrores con los que trato a diario. Décadas de código personalizado en idiomas oscuros con cero documentación. Uno de mis compañeros de trabajo se desarrolla exclusivamente en Visual Basic 6.0 e implementa binarios con nombres crípticos en todo el lugar. La mujer que reemplacé programó exclusivamente en RPG .

Es extremadamente difícil para mí creer, por más horrible que haya visto en mis años como programador, que todos solo generan código limpio.

No creo que me guste el término "código de niña" pero código limpio = código mantenible. Cualquier cosa menos no es profesional.

Como regla general, considero el próximo desarrollador que tiene que mirar mi desorden.

Muchas veces soy yo ... varios meses después ... cuando no recuerdo cómo funciona ... y tengo aún menos tiempo para hacer un cambio.

Intento escribir "código limpio" en el sentido de Bob Martin (por ejemplo, diseño OO). Hay un gran valor en escribir código limpio. Es mucho más fácil de mantener.

Luego dejo que ReSharper lo convierta en un "código bonito" para mí (por ejemplo, alineación, saltos de línea, etc.). Hay un buen valor en escribir código bonito. Pero hay rendimientos decrecientes. Algunas prettificaciones lo hacen un poco más fácil de mantener debido a la facilidad de lectura.

Si cree que es necesario alinear bloques de código enormes para que sea legible, ¡entonces el problema es su enorme bloque de código! Es muy grande. Veo muchos ejemplos de personas que se esfuerzan mucho para embellecer un código muy mal diseñado.

Si no tuviera ReSharper, todavía tendría un código limpio, pero no sería tan bonito.

No creo que deba dedicar más del ~ 5% de mi tiempo de codificación a la prettificación. Lo que significa que cuanto más potente sea mi editor y más hábil sea con él, más prettificación puedo hacer.

Parece que nadie plantea el punto de lo que es mejor para su empresa?

A menudo, si no siempre, los programadores son solo empleados, y aunque las decisiones de gestión pueden frustrarnos, a menudo no tenemos todos los datos que tienen.

Por ejemplo, supongamos que la compañía tiene un contrato con una cláusula que dice que si el software no está listo a tiempo, no se le pagará (simplemente nos sucedió, aunque creo que obtuvimos el pago después de todo). Sí, el código limpio es importante, ¡pero lo más importante es que el código funcione antes del día de pago!

Otro ejemplo: la compañía está en una mala situación financiera y necesita recaudar algo de dinero. ¿Adivina a quién le importa la calidad? Puede arreglarlo más tarde, si es necesario, ¡simplemente envíelo!

Un argumento podría ser "¿Por qué debería vender y escribir código malo?". Bueno, ¿por qué su empresa debería pagarle un buen cheque cada mes? Elecciones, mi amigo. Si buscas el idealismo, prueba la Free Software Foundation ; Escuché que están haciendo algunas cosas geniales (me refiero a esta, y respeto FSF y OSS).

Por otro lado, si trabaja en un proyecto donde se espera un crecimiento explosivo en el uso (aunque tales proyecciones casi nunca son precisas), es mejor que establezca una base sólida con la mejor calidad de código requerida, ya que es casi seguro que el mantenimiento Ser el mayor costo para el proyecto.

Los programadores aman el código 'limpio', sea lo que sea que eso signifique. Ni siquiera podemos ponernos de acuerdo sobre lo que está limpio, pero nos encanta. Sin embargo, a veces simplemente no importa tanto como la usabilidad y la corrección. Estos pueden parecer sinónimos, pero no lo son: si ha visto código escrito por un verdadero pirata informático de Perl en 4 horas con la intención de usarse dos veces y desecharse, reconocerá que no está limpio, pero funciona.

Entonces, a veces, dejando de lado el ego, deberíamos hacerlo funcionar. Tenga en cuenta que no recomiendo escribir código incorrecto como un hábito; Solo estoy señalando que podría ser necesario. La perfección lleva tiempo que su empresa podría no tener. Entonces, si a su empleador no le importa, cree software, pero si lo necesita, simplemente escriba el código de trabajo, no importa la 'limpieza'. Simplemente no es una respuesta de 'talla única': debe priorizar.

No estoy seguro de que "verse bien" y ser "elegante, perfectamente comprensible y sostenible" sea equivalente.

Intento escribir código, que es "elegante, perfectamente comprensible y fácil de mantener". Refactorizo ​​mi propio código para que coincida mejor con esos criterios.

No veo ningún inconveniente, excepto el costo resultante en el tiempo.

Para que el código "se vea bien", hay muchas herramientas automatizadas, que sangrarán y espaciarán adecuadamente todo lo que desee.

Demasiado de algo nunca es bueno.

Sin embargo, una cosa importante a tener en cuenta con el código "impuro" es que puede conducir fácilmente a " ventanas rotas ". Si el código está muy mal formateado, creo que muchas personas nuevas en la base del código podrían sentirse menos inclinadas a hacer un buen trabajo con el mantenimiento y la evolución, lo que provocaría una espiral descendente que podría afectar las condiciones de funcionamiento del software.

Por lo tanto, mantener un cierto nivel de limpieza en el código es beneficioso para algo más que sus colegas desarrolladores. No gaste demasiado tiempo en ello (se ha mencionado ~ 5%). Aprenda a usar las herramientas de su oficio para automatizar tareas manuales (formato de código en este caso). Asuma la responsabilidad de lo que hace y siempre haga lo que considere más beneficioso para su empresa / clientes / usuarios.

Esta es una cita de Clean Code, de Bob Martin:

Para llevar este punto a casa, ¿qué pasaría si fuera un médico y tuviera un paciente que le exigiera que dejara de lavarse las manos tontamente en preparación para la cirugía porque estaba tomando demasiado tiempo? Claramente el paciente es el jefe; y, sin embargo, el médico debe negarse absolutamente a cumplir. ¿Por qué? Porque el médico sabe más que el paciente sobre los riesgos de enfermedades e infecciones. Sería poco profesional (no importa lo criminal) que el médico cumpla con el paciente.

Por lo tanto, tampoco es profesional que los programadores se dobleguen a la voluntad de los gerentes que no entienden los riesgos de causar problemas.

Creo que el "código limpio" debería ser tan limpio o más limpio que como solía escribir en sus exámenes de física / ingeniería / matemáticas. Si es demasiado desordenado, el calificador no entenderá su trabajo y probablemente lo marcará mal incluso si es correcto.

Me gusta que el código sea legible, pero lo más importante es la coherencia. Para mí eso significa coherencia con las convenciones de nomenclatura y el espaciado entre funciones, paréntesis en la misma línea o la siguiente línea de la declaración if, etc.

Por supuesto, hay momentos en que alguien programa algo con un estilo de código consistente y todavía me vuelve loco. Especialmente código que no "respira". Por ejemplo:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Bueno ... Se ve peor con los métodos Objective-C, y con montones de sentencias if anidadas, y líneas mucho más largas que 80 caracteres. Pero todavía me molesta :)

Hago un gran esfuerzo para limpiar el código. Creo que ayuda mucho a que los errores se destaquen.

No estoy de acuerdo con el concepto de "enviar la maldita cosa ahora", porque el código limpio es una inversión para el futuro. También se envía demasiado software con demasiados errores. Resolver un error en mi opinión es mejor que implementar una nueva característica.

Además, si observa las estimaciones de la productividad del programador , no creo que obtenga una puntuación muy mala. Escribir código limpio es un hábito, y cuanto más experiencia como programador, más eficiente se vuelve. Si uno nunca lo intenta, obviamente, nunca obtendrá experiencia con él.

Otro punto a tener en cuenta es que la mayor parte del tiempo del desarrollador va a leer el código, por lo que el código legible reduce en gran medida el tiempo dedicado a la lectura. Comprender los algoritmos no documentados, por ejemplo, puede ser costoso e invitar a nuevos errores.

Una cosa que definitivamente echo de menos y que me gustaría tener algún día es un formateador de código automático que pueda adaptar a mi estilo, que realmente me ahorrará algo de tiempo, especialmente al leer el código de otras personas.

La codificación limpia tiene un vínculo con el perfeccionismo, que tiene el riesgo de nunca materializarse, pero creo que eso es principalmente un problema cuando comienzas, porque inviertes más tarde y cuando reutilizas tus propios códigos elegantes, combinados con tu experiencia , envejeciendo serás muy productivo y mucho menos perseguido por los errores que los codificadores desordenados.

Este es un fragmento de código que demuestra mi estilo de codificación.

Solo evite el "código de vanidad". Hay muchos desarrolladores que hacen cosas por pura vanidad (o debido a un TOC) y nada más. Mis bragas realmente se tuercen con esas personas.

Escribo código que intenta resolver el problema dado de la manera más eficiente y teóricamente 'elegante'. En ese sentido solo está limpio. Si resulta que es "bonito" cuando termine, que así sea.

Lo que he encontrado en mis experiencias limitadas es que cuando las personas se quejan de 'código limpio', la fealdad suele ser el resultado de una solución terrible en lugar de una convención de codificación.

Diría que hago un esfuerzo para escribir código más limpio, pero eso puede cambiar debido a limitaciones de tiempo o si estoy trabajando en algo difícil. Tiende a complicarse cuando se enfoca en hacer que funcione. Luego volveré y limpiaré mientras lo reviso. Si vuelve al código y tiene que pasar demasiado tiempo refrescando su memoria, no lo comentó lo suficiente.

El código limpio es bueno, pero como todo lo demás, solo necesita estar lo suficientemente limpio. Sangrar 5 líneas de código 4 espacios y una línea 5 espacios no aumenta la dificultad de lectura.

Creo que depende de lo que estés haciendo. Si estoy escribiendo una solicitud de prueba de concepto, básicamente estoy codificando a mi vaquero y no mirando hacia atrás. Si estoy trabajando en una aplicación en la que voy a estar trabajando durante un tiempo, entonces me aseguro de codificarla lo suficientemente bien como para que sea comprensible dentro de un mes.

Creo que diseñar tu código es un poco dudoso. Como algunos han dicho anteriormente, su trabajo es hacer un producto, no un código formateado, pero yo diría que al menos uno debe seguir con un estilo definido de comentar y codificar cosas. Odiaría ver la mitad de las variables en camello y la otra mitad húngara.

Pero también, depende de lo que quiera decir con 'código limpio'.

Admito haber hecho eso; y el beneficio no se molesta cada vez que lo veo. Supongo que también es más fácil de leer y, por lo tanto, los errores se vuelven más obvios; pero la verdadera razón es que no soporto el código feo.

Refactorizar su código para que sea elegante hace que sea más fácil de leer y más fácil de mantener. Incluso cosas menores como alinear sus asignaciones variables:

int foo    = 1;
int bar    = 2;
int foobar = 3;

es más fácil de leer que

int foo = 1;
int bar = 2;
int foobar = 3;

lo que significa que es más fácil pasar por alto cuando estás depurando más tarde.

Además, en PHP se le permite cualquier cantidad de bloques de código aleatorio. Los uso para agrupar tareas lógicas:

// do x
{
    // ...
}

// do y
{
    // ...
}

Esto agrega una definición clara al código relevante.

Editar : como una ventaja adicional, es fácil preceder a uno de esos bloques de código lógico con un if (false)si desea omitirlo temporalmente.

Solo escribo mi código, siguiendo los estándares de la compañía. Si lo quiero "embellecido", puedo ejecutarlo a través de un embellecedor de código.