¿Hay algún beneficio en la obsesión por hacer que el código "se vea bonito"?

A veces paso cantidades ridículas de tiempo (horas) agonizando por hacer que el código "se vea bonito". Me refiero a hacer que las cosas se vean simétricas. De hecho, me desplazaré rápidamente por toda una clase para ver si algo salta como que no se ve "bonita" o "limpia".

¿Estoy perdiendo el tiempo? ¿Hay algún valor en este tipo de comportamiento? A veces, la funcionalidad o el diseño del código ni siquiera cambiarán, simplemente lo reestructuraré para que se vea mejor.

¿Estoy siendo totalmente TOC o hay algún beneficio oculto en esto?

Use un formateador automático. Si realmente pasa tanto tiempo editando manualmente el código, estaría dispuesto a adivinar que no está muy desafiado / aburrido, porque no hay absolutamente ninguna razón para ello. Ctrl + K, Cntrl + D en VS formateará un documento completo. Puedes usar algo como Style Cop si quieres algo un poco más pesado.

Es bueno estar orgulloso de su código, pero no cuando se trata de ser inteligente (buscar la solución más eficiente. En este caso, usar una herramienta para automatizar un proceso tedioso) y hacer las cosas (¿qué más podría hacer? ¿Has trabajado durante esas horas?).

Si no está cambiando nada que permita que se entienda mejor, entonces sí, está perdiendo el tiempo.

Nada oculto, el código bonito es fácil de leer y fácil de mantener.

"Horas" parece un poco excesivo, a menos que tenga una gran base de código. No todo tiene que ser perfecto, solo tiene que ser bueno

Es una cuestión de juicio; si pasas horas, yo diría que estás exagerando. Sin embargo, hay cosas que un ser humano puede hacer que un formateador automático no puede hacer, y cosas que puede hacer para que su código sea más legible que son difíciles de capturar en los estándares de codificación corporativos.

Por ejemplo, cuando declaro variables en una clase, me gusta tener agrupaciones lógicas; hace que sea más fácil seguir la lógica.

El código generalmente se considera "escribir una vez, leer muchas", por lo que hacer que la experiencia de lectura sea agradable es un buen hábito, pero en mi opinión, el diseño es mucho menos problemático que las convenciones de nomenclatura claras, las abstracciones limpias y las firmas de métodos bien estructurados.

He visto código bellamente formateado que causó graves momentos WTF porque el proceso de pensamiento subyacente era defectuoso. Si tiene horas para gastar, lo gastaría en diseño y refactorización, en lugar de diseño ...

No, no estás siendo totalmente TOC. El mayor cumplido que he escuchado como programador fue: "Tu código está tan limpio que mi hermano pequeño podría resolverlo".

Algún día alguien tendrá que soportar tu código. El código limpio es mucho más fácil de soportar. Y algún día ese serás tú. En 6 meses o un año no recordarás lo que hiciste. Pero si es limpio y fácil de leer, volverá rápidamente.

Dicho esto, si el código es basura, no ayuda ser una basura bonita. Pero si está bien estructurado y solo tiene problemas de funcionalidad, será mucho más fácil mejorar la funcionalidad.

No, estar obsesionado con hacer que el código se vea bonito es perder el punto .

Aquí hay algunas piezas de sabiduría que encontré útiles:

Pregunte por qué el código debe ser ordenado.

Puede o no estar perdiendo el tiempo dependiendo de su definición de bonita.

El teorema fundamental del formato dice que un buen diseño visual muestra la estructura lógica del programa. Hacer que el código se vea bonito vale algo, pero vale menos que mostrar la estructura del código. [pág. 732, Código completo 2ª edición, Steve McConnell]

Si utiliza el sistema de versiones simultáneas para realizar un seguimiento de los cambios en el código, no mezcle los cambios de formato del código con los cambios de funciones lógicas / de adición dentro del mismo compromiso.

Hará que los cambios sean más difíciles de detectar y provocará conflictos de fusión innecesarios si otros miembros del equipo están editando el archivo. Si debe realizar cambios de formato, verifique que otros miembros del equipo no estén trabajando en ese archivo. [Parafraseado, Pg 93, Control de versión pragmático usando Subversion, 2da edición]

También Martin Fowler habla sobre 'usar dos sombreros' y cambiar entre ellos durante todo el día. Un sombrero para agregar características, un sombrero para refactorizar.

1. Considera agregar una nueva función (Feature Hat)
2. Examina el código existente para obtener comprensión, ordenando a medida que avanza. (Sombrero refactorizador)
3. Cometer los cambios.
4. Agrega la función. (Feature Hat) y así sucesivamente ...

[Parafraseado pg 57ish, refactorización, Martin Fowler]

Por lo tanto, no pase horas tratando de embellecer todo el código base. Simplemente agregue el código suficiente que necesita para agregar la siguiente función.

En resumen ... deje cada código en un estado más agradable que cuando llegó por primera vez.

Si es puramente formateado, probablemente sea mejor invertir algo de tiempo en enseñarle a una impresora bonita cómo quiere que se formatee su código. Eso es algo costoso por adelantado, pero imagino que recuperarás ese temporizador en 2-3 usos.

