Formato de código: ¿vale la pena hacer que un código malo se vea mal? [cerrado]

7

En Code 2nd Edition, Steve McConnell escribió lo siguiente (página 732):

  

Técnicas que hacen que un buen código se vea bien   y el mal código se ve mal son más útiles   técnicas que hacen que todo el código se vea bien.

Tengo una discusión sobre eso y reglas de formato de código de Eclipse con un colega. Dijo que el código de mala apariencia hace que la refactorización y la limpieza del código malo sean más difíciles, ya que necesita más esfuerzo para comprender el código. Por otro lado, he descubierto que el código que se ve mal es similar a una advertencia de "cuidado". Me recuerdo que debo pensarlo dos veces antes de modificar algo para asegurarme de que no romperé nada. Además, probablemente obliga a los desarrolladores a reestructurar su código para que sea un poco más hermoso y mejor estructurado.

Otra cosa es @SuppressFBWarnings anotaciones para falsas advertencias FindBugs positivas que también hacen que el código sea más difícil de mantener ya que estas anotaciones se ven mal, rompen la estructura del código y son difíciles de leer. Por otro lado creo que estos también ahorran tiempo. Cuando un desarrollador encuentra algún código que huele y FindBugs ya lo encontró, el desarrollador probablemente tiene una razón por la cual está bien (o porque alguien pensó que estaba bien) en el elemento justification de la anotación.

¿Hay otras razones por las que vale la pena o no hacer que un código malo se vea mal o es más bien una pregunta de psicología y ambos formatos son aceptables?

    
pregunta uqk 06.03.2015 - 11:24

4 respuestas

17

La cita de la misma página, el mismo párrafo, unas pocas oraciones antes:

  

Vale la pena hacer que el código se vea bonito, pero vale menos que mostrar la estructura del código. Si una técnica muestra mejor la estructura y otra se ve mejor, use la que muestre mejor la estructura. [...] En la práctica, priorizar la representación lógica generalmente no crea un código feo, a menos que la lógica del código sea fea.

El punto no es que debas formatear mal el código mal intencionalmente. El punto es que en un buen código, puede ver fácilmente la estructura, mientras que en un código incorrecto, encontrar cualquier estructura (si existe) es doloroso.

En este contexto, el formato es completamente superfluo . Puede pasar horas mejorando las convenciones de nomenclatura o agregando saltos de línea, pero el código incorrecto seguirá siendo malo porque, una vez más, de la falta de estructura.

En esencia, esta es la diferencia entre bonito y legible. El estilo hace que el código sea bonito, pero esto no significa que se pueda leer inmediatamente. Sólo la refactorización (relativamente importante y dolorosa) puede hacer frente a eso. Por otro lado, el código legible puede percibirse como feo debido a la falta de estilo, pero una herramienta básica puede recorrerlo y reformatearlo en cuestión de milisegundos.

    
respondido por el Arseni Mourzenko 06.03.2015 - 11:58
5

No solo el formato incorrecto hace que sea más difícil mejorar el código, sino que el formato incorrecto (o, lo más probable, desconocido) puede hacer que el código parezca lógicamente peor de lo que realmente es.

Una vez me encontré a mí mismo solucionando algo, estaba casi seguro de que era un error, solo para descubrir que no había ningún error, y me di cuenta de que tenía la impresión de que había un error porque el formato incorrecto de la El código me tentó a creer que estaba haciendo algo mal.

Entonces, en su mayor parte, no, no creo que sea una buena idea salir de tu camino intencionadamente para hacer que el código malo se vea mal o dejar que el código de mala apariencia se vea mal.

