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.
- Considera agregar una nueva función (Feature Hat)
- Examina el código existente para obtener comprensión, ordenando a medida que avanza. (Sombrero refactorizador)
- Cometer los cambios.
- 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.