Si se trata de una refactorización real, posiblemente no. Conceptualmente, el código limpio tiende a ser más fácil de modificar en el futuro y tener "siempre limpio" disminuye la tentación de dejar pasar algo solo porque hay otro código maloliente.

Ayuda un poco, pero no vale la pena dedicarle mucho tiempo. También asegúrese de que sus mejoras también agreguen alcance variable, RAII, copia de grupo / código pegado, etc. Si hace todo eso, se vuelve 1000 veces más fácil cuando tiene que entender qué hace el código después de un año más o menos.

Debería producir un código limpio, pero no debería llevar horas.

Para C, está el programa gnu gnu-indent gnu-indent , en eclipse, hay al menos un formateador de código para Java, y creo que también hay herramientas para la mayoría de los otros lenguajes. Debería hacer unos pocos clics para sangrar un archivo correctamente, y unos minutos, si desea violar las reglas para propósitos específicos, como lo hago para breves declaraciones de cambio de caso:

 switch (foo) {
      case a:  foo (a);             break; 
      case b:  foob ();             break;
      case c:  /* intent. empty */
      case d:  foocd ();            break; 
      default: allPrettyAligned (); break; 
 }

lo cual es difícil de especificar

Si crees que algo se ve limpio al rozarlo, te estás concentrando en algo superficial que se puede automatizar.

Lea este artículo clásico sobre "Hacer que el código incorrecto se vea mal" y verá exactamente por qué las personas comúnmente piensan que la sangría (que se puede hacer automáticamente) es trivial:

http://www.joelonsoftware.com/articles/Wrong.html

Particularmente esta lista:

Bien, hasta ahora he mencionado tres niveles de logro como programador:

1) No sabes limpio de inmundo.

2) Tiene una idea superficial de limpieza, principalmente en el nivel de conformidad con las convenciones de codificación.

3) Empiezas a oler sutiles indicios de impureza debajo de la superficie y te molestan lo suficiente como para acercarte y arreglar el código.

Sin embargo, hay un nivel aún más alto, que es de lo que realmente quiero hablar:

4) Usted deliberadamente diseña su código de tal manera que su olfato para la impureza haga que su código sea más correcto.

Este es el verdadero arte: crear un código robusto inventando literalmente convenciones que hacen que los errores se destaquen en la pantalla.

"Horas"? Bueno, yo diría que su respuesta es "y", no "o": sí, usted está siendo TOC, pero tiene algún beneficio.

Probablemente.

¿Hace que su código sea más fácil de leer rápidamente? ¿Hace que sea más fácil hojear, descubrir qué se detiene y dónde comienza, encontrar funciones, variables, etc.? ¿Hace la forma en que su código funciona más claro? ¿El proceso de embellecimiento lo obliga a revisar algunas decisiones de diseño y a podar el código muerto o eliminar soluciones a medias que finalmente abandonó? Si es así, tiene absolutamente valor.

Por otro lado, si ha descubierto alguna forma perversa de apelar a su propio sentido de la estética sin hacer que su código sea más fácil de trabajar, entonces sí, es una gran pérdida de tiempo.

En cuanto a mí, tiendo a caer en el extremo del TOC, pero no voy a parar. El acto de proporcionar documentación para una clase o función me obliga a pensar en cómo funciona realmente la cosa: lo estoy escribiendo para que alguien que no sea yo pueda entenderlo, después de todo. Y si me encuentro lanzando un montón de advertencias y advertencias y disculpas por qué el código funciona de la manera en que funciona, esa es una advertencia bastante fuerte que necesita una ronda más de ajustes antes de declararlo terminado.

Primero, nada de malo en hacer que su código se vea bonito porque eventualmente desea estar orgulloso de su creación y la presentación / formateo del código es parte de eso.

Sin embargo, tendría cuidado de no formatear demasiado su código por el bien de sus compañeros de trabajo o futuros desarrolladores. Bonito para ti, puede que no lo sea para mí. :)

Reconoce el problema (comportamiento compulsivo) y el síntoma (formateo obsesivo).

¿Qué pasa con la causa y la cura?

• ¿Estás trabajando demasiadas horas?
• ¿Estás frustrado, aburrido, ansioso?
• ¿Cuál es tu próxima tarea? ¿Es algo que no quieres hacer?
• ¿Cuándo fue la última vez que tuvo vacaciones? ¿Promoción? ¿Reconocimiento por un logro?
• ¿Es un problema relacionado con el agotamiento?
• ¿Estás en una Marcha de la Muerte?

A veces, estos síntomas son una señal de que es hora de hacer cambios audaces o seguir adelante.

A pesar de su título desalentador, el libro de Yourdon tiene muchas sugerencias útiles y para muchas organizaciones, está haciendo una descripción bastante real.

http://dev.co.ua/docs/Edward%20Yourdon%20-%20Death%20March.pdf

Pareces bastante perspicaz y creo que puedes saber la respuesta.

Ahora, date permiso para actuar en consecuencia.

Holy Bovine!
¿Ustedes nunca han oído hablar de sangría?

Es una utilidad de formateo de código que existe desde hace más de 20 años. Tiene una gran cantidad de opciones para que su código pueda formatearse de la forma que lo desee, automáticamente.

ermm, pero solo funciona en C y algunos, pero no todos, C ++ ... (wtf? ¿por qué GNU no lo actualiza?)