Estaría dispuesto a hacer una excepción en ciertos casos en los que se eligen identificadores feos para representar correctamente la fealdad de lo que hace el código. Por ejemplo, una y otra vez veo a los programadores escribir funciones de devolución de vacíos llamadas 'checkSomething ()' como si fueran las cositas inocentes más naturales del mundo. Por supuesto, estas funciones funcionan completamente por efecto secundario, por lo que son bastante malvadas. Cambiaría el nombre de esta función a 'checkSomethingAndDoThisIfSuchOrThatOtherwise ()' para indicar claramente que esta es una función maligna que posiblemente hace cosas malas.

    
respondido por el Mike Nakis 06.03.2015 - 12:50
5

Lo referiré a esta pregunta , ya que el sangrado correcto del código reveló al instante la fuente del error. También te referiré al estilo de codificación del kernel de Linux , que utiliza explícitamente las pestañas de 8 espacios como una forma de resaltar Anidación excesiva.

Este tipo de estándares de codificación no están diseñados para colocar una cinta de precaución permanente alrededor de las áreas defectuosas de su código. Tienen la intención de darle una patada visual en la cabeza para que el código mal estructurado nunca se envíe en primer lugar. Hacen que ciertos tipos de código sean más difíciles de leer intencionalmente, no como una especie de Castigo o advertencia permanente, pero así lo arreglará . Si tiene que desactivar temporalmente el formato para solucionarlo, que así sea, pero eso no es excusa para dejarlo deshabilitado para siempre.

  

Hay dos formas de escribir código: escribe código tan simple que hay   obviamente no hay errores en él, o escribir código tan complejo que no haya   errores obvios en él.
—Tony Hoare

El código de formateo es una manera fácil de hacer obvios ciertos tipos de errores, para que puedan eliminarse. No ayuda con todo tipo de errores, pero cualquier paso fácil que pueda tomar en esa dirección es bueno.

    
respondido por el Karl Bielefeldt 06.03.2015 - 14:04
3

Si está comenzando un proyecto de refactorización, y el código está mal formateado, debería primero reformatear mecánicamente todo el código base a algo sensible. Debe hacer ningún otro cambio en ese compromiso VCS.

Puede realizar ajustes manuales para la legibilidad local (inserción de líneas en blanco, alineación de signos de igual consecutivos, eliminación de comentarios sin sentido, etc.) más adelante, al refactorizar cada unidad lógica, pero el reformateo inicial debe ser 100% mecánico y aplicado al 100% del código.

Hay tres razones para esto:

  • No debe reformatear el código defectuoso pieza por pieza al mismo tiempo que lo refactoriza semánticamente, porque eso dificulta que los revisores de código entiendan cuáles fueron los cambios semánticos.

  • Será más fácil para usted entender el código lo suficientemente bien como para refactorizarlo, si está bien formateado cuando comienza.

  • Un parche mecánico de reformateo seguramente será grande y aburrido. Si es 100% mecánico, los revisores de código no tienen que leerlo en busca de cambios semánticos. También es seguro que toque casi todos los archivos, por lo que también puede hacer que todos los archivos, minimizando el número de veces que alguien tiene que reconstruir el mundo.

No importa el estilo de formato de código ejecutable mecánicamente que elija (excepto que nunca debe poner espacios en el interior de los paréntesis, porque eso hace llorar al bebé Jesús). La consistencia de dar formato a todo un proyecto es mucho más importante que cualquier estilo en particular. (La legibilidad local es aún más importante, pero no te preocupes por eso en esta etapa).

Finalmente, si el código es tan desordenado que reformatearlo mecánicamente el código lo rompe, debes aplicar las correcciones antes del parche de reformateo. Es decir, su historial de VCS debería terminar pareciéndose a

... --- [corrections so reformatting doesn't break the code] --- [reformatting] --- ...

tiempo avanzando hacia la derecha. Esto es por lo que cada revisión del código en el VCS no se rompe, pero el parche de reformateo sigue siendo 100% mecánico.

Si no tiene un VCS, un proceso de revisión de código, un conjunto de pruebas o una infraestructura de integración continua, obtenga esas cosas antes que intenta refactorizar el programa. En ese orden.

    
respondido por el zwol 06.03.2015 - 20:12

Lea otras preguntas en las etiquetas