it-swarm-es.com

¿Realmente escribes 'código limpio'?

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

OMI, '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?

57
ykombinator

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 respuesta del blog de Robert Martin :

Entonces. Se inteligente. Estar limpio Ser simple. ¡Embarcacion! Y tenga listo un pequeño rollo de cinta adhesiva para conductos, 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. Haz que funcione, usa cinta adhesiva y envíala. 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 a tiempo un producto con cinta adhesiva 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".

54
spong

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

Pero estás hablando de over styling (como ese término mejor que 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 , 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.

39
user2567

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 N horas adicionales de esfuerzo por parte del desarrollador inicial podrían 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 limpiar el código a una pulgada de su vida útil. Lleva tiempo, pero es probable que ahorre costos netos durante la vida del proyecto.

24
Benjamin Wootton

¿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.!

21
Sifar

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

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 tiempo y esfuerzo en el futuro.

18
GrandmasterB

Honestamente depende. Me gusta cómo todos dicen en voz alta 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 escribo mucho código 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 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 a la 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.

15
Satanicpuppy

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.

7
Heath Lilley

Intento escribir "código limpio" en el sentido de Bob Martin (p. Ej. OO). Hay un valor excelente al 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 bueno valor al 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 crees que es necesario alinear ordenadamente 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 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 poderoso sea mi editor y más hábil sea con él, más prettificación puedo hacer.

5
dss539

Parece que nadie plantea el punto de ¿cuál es el mejor interés de 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, digamos 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 cheque Niza cada mes? Elecciones, mi amigo. Si buscas el idealismo, prueba 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 un software, pero si lo necesita, simplemente escriba el código de trabajo, No importa la "limpieza". Simplemente no es una respuesta 'Una talla para todos', debe priorizar.

4
K.Steff

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 pueden sentirse menos inclinadas a hacer un buen trabajo con el mantenimiento y la evolución, causando 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.

3
Per Noalt

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.

3
Tulains Córdova

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 correctamente todo lo que desee.

3
back2dos

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 espaciado entre funciones, paréntesis en la misma línea o la siguiente línea de la instrucció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 :)

2
vedosity

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.

2
chiurox

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 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 extraño 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.

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

2
user20416

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

1
ElGringoGrande

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.

1
Kurtis

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.

1
JeffO

Creo que depende de lo que estés haciendo. Si estoy escribiendo una solicitud de prueba de concepto, entonces 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'.

1
user7007

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 pasarlo por alto cuando depures más tarde.

Además, en PHP tienes permitido cualquier número 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 una if (false) si desea omitirlo temporalmente.

0
Craige

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.

0
user281377