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

Argumentarí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.

Me recuerda la publicación del blog de Joel Spolsky: El programador de cintas de ductos .

Cita de Coders en el trabajo :

  

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

También me acuerdo de respuesta del blog de Robert Martin :

  

Entonces. Se inteligente. Se limpio Ser simple.   ¡Enviar! Y mantén un pequeño rollo de ducto.   cinta en la lista, y no tengas miedo   para usarlo. - tio bob

Si el código, un desarrollador escribe que está limpio Y funciona (es entregable), que así sea, bueno para todos. Pero si un desarrollador está intentando hacer un código limpio y legible a costa de poder entregarlo a tiempo, eso es malo. Haz que funcione, usa cinta adhesiva y mándalo. Puedes 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 a tiempo un producto con cinta adhesiva supera con creces los beneficios de un código limpio que nunca se terminó ni se entregó.

Una buena parte del código que he encontrado no está limpio. 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 un 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. Entonces, vuelve a limpiar ... eso es profesional. Con suerte, el código entregado no es pura cinta adhesiva 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 deben hacer todos los programadores .

Pero estás hablando de over styling (como ese término mejor que girl-code ) que no sirve más que al ego de su autor.

En el pasado, he visto a muchos desarrolladores tan orgullosos de su creación (ya saben, como en los baños;), que 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 , debe 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 estaría 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 usted mismo y los futuros desarrolladores puedan mantener lo más rentable posible.

He pasado periodos como ese programador o consultor de mantenimiento deficiente en el sitio que tiene que entender y depurar un gran sistema no documentado, y puedo decirle que los diseños deficientes y el código confuso pueden llevar a horas o incluso días de esfuerzo inútil. . Puedo pensar en muchas situaciones en las que N horas adicionales de esfuerzo por parte del desarrollador inicial podrían haber llevado a un ahorro de costos de 5N en términos de mi tiempo.

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

Por lo tanto, diría que limpie el código a una pulgada de su vida . Lleva tiempo, pero es probable que se ahorre en costos netos durante la vida del proyecto.

¿Alguno de nosotros compraría un automóvil si supiéramos que bajo el capó todo es complicado y difícil de solucionar, mantener o reparar y se necesitan más recursos para funcionar de lo que debería?

¿Por qué debería ser diferente para un 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, sí.!

Si con 'código limpio' quiere decir ¿me desvío de mi camino para asegurarme de que el código sea lo más claro posible?

Heck yes.

Cuanto más limpio, más claro es el código, más fácil es mantenerlo y, por lo tanto, le ahorra tiempo a largo plazo. No mires el código limpio como una vanidad; Considérelo como una inversión para ahorrar tiempo y esfuerzo en el futuro.

Honestamente depende. Me gusta la forma en que todo el mundo habla de la línea de la fiesta sobre cómo "¡cualquier cosa que no sea un código limpio y bien documentado es una simple farsa!", Pero trabajo en un negocio con ciclos de implementación ridículos y sin supervisión: hago lo mejor que puedo, pero escribo tan mucho código es extremadamente difícil escribir el código perfecto y limpio que todos los demás reclaman que escriben.

Intento escribir un código que pueda ser mantenido fácilmente por alguien que tiene aproximadamente mi capacidad. Comento las partes complicadas, nombro los programas, las variables y los nombres descriptivos de las clases, implemento y sigo adelante. No tengo tiempo para hacer nada más.

A veces me siento un poco culpable por eso, pero no mucho. 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 y despliega binarios con nombres crípticos en todo el lugar. La mujer que reemplacé programada exclusivamente en RPG .

Para mí es extremadamente difícil de creer, por más horrible que he 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 de mantenimiento. Cualquier cosa menos es poco profesional.

Como regla general, considero al siguiente desarrollador que tiene que ver mi desorden.

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

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

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

¡Si crees que es necesario alinear cuidadosamente grandes bloques de código para que sea legible, entonces el problema es tu enorme bloque de código! Es muy grande. Veo muchos ejemplos de personas que se esfuerzan mucho por pretender 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 gastar más del ~ 5% de mi tiempo de codificación en la prueba previa. Lo que significa que cuanto más poderoso sea mi editor y más competente sea con él, más prettificación puedo hacer.

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

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

