coding style - psr - ¿Te preocupa la estética de tu código?
psr-2 español (19)
"Bonita" y "estética de código" son una especie de palabras proxy, esos términos suenan triviales, pero (al menos para mí) realmente significan "ideas expresadas de manera clara y lógica". Las ideas expresadas de forma clara y lógica.
No sé si soy la única persona en el mundo que tiene un mal presentimiento en mi estómago si mi código no es "bonito". Por ejemplo, si obtengo una tarea que otra persona ha estado haciendo antes que yo. No puedo evitarlo para limpiar el código y hacer que se vea "bonito". No sé si es algún tipo de TOC.
Es como que veo el código como un tipo de arte que ha sido perfecto en mi propia convención de código para que se vea bien. No sé si entiendes lo que estoy tratando de explicar aquí.
Pero, ¿eres como yo, intentando siempre hacer que mi código se vea bien en un punto de vista estético aunque no haga que el código sea mejor?
¿Así que eres el chico que está haciendo una completa pesadilla? ¿Deshacer todo el formato que es estéticamente agradable para mí, el escritor y mantenedor principal de ese código que acaba de ingresar?
Creo que Robert Martin lo describió mejor en su Book Clean Code: A Handbook of Agile Software Craftsmanship
No es suficiente escribir bien el código. El código debe mantenerse limpio con el tiempo. Todos hemos visto la descomposición y degradación del código a medida que pasa el tiempo. Por lo tanto, debemos tomar un papel activo en la prevención de esta degradación.
Los Boy Scouts of America tienen una regla simple que podemos aplicar a nuestra profesión.
Deja el campamento más limpio de lo que lo encontraste.
Si todos registramos nuestro código un poco más limpio que cuando lo comprobamos, el código simplemente no podría pudrirse. La limpieza no tiene que ser algo grande. Cambie un nombre de variable para mejor, divida una función que sea un poco demasiado grande, elimine un poco de duplicación, limpie una instrucción compuesta
if.¿Te imaginas trabajar en un proyecto donde el código simplemente mejoró con el tiempo? ¿Crees que alguna otra opción es profesional? De hecho, ¿no es la mejora continua una parte intrínseca del profesionalismo?
Dar formato al código es una forma (y posiblemente la mejor manera de hacerlo) para hacer que su código sea legible . La confrontación con el código legible facilita el paso a través de su programa (ya sea en un depurador o en la revisión del código). Lo mismo ocurre con los nombres de variables sensibles y el pensamiento sobre el alcance de la variable.
Sin embargo, si pasa todo su tiempo cambiando una notación perfectamente aceptable para campos, locales, punteros, etc. en una anotación Ancide muy personal, entonces me inclino a decir que eso no es realmente necesario.
Definir "estética". Creo que significa diferentes cosas para diferentes personas.
Lo más importante para mí sobre cualquier código que escribo (a pesar de los ejemplos de códigos apresurados publicados aquí) es que funciona según lo previsto. Una vez que funciona según lo previsto, entonces , y solo entonces, me preocupo por la estética.
La estética es subjetiva. Puedo gastar el trabajo para hacer de mi código una obra de arte en mis ojos, y alguien más puede venir detrás de mí y trabajar para cambiarlo para que se ajuste a su sentido de lo que constituye un "código hermoso". Después de todo, ¿incluye patrones de diseño, estándares de codificación, convenciones de nomenclatura y quién sabe qué más hay en eso? ¿O es una simple cuestión de sangría, alineación de llaves, alineación de tipo en la declaración de variables, etc.?
No hay dos desarrolladores que estén completamente de acuerdo con lo que constituye un código estéticamente agradable. Eso no quiere decir que no debas esforzarte por crearlo; pero no debe ser su prioridad número uno. Escribir código de trabajo y de mantenimiento debe ser su prioridad número uno. Si resulta ser estéticamente agradable como resultado de eso, que así sea.
El código ordenado es más fácil de mantener. Su cerebro es capaz de hacer increíbles combinaciones automáticas de patrones en el código, por lo que a menudo encontrará que detecta errores y problemas en el código simplemente porque es la "forma" incorrecta. Considero que la ordenación es tan importante que escribí un complemento de VS (AtomineerUtils) para agregar y formatear comentarios de documentos para minimizar el trabajo al que debo ir para mantener ordenado mi código.
Por supuesto, esa no es razón para reformatear el código de otra persona; solo molestará a otros programadores si cambia su código a su estilo por razones estéticas, sin mencionar que está invirtiendo mucho tiempo que podría incluirse en un nuevo código. y cada línea de código que cambie es otro error potencial que debe volver a probarse. Así que trata de dejar de ir "demasiado lejos".
Hago un buen uso del formateador de código incorporado en Visual Studio. En Delphi, incluso uso un complemento que me permite formatear mi código de Delphi. También trato de mantener cada archivo de origen por debajo de las 1000 líneas de código, aunque no estoy preocupado si algunos archivos se vuelven más largos. Utilizo nombres de variables descriptivos y ocasionalmente agrego algunos comentarios adicionales cuando sospecho que el código (y los nombres de los campos, las clases y los parámetros) no es lo suficientemente claro para el siguiente que lea mi código.
El resultado es muy gratificante ya que una vez tuve que mantener un fragmento de código que escribí 5 años antes. Su legibilidad hizo que mis propias piezas de código en el proyecto aún fueran muy legibles. Sin embargo, otros han sido más descuidados. Me dio un truco fácil para reconocer mi propio código de la basura que fue agregada por un semi-programador / administrador inexperto que solo era capaz de escribir macros en Word y Excel ...
No iría tan lejos como para hacer que las cosas se vean estéticamente bien solo por el valor estético, pero creo que es realmente importante escribir un código que sea legible y fácil de entender de un vistazo. Especialmente cuando escribes cosas como XML / HTML, cosas como el anidamiento y la sangría adecuados pueden hacer que sea más fácil tener una idea rápida de la estructura y permitirte pasar tu tiempo concentrándote en las áreas que te interesan. Un método breve y bien organizado que sea fácil de leer visualmente ahorrará tiempo y energía en comparación con algo que demora diez minutos en entenderse.
No me preocupa tanto si se ve bien como si se ve bien. Da la casualidad de que el código "más bonito" suele ser más fácil de leer y mantener.
No, dejé de intentarlo más. No puedes derrotar a un ejército de monos codificados.
Solo con mi proyecto personal aspiro a hacerlo perfecto.
Odio que mis colegas siempre escriban variables de una letra, métodos con nombres cortos que comienzan con guiones bajos y, por lo general, código feo . Parece ser la práctica estándar en torno a estas partes.
Siempre hago que mi código se vea bien. Es una representación visual de quién soy, por lo que tengo que mantenerlo limpio y ordenado, y correctamente sangrado.
Sí, estoy tratando descaradamente de adquirir el karma de con preguntas tontas.
Sí, me gusta hacer que el código se vea mejor, porque hace que sea más fácil de mantener y parece que la gente está preocupada por hacer un buen sistema.
Cuando el código parece feo, no te sientes motivado para mantenerlo fresco.
Y siento que estoy tan preocupado que creo que mis compañeros de trabajo me odian = P
Sí, me importa la estética del código ... El código que es estéticamente agradable es fácil de leer y, por lo tanto, fácil de entender.
Sí, tengo que tener el código sangrado con espacios y tabuladores de 4 espacios de ancho y, si es código C / C ++ / Java, coloque llaves en su propia línea, las macros de Emacs hacen el resto :-)
Sí. Y porque "no puedes [de hecho] luchar contra un ejército de monos" (si puedo tomar esto prestado de una respuesta), tiendo a hacer que esto sea menos doloroso y a automatizar lo que puede automatizarse, por ejemplo, realizar controles cosméticos durante la construcción. (que se romperá si es necesario). Otra opción sería formatear el código automáticamente en la confirmación, pero prefiero el primero.
Si te refieres a la identificación, creo que es esencial.
Si te refieres a legible (que para mí es diferente de estéticamente bonito), también es esencial.
Si quieres que lo que está escrito se vea como flores y pájaros volando, entonces no. No estoy preocupado :PAG
Yo también lo hago. Encuentro que hacer que el código se vea bien hace que sea más fácil de leer y entender.
Yo también me encuentro en tal posición. Como el código limpio es fácil de leer y mantener, siempre trato de limpiar y diseñar mi código.