Por ejemplo, supongamos que la compañía tiene una cláusula que estipula que si el software no está listo a tiempo, no le pagarán (solo nos pasó a nosotros, 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 posición financiera y necesita recaudar algo de dinero. Adivina a quién le importa la calidad? Puede arreglarlo más tarde, si tiene que hacerlo, ¡simplemente envíelo!

Un argumento podría ser "¿Por qué debería vender y escribir código de mierda?". Bueno, ¿por qué su compañía le paga un buen cheque cada mes? Elecciones, amigo mío. Si buscas el idealismo, prueba la Free Software Foundation ; Escuché que están haciendo cosas muy interesantes (me refiero a esta, y respeto a FSF y OSS).

En el otro lado de las cosas, 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 Cierto mantenimiento será el mayor costo para el proyecto.

A los programadores les encanta el código 'limpio', lo que sea que eso signifique. Ni siquiera podemos estar de acuerdo con lo que está limpio, pero nos encanta. Sin embargo, a veces simplemente no importa tanto como la facilidad de uso y la corrección. También pueden parecer, pero no lo son: si ha visto un código escrito por un verdadero hacker de Perl en 4 horas con la intención de usarlo dos veces y desecharlo, reconocería que no está limpio, pero funciona.

Así que a veces, aparte del ego, deberíamos hacerlo funcionar. Tenga en cuenta que no recomiendo escribir código malo como un hábito; Solo estoy señalando que podría ser necesario. La perfección requiere 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, sin importar la "limpieza". Simplemente no es una respuesta de "talla única", debes priorizar.

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

Intento escribir código, que es "elegante, perfectamente comprensible y fácil de mantener". Yo 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 sangran y espacian todo como desees.

Demasiado de nada 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 tiene un formato muy pobre, creo que muchas personas nuevas en la base de código podrían sentirse menos dispuestas a hacer un buen trabajo con el mantenimiento y la evolución, provocando una espiral descendente que podría afectar la condición 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 compañeros desarrolladores. No le dedique mucho tiempo (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 por lo que hace y siempre haga lo que crea que es más beneficioso para su empresa / clientes / usuarios.

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

  

Para llevar este punto a casa, ¿qué pasaría si fuera un médico y tuviera un paciente?   ¿Quién exigió que detengas todo el estúpido lavado de manos 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 absolutamente negarse a cumplir.   ¿Por qué? Porque el médico sabe más que el paciente sobre los riesgos de   Enfermedad e infección. Sería poco profesional (no importa   criminal) para que el médico cumpla con el paciente.

     

También es poco profesional para los programadores someterse a la voluntad de   gerentes que no entienden los riesgos de hacer un desastre.

Creo que el "código limpio" debería ser tan limpio o más limpio que la forma en que solías escribir en tus exámenes de física / ingeniería / matemáticas. Si está demasiado desordenado, el graduador 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 consistencia. Para mí eso significa coherencia con las convenciones de nomenclatura y espaciado entre funciones, paréntesis en la misma línea o en la línea siguiente de la declaración if, etc.

Por supuesto, hay veces en que alguien programa algo con un estilo de código consistente y todavía me vuelve loco. Especialmente el 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 de Objective-C, y con muchísimas frases if anidadas y líneas de más de 80 caracteres. Pero todavía me molesta :)

Voy a gran longitud para limpiar el código. Creo que ayuda mucho a los bichos a destacar.

No estoy de acuerdo con el concepto de "envía lo de mierda ahora", porque el código limpio es una inversión para el futuro. También muchos programas se envían con demasiados errores. Resolver un error en mi opinión es mejor que implementar una nueva función.

También si observa estimaciones de la productividad del programador , no creo que puntúe muy mal. Escribir código limpio es un hábito, y mientras más experiencia tenga como programador, más eficiente se vuelve uno. 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 se dedica a leer el código, por lo que el código legible reduce en gran medida los tiempos de lectura. Comprender algoritmos no documentados, por ejemplo, puede ser costoso e invitar a nuevos errores.

Una cosa que definitivamente echo de menos y 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ía 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 no materializarse nunca, pero creo que es un problema principalmente cuando empiezas, porque inviertes más tarde y cuando reutilizas tus propias piezas de código elegantes, combinadas con su experiencia, envejeciendo será muy productivo y mucho menos atormentado por errores que los programadores desordenados.

Esta es una pieza de código que demuestra mi estilo de codificación.

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

Escribo un 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 la convención de codificación.

Diría que me esfuerzo por escribir un código más limpio, pero eso puede cambiar debido a limitaciones de tiempo o si estoy trabajando en algo difícil. Tiende a ensuciarse cuando se enfoca en hacer que funcione. Luego regresaré y limpiaré mientras lo reviso. Si regresa al código y tiene que dedicar demasiado tiempo a actualizar su memoria, no lo comentó lo suficiente.

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

Creo que depende de lo que estés haciendo. Si estoy escribiendo una aplicación de prueba de concepto, entonces estoy básicamente codificado por cowboy y no estoy mirando hacia atrás. Si estoy trabajando en una aplicación en la que voy a estar trabajando por un tiempo, me aseguro de codificarlo 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 de los anteriores han dicho, su trabajo es hacer un producto, no un código formateado, pero yo diría que al menos uno debería seguir un estilo definido de comentar y codificar cosas. No me gustaría ver la mitad de las variables camel y la otra mitad húngara.

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

Admito que hago eso; y el beneficio es no molestarse 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 puedo soportar el código feo.

Refactorizar su código para hacerlo elegante hace que sea más fácil de leer y mantener. Incluso cosas menores como alinear sus asignaciones de 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 saltear cuando estás depurando más tarde.

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

// do x
{
    // ...
}

// do y
{
    // ...
}

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

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

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