¿Por qué el tío Bob sugiere que los estándares de codificación no deberían escribirse si puedes evitarlo?

145

Mientras leía esta pregunta , la respuesta más votada citaba al tío Bob sobre los estándares de codificación , pero este consejo me confundió:

  1. No los escriba si puede evitarlo. Más bien, deje que el código sea la forma en que se capturan los estándares.

Esto rebotó en mi cerebro, pero no pude encontrar un lugar donde quedarme. Si una nueva persona se une al equipo, o los estándares de codificación cambian, ¿no podría haber confusión de información?

¿Por qué no debería escribir un estándar de codificación?

development-process coding-standards Legal perezoso
fuente
47
Hmm Estoy tratando de imaginar cómo funcionaría esto en una gran empresa multinacional con cientos de desarrolladores y una base de código que abarca décadas.
Matthew James Briggs
31
@MatthewJamesBriggs: funciona tan bien como un estándar escrito que la mayoría de los desarrolladores ignoran, o que tenían un contenido diferente en el momento en que el código se escribió inicialmente.
Doc Brown
77
@MatthewJamesBriggs: de acuerdo. La guía de estilo debe contener suficiente información para reconocer las convenciones anteriores que ahora están en desuso, de lo contrario la cultura de "copiar el estilo existente" encontrará un horror de 10 años para resucitar. Además, cuando se forman camarillas accidentalmente que usan muestras diferentes e incompatibles para deducir el estilo oficial, la guía de estilo escrita dice cuál de ellas es la correcta (o idealmente, evita que la camarilla se forme en primer lugar). Y si algunos de tus cientos de desarrolladores no leen documentos, en una gran empresa puedes despedirlos por muppetry.
Steve Jessop
14
Aunque para ser justos, Bob también dijo que, en primer lugar, no debería tener un estándar de codificación para toda la empresa, escrito o no escrito. Más bien, cada equipo / camarilla debe desarrollar el suyo.
Steve Jessop
37
En lugar de escribir un documento que nadie leerá, use un linter que imponga el código de cierta manera. Si es parte de su proceso de desarrollo, es inevitable.
Seiyria

Respuestas:

256

Hay unas pocas razones.

  1. Nadie lee la documentación.
  2. Nadie sigue la documentación, incluso si la leen.
  3. Nadie actualiza la documentación, incluso si la leen y la siguen.
  4. Escribir una lista de prácticas es mucho menos efectivo que crear una cultura.

Los estándares de codificación no se refieren a lo que las personas deberían hacer, sino a lo que realmente hacen. Cuando las personas se desvían de los estándares, esto debería ser recogido y cambiado a través de un proceso de revisión de código y / o herramientas automatizadas.

Recuerde, el objetivo de los estándares de codificación es hacernos la vida más fácil. Son un atajo para nuestro cerebro para que podamos filtrar las cosas necesarias de las cosas importantes. Es mucho mejor crear una cultura de revisión para hacer cumplir esto que formalizarlo en un documento.

Stephen
fuente
11
Y si desea hacer cumplir las cosas, debe tener un paso del proceso de compilación que lo haga cumplir, no una guía de estilo que lo haga.
Wayne Werner
31
¿Realmente no tiene un documento estándar, pero solo grita a las personas durante las primeras semanas en cada revisión de código? Parece que básicamente esperarías que los principiantes realicen ingeniería inversa en tus guías de estilo de codificación. ¿O es más un hipotético "Creo que eso es lo que quiso decir"? Ahora bien, si se trata de herramientas automáticas que hacen cumplir esas reglas, de acuerdo, eso es esencial. Pero no quiero tener que resolver laboriosamente las reglas.
Voo
13
@Voo, ¿por qué siente que necesita gritar durante una revisión de código si surge un problema?
Jaap
20
@Jaap Pensé que la hipérbole era obvia ... aparentemente no. No, no gritar a las personas, sino decirles que tienen que regresar y arreglar todas las cosas que violaron porque no podían saberlo mejor.
Voo
55
@Voo: no necesita “realizar ingeniería inversa de las guías de estilo de codificación”. Las convenciones deben ser evidentes cuando se mira el código existente. Todo lo que no salta inmediatamente al ojo es, poco común o ni siquiera está arreglado. En caso de que haya reglas realmente importantes sobre algo que rara vez ocurre, puede valer la pena discutirlo con los nuevos desarrolladores, cuando son ellos quienes tienen que escribir dicho código. La comunicación no puede ser sobreestimada.
Holger
112

Hay otra interpretación. No creo que sea lo que quería decir tío Bob, pero vale la pena considerarlo.

No capture estándares de codificación en un documento. Captúrelo en código al tener un proceso automatizado que verifique que se cumplen los estándares .

No confíe en que las personas hagan referencia a un documento, pero al mismo tiempo, no confíe en que las personas interpreten el código que ya existe e identifiquen qué es una convención y qué es una coincidencia.

Incorpora algo como Checkstyle en tu build de commit. Esto puede hacer cumplir las reglas básicas como los estándares de formato y nomenclatura, y luego, en lugar de gastar esfuerzo mental al considerar el estilo, todo eso puede descargarse en un proceso tonto que al menos se garantiza que sea exhaustivo.

Si es importante, defina estrictamente qué es lo que desea y falle si está mal.

Tom Johnson
fuente
66
En realidad, sospecho que algo así fue al menos parte del razonamiento del tío Bob para la sugerencia. La automatización de los estándares de codificación va junto con las pruebas automatizadas como una forma útil de mejorar la calidad, y estoy seguro de que Bob lo sabe ...
Julio
10
Puede valer la pena mencionar la regla n. ° 6: After the first few iterations, get the team together to decide.con solo la regla n. ° 3 parece que no defiende ningún estándar de codificación, pero al considerar todas las reglas juntas y, sobre todo, el n. ° 6, parece que realmente está diciendo: "No forzar un estándar de codificación al principio. Dejar que se desarrolle orgánicamente y, después de un tiempo, sentarse con su equipo para resolver los detalles ". Lo cual es muy diferente de "No formalice su estándar de codificación" (que parece ser la esencia de muchas respuestas).
Shaz
Si lees los artículos, creo que descubrirás que esto no es lo que él quiso decir, por ejemplo, este solo debería decirte algo: 2. Deja que sean específicos del equipo en lugar de específicos de la compañía.
Bill K
Tenga en cuenta que estoy respondiendo la pregunta "¿Por qué no debería escribir un estándar de codificación" - no "¿Qué quiso decir el tío Bob". Eso puede ser contrario al título de la pregunta, pero no a su espíritu.
Tom Johnson
Tenga en cuenta que un sistema de formato de codificación automatizado que no proporciona una cláusula de escape (donde puedo desactivarlo para una sección de código) seguramente será malware en algún momento.
Yakk
66

La gente pasa por alto el verdadero propósito de un documento de estándares de codificación, que es resolver disputas .

La mayoría de las decisiones en el estándar de codificación tendrán un efecto muy pequeño en la legibilidad y la productividad. Especialmente si adopta el estilo "normal" para el idioma, y ​​los diseñadores de idiomas comienzan a darse cuenta de que esto debería ser parte de la especificación (por ejemplo, Ir).

Debido a que son tan triviales, los argumentos pueden ser realmente acalorados y continuar sin parar, causando un daño real a la productividad y la cohesión del equipo. O puede ocultar su historial de cambios con un reformateo interminable entre los estilos preferidos de dos o más personas.

Tener un estándar escrito termina el argumento. Los gerentes pueden señalarlo y desviar la insatisfacción hacia el documento. Puedes discutir con un pedazo de papel pero no te va a escuchar.

(Ver también La tiranía de la falta de estructura )

pjc50
fuente
19
Esto es increíblemente importante para los equipos que trabajan con código heredado. Especialmente cuando se pasa del código que sigue un conjunto de estándares (o no sigue ningún estándar) a otro. Sin una guía a la que hacer referencia, es imposible saber qué estilo de código seguir cuando ya hay varios estilos presentes en la base de código. Creo que el consejo de no escribir estándares está destinado a equipos muy pequeños que trabajan en proyectos nuevos sin cambio de riesgo, un caso muy raro, en mi experiencia.
thomij
44
Es mucho más importante aceptar un estándar que el contenido real del estándar. Puedes acostumbrarte a casi cualquier estilo si trabajas con él lo suficiente.
Mark Ransom
3
Discutir sobre trivialidades es una señal de incompetencia, en mi humilde opinión. Resolver la disputa concreta no solucionará el problema subyacente.
Jørgen Fogh
1
Sí, la resolución de disputas y mantener el historial de cambios sin contaminar son enormes, especialmente cuando tienes una combinación de desarrolladores OCD y no tan OCD en tu equipo. Sin embargo, he encontrado que los estándares escritos son árbitros mucho menos efectivos que las herramientas automatizadas como StyleCop, que establecen la ley sin hacerlo personal ni perder el tiempo de los gerentes.
Eric Hirst
12
"Discutir acerca de las trivialidades es una señal de incompetencia". Ojalá esto fuera cierto en la ingeniería de software ... Me temo que algunos desarrolladores muy, muy competentes (al menos técnicamente) son exactamente las personas más aficionadas a discutir sobre las trivialidades. Demonios, es su deporte nacional. "Infinitos son los argumentos de los magos" -Ursula Le Guin
Spike0xff
21

Porque los comentarios son mentiras .

El estándar de codificación es un gran comentario sobre cuál debería ser el código. El código en sí es la última fuente de verdad. La verdad en este caso no es el comportamiento del código, es el estilo en el que se expresa. Si sus estándares ya no se reflejan en su código, tiene mucho trabajo por delante.

El tío Bob ve un comentario como una falla personal del programador, porque demuestra que no logró expresar el propósito del fragmento de código con el lenguaje de programación en sí. Del mismo modo, un documento estándar es una falla al expresar un estilo coherente en la base del código.

Los nuevos programadores deberían pasar tiempo mirando el código, no pasar días leyendo un documento de estándares de varios capítulos (he tenido que hacer esto, suspiro).

Un documento de estándares no es una mala idea, pero he estado en talleres de programación donde mantener los documentos de estándares era el trabajo a tiempo completo de alguien. Por favor, si debe mantener un documento estándar, guárdelo en una página. Pero si ya tiene un código, ¿nadie debería poder armar el mismo documento en menos de un día?

Tener estándares de código es importante. Tener un documento que dicta lo que son no lo es.

naranja confitada
fuente
22
De hecho, he experimentado la base de código de varias décadas con la política "sin comentarios"; Si bien fomenta nombres de métodos descriptivos muy largos, es absolutamente terrible capturar la intención, las razones para no hacer las cosas, y solo nos salimos con la suya con uno de los autores originales todavía con nosotros.
pjc50
77
+1 "Tener estándares de código es importante. Tener un documento que dicta lo que son no lo es". Bien y sucintamente puesto.
David
44
@ pjc50 Nunca he escuchado que el tío Bob aliente una política de no hacer comentarios. Él no enseña que nunca debas comentar. Él enseña que debes sentirte mal cuando descubres que tienes que hacerlo para que te entiendan. Código no leído ilegible <comentado ilegible <legible que no necesita comentarios. Tenga en cuenta que los comentarios que menciona son los que están completamente desconectados de CÓMO funciona el código. Los documentos de estándares pueden convertirse en una lista de verificación de muerte cerebral que se marca en una revisión de código. Lo importante no es que consigas todas tus garrapatas. Es que las personas en la mesa entienden tu código.
candied_orange
3
"Los nuevos programadores deberían pasar tiempo mirando el código, no pasar días leyendo un documento de estándares de varios capítulos". No tengo idea de qué guías de codificación sigues, pero la guía de estilo C ++ de Google se puede leer fácilmente en menos de una hora y es mucho más fácil de descifrar que tener que aplicar ingeniería inversa al estilo preferido basado en el código existente (lo cual me parece horrible). Lo mismo es cierto para todas las demás guías de estilo que he leído.
Voo
55
@CandiedOrange: a menudo, los comentarios más útiles son los que describen la razón por la que no se hicieron ciertas cosas [ya que, en ausencia de tales comentarios, los futuros programadores pueden perder el tiempo tratando de implementar y luego retraer "mejoras" aparentemente obvias ese cambio fuera a ser inviable]. A menos que uno se vuelva realmente loco con los nombres de las variables, no hay forma de que incluso el código más legible pueda capturar esa información.
supercat
16

¿Por qué el tío Bob sugiere que los estándares de codificación no deberían escribirse si puedes evitarlo?

Si está preguntando razones detrás de su opinión, entonces puede tener una respuesta solo si él publicará una respuesta aquí ( nuestra opinión es irrelevante), sin embargo ...

¿Por qué no debería escribir un estándar de codificación?

Si está preguntando si tiene razón al respecto: déjeme ser el único impopular (hasta ahora) que diga que no tiene ninguna razón para evitarlo.

ESCRIBIRLO ABAJO . Sin embargo, intentaré explicar mis razones ...

David sugirió en un comentario que el punto principal de la respuesta de Stephen no es por qué no debería escribir documentos, sino en qué forma están. Si las pautas se formalizan en las herramientas (no solo en la revisión manual del código), entonces puedo estar de acuerdo (cuando la ley no requiere otra cosa). Tenga en cuenta que desafortunadamente las herramientas no pueden verificar todo (la teoría de la computación no es nuestra amiga) a menudo porque están limitadas a una unidad o paquete de traducción específico o como su idioma favorito llame a un límite .

Sin embargo, la redacción del tío Bob no me hace pensar que está hablando de eso.

¿Puedo estar en desacuerdo con un experto tan alto? Lo hago, para casi todos los puntos en la publicación citada (ver también la segunda parte de esta respuesta para más detalles). Tratemos de entender por qué (suponiendo que ya sepa que las pautas de codificación no son solo problemas menores de formato ).

  • En algunas circunstancias, la ley exige normas de codificación escritas.
  • Leo la documentación y estoy seguro de que no estoy solo. Los miembros del equipo pueden cambiar con el tiempo, el conocimiento no puede estar en una base de código de 5 a 10 años o en la mente de los miembros del equipo. Las organizaciones deberían despedir a las personas que no siguen las pautas internas.
  • Los estándares de codificación, una vez que hayan sido aprobados , no cambiarán con frecuencia y si lo desea, debe saberlo. Si los estándares cambiaron, entonces su documentación (en el código) está desactualizada porque todo su código no sigue el nuevo estándar. Reformatear / refactorizar puede ser lento, pero siempre debe seguir una guía autorizada por escrito .
  • Es mejor leer un documento de 5 páginas que inspeccionar 10 / 20K LOC para extrapolar una regla (que puede comprender erróneamente, por cierto), no hay duda al respecto.
  • Es irónico que alguien que escribió muchos libros sobre principios de diseño y estilo de codificación sugiera que no debe escribir sus propias pautas, ¿no es mejor si nos deja con algunos ejemplos de código? No, porque las pautas escritas no solo le dicen qué hacer, sino también otras dos cosas de las que carece el código: qué no hacer y razones para hacerlo o no.

La "programación de autoorganización gratuita" es buena para un chico ninja de 16 años, pero las organizaciones tienen otros requisitos :

  • La calidad del código debe otorgarse (y definirse) a nivel de empresa: no es algo sobre lo que un solo equipo pueda decidir. Es posible que ni siquiera tengan las habilidades para decidir qué es mejor (¿cuántos desarrolladores, por ejemplo, tienen todas las habilidades requeridas para revisar MISRA o incluso simplemente entender cada regla?)
  • Los miembros pueden moverse a través de diferentes equipos: si todos siguen los mismos estándares de codificación, entonces la integración es fluida y menos propensa a errores.
  • Si un equipo se autoorganiza, los estándares evolucionarán con el tiempo cuando los miembros del equipo cambien; entonces tendrá una enorme base de código que no sigue los estándares aceptados actuales .

Si está pensando en las personas antes del proceso , solo puedo sugerirle que lea sobre TPS: los seres humanos son una parte central de Lean, pero los procedimientos están altamente formalizados.

Por supuesto, una organización pequeña con un solo equipo puede dejar que el equipo decida los estándares a adoptar, pero luego debe anotarse. Aquí en Programmers.SE puede leer publicaciones de Eric Lippert: Supongo que todos estamos de acuerdo en que es un desarrollador experimentado, cuando trabajó para Microsoft tuvo que cumplir con sus pautas escritas (incluso si algunas reglas pueden ser incorrectas , no aplicables o inútiles) a él.) ¿Qué pasa con Jon Skeet? Las pautas de Google son bastante estrictas (y muchas personas no están de acuerdo con ellas), pero debe cumplirlas. ¿Les falta el respeto? No, probablemente trabajaron para definir y mejorar tales pautas, una empresa no está compuesta por un miembro (o un equipo) y cada equipo no es una isla .

Ejemplos

  • Decidió no usar herencia múltiple y clases anidadas en C ++ porque los miembros reales del equipo no lo entienden bien . Más tarde, alguien que quiera usar herencia múltiple debe explorar todo el 1M LOC para ver si alguna vez se ha usado. Es malo porque si las decisiones de diseño no están documentadas, debe estudiar toda la base de código para comprenderlas. E incluso entonces, si no se ha utilizado, ¿es porque está en contra del estándar de codificación, o está permitido, pero simplemente no hubo situaciones anteriores en las que la herencia múltiple fuera una buena opción?
  • En C # había sobrecargado los métodos para proporcionar parámetros predeterminados porque su base de código comenzó cuando los parámetros opcionales no estaban disponibles en C #. Luego cambió y comenzó a usarlos (refactorizando el código antiguo para usarlos cada vez que tenía que modificar tales funciones). Incluso más tarde, decidió que los parámetros opcionales son incorrectos y comienza a evitar usarlos. ¿Cuál es la regla que te dice tu código? Es malo porque el estándar evoluciona, pero la base de código es más lenta y si es su documentación, entonces está en problemas.
  • Jon pasó del equipo A al equipo B. Jon tiene que aprender un nuevo estándar; mientras aprende, probablemente introducirá errores más sutiles (o, si tiene suerte, solo tomará mucho tiempo comprender el código existente y hacer que la revisión del código sea más larga).
  • El equipo A pasa a una base de código que anteriormente pertenecía al equipo B. Tiene estándares de codificación completamente diferentes. ¿Volver a escribir? ¿Adaptar? ¿Mezcla? Todos ellos son igualmente malos.

Tío Bob

Déjelos evolucionar durante las primeras iteraciones.

Es cierto, hasta que no tenga un estándar y su organización le haya asignado la tarea de construir uno.

Permítales ser específicos del equipo en lugar de específicos de la compañía.

No, por todas las razones explicadas anteriormente. Incluso si piensas formalizar solo el formateo de código (lo menos útil que quieras formalizar), todavía tengo memoria de guerras interminables (e inútiles) sobre el formateo. No quiero vivirlos una y otra vez, configúrelo de una vez por todas.

No los escriba si puede evitarlo. Más bien, deje que el código sea la forma en que se capturan los estándares.

No, por todas las razones explicadas anteriormente (por supuesto, a menos que refactorice todo su código de una sola vez cuando cambien las pautas). ¿Quieres dejar tu código tal como está? ¿Cómo inspecciona la base de código para comprender las pautas actuales ? ¿Busca por antigüedad del archivo y adapta su estilo de codificación a la antigüedad del archivo de origen?

No legisles un buen diseño. (por ejemplo, no le digas a la gente que no use goto)

Es cierto que las pautas deben ser cortas o nadie las leerá. No repitas lo obvio.

Asegúrese de que todos sepan que el estándar se trata de comunicación y nada más.

No solo, un buen estándar se trata de calidad a menos que desee tener un estándar solo sobre detalles menores .

Después de las primeras iteraciones, reúna al equipo para decidir.

Vea el primer punto y no olvide que un estándar de codificación suele ser un proceso que tardó muchos años en desarrollarse y refinarse: ¿pocas iteraciones, tal vez con desarrolladores junior? De Verdad? ¿Desea confiar en la memoria de un miembro senior (si lo hay)?

Tres notas:

  • En mi opinión, los inconvenientes son más graves con algunos lenguajes que con otros, por ejemplo, en C ++, un estándar a nivel de empresa es aún más necesario que en Java.
  • Es posible que este razonamiento no se aplique por completo (y los motivos del tío Bob pueden ser menos extremos ) si está trabajando en una empresa muy pequeña en la que solo tiene un equipo pequeño.
  • Estás contratado (como equipo) y trabajarás solo con un nuevo proyecto, luego lo olvidarás y seguirás adelante. En este caso, es posible que no le importe (pero su empleador debería ...)
Adriano Repetti
fuente
55
He rechazado esto porque siento que la respuesta está fuera del tema de la pregunta, por lo que no (y específicamente el tío Bob) escribiría un estándar de codificación , no por qué debería hacerlo. Creo que todos entienden los puntos positivos de tener un estándar escrito, pero las desventajas son más difíciles de determinar y cuando un senior de la industria respetado sale con una posición opuesta a la práctica habitual en la industria, examinar por qué es ciertamente algo que vale la pena hacer.
Julio
55
@gnat gracias, no necesito votos a favor para publicaciones fuera de tema, no es "¿Por qué el Sr. X hizo Y?" fuera de tema en este caso? No sabemos sus razones y él no las explicó, ¿no debería ser una pregunta cerrada como fuera de tema entonces? ¿Cómo que responder a esta pregunta? ¿Inventar razones aleatorias o decir que la premisa es incorrecta?
Adriano Repetti
1
@AdrianoRepetti: el tío Bob ha explicado mucho a lo largo de los años, por lo que es razonable considerar que alguien puede tener alguna idea de su forma de pensar, pero tiene razón si se requiere la interpretación directa del tío Bob.
JeffO
3
@jeff sí, si la pregunta es "por qué piensa eso", entonces la respuesta es solo una suposición. Si la pregunta es "¿es correcto?" entonces mi respuesta personal es d *** absolutamente no.
Adriano Repetti
1
"Cuando trabajaba para Microsoft tenía que cumplir con sus pautas escritas". Apuesto a que lo hice. Y, por supuesto, utilizamos FXCop y StyleCop para evitar que se registren algunos patrones malos.
Eric Lippert
12
  1. Para ser útil, un estándar de codificación no debe hablar sobre cuestiones de fondo; solo cuestiones de estilo. Debe especificar solo aquellas cosas que son arbitrarias y ambiguas. por ejemplo, colocación de llaves, profundidad de sangría, espacios frente a pestañas, convenciones de nomenclatura, etc.
  2. Las cuestiones de estilo son locales, no globales. Cada equipo debe adoptar su propio estilo peculiar, acorde con su tarea y su personalidad. Esto mantiene los estándares simples y livianos. Los estándares corporativos se sobrecargan con todas las posibles consideraciones, configuraciones y excepciones.
  3. Dentro de un equipo, la única razón para escribir un documento de estilo de codificación separado es si el código producido por el equipo no cumple con el estándar. En cuyo caso no tienes estándar. Para ser efectivo, el estándar debe ser expresado por el propio código. Y si eso es así, no hay necesidad de un documento separado.
  4. En los sistemas heredados, los equipos y estilos cambian con el tiempo. No hay nada de malo en eso. El código antiguo tendrá un estilo más antiguo. El código más nuevo tendrá un estilo más nuevo. El equipo debe conocer los estilos y sus edades. Siempre que se escriba un nuevo código, debe estar en el nuevo estilo, sin importar en qué parte del código se encuentre.
Robert Martin
fuente
Tengo pocas perplejidades: 1) para ser útil, un estándar de codificación no debe hablar solo sobre el formato (cuestión de guerras santas, pero es fácil de entender el código de lectura) sino construcciones para evitar, patrones de codificación (para evitar errores comunes, lenguaje no fácil de entender características) y problemas de seguridad. Estas son pautas de codificación (más útiles que los problemas de formato). 2) Dada la premisa del punto 1, entonces no se trata de personalidad (pero puede tratarse de tareas ), puede tener un estándar corporativo liviano, es su propio deber hacerlo liviano.
Adriano Repetti
3) El código puede decirle qué hacer, pero no puede transmitir lo que no debe hacer (a menos que desee estudiar la base del código completo e incluso en ese caso ... simplemente no tuvo que usar X construct o es un no-no?) Otra cosa importante es el razonamiento: ¿por qué no? y por que si Las cosas pueden cambiar con el tiempo, pero ¿cómo saber si las premisas iniciales siguen siendo válidas? 4) y cuando eres un nuevo miembro del equipo y escribes un nuevo código ... ¿estudias la base del código con la misma edad para mantener ese estilo de codificación? El día después de mudarse a otro componente más nuevo y estudiar nuevamente la base de código (¿filtrando por fecha de creación?)
Adriano Repetti
Por cierto, si, en cambio, sugiere no escribir solo estilos de formato de código, entonces puedo estar de acuerdo (bueno, en realidad no pero con razones no tan fuertes además de recuerdos de discusiones interminables e inútiles que inevitablemente surgirán cada vez, y que es una pauta corporativa evitará de una vez por todas), sin embargo, debe dejarlo claro o la gente interpretará sus palabras demasiado literalmente (vea la mayoría de las respuestas + comentarios aquí). También ese punto sobre "goto" es un poco engañoso en este sentido (IMO)
Adriano Repetti
4

¿Por qué no debería escribir un estándar de codificación?

Hay muchas razones para esto. Aquí hay algunas consideraciones:

  1. ¿Cuánto tiempo pasan las personas "aprendiendo" los estándares del código solo para tener mucho tiempo para que todo el equipo revise, discuta, documente, revise ... etc. estándares del código? Esto es como discutir constantemente su "Manual del Empleado": ¿con qué frecuencia aparece en la agenda de una reunión de equipo?

  2. Cuando un proyecto es financiado / archivado / etc. entonces las pocas personas que quedan generalmente no pueden seguir adhiriéndose (o tal vez ni siquiera han leído) los estándares. Lo siguiente que sabes es que, de todos modos, todo ese esfuerzo para "mantener limpio el código" se desperdició.

  3. Si el proyecto se detiene o se presenta un nuevo cliente potencial, es muy probable que la persona ignore por completo las reglas anteriores y quiera hacerlo de una nueva manera. Nuevamente, ¿qué se ganó codificando estándares?

Debes asegurarte de leer # 6:

Después de las primeras iteraciones, reúna al equipo para decidir.

En otras palabras, cuando llegue el momento de comenzar un proyecto, simplemente siga la corriente por un tiempo. Luego discuta las reglas generales de los estándares de codificación que el equipo actual está usando, y básicamente sígalas. De esa manera, maximiza el esfuerzo que se necesita para mejorar el producto y minimiza el esfuerzo necesario para escribir, revisar y documentar el "azúcar sintáctico" que se utilizó para obtener el código ejecutable.

Muy pocos equipos obtienen enormes beneficios de los estándares de codificación. Por lo general, "legibilidad" es demasiado vago - y la mayoría de los desarrolladores no se benefician en gran medida de exactas reglas sobre el espaciamiento, nuevas líneas, etc., pero se puede evitar constantemente molestos desarrolladores por tener al menos un par de reglas.

Jim
fuente
4

Otra respuesta que no creo que se haya dicho con suficiente claridad es que también significa que las personas no siguen las reglas a ciegas. Significa que las personas tienen que presentar justificaciones reales para sus decisiones de diseño y convenciones de codificación, en lugar de solo depender del hecho de que se ha escrito para justificarlo.

Finn O'leary
fuente
4

En primer lugar, que yo sepa, el tío Bob es una persona de Java, esto es muy importante para entender lo que dice.

Cuando trabajo en un equipo Java o C #, si el código actual ha sido escrito por desarrolladores experimentados, es fácil para mí elegir el estilo de codificación y seguir el ritmo. Si no estoy dispuesto a hacerlo, tal vez no era la persona adecuada para el trabajo ... Si no hay revisión de código o programación de pares para recogerme cuando no sigo con el estilo, entonces la compañía tiene un ¡Un problema mayor que la forma en que nombro los campos de miembros!

Tanto Java como C #, junto con la mayoría de los lenguajes modernos, se han definido para que haya pocas trampas "simples" en las que pueda caer un programador.

Sin embargo, cuando comencé a programar, estaba usando C (y luego C ++). En C puedes escribir código como

if (a = 3);
{
   /* spend a long time debugging this */
}

El compilador no dará un error, y eso es difícil de detectar cuando se lee mucho código. Sin embargo, si escribes:

if (3 = a)
{
   /* looks odd, but makes sense */
}

El compilador da un error, y es fácil cambiar el código 3 == a. Del mismo modo, si el estándar de codificación no permite =ser utilizado dentro de una ifcondición o " ifdeclaración vacía ", entonces se puede usar un verificador de código como parte del sistema de compilación para rastrear este error.

Mis puntos de vista sobre los estándares de codificación cambiaron mucho cuando me alejé de C / C ++: solía gustarme los estándares de codificación que se aplicaban estrictamente y tenían muchas páginas. Ahora creo que solo necesita enumerar las herramientas que se utilizan y obtener un acuerdo informal entre los miembros del equipo original en algunas convenciones de nomenclatura. Ya no vivimos en un mundo de equipos de más de 30 desarrolladores que escriben aplicaciones en C / C ++ ...

Hay una razón por la que nunca me gustó JScript, y creo que TypeScript es lo mejor que le ha pasado al desarrollo web durante años. Espero que los desarrolladores de IU web todavía necesiten estándares de codificación debido a los defectos en el diseño de HTML / CSS / JScript, etc.

Ian
fuente
44
"El compilador no dará un error" la mayoría de los compiladores modernos de C y C ++ admiten la notificación de este comportamiento con advertencias o, si lo desea, errores completos. gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
JAB
2
"En primer lugar, hasta donde sé, el tío Bob es una persona de Java, esto es muy importante para comprender lo que dice", eso no es cierto, el tío Bob ha escrito artículos fantásticos sobre C ++ y definitivamente también ha trabajado varios años con C.
Alessandro Teruzzi
@JAB, Afortunadamente, C / C ++ dejó de ser utilizado para nuevas "aplicaciones comerciales" hace mucho tiempo (por ejemplo, antes de los compiladores de C / C ++ modernos), y ahora solo lo usan principalmente expertos en C / C ++, en lugar de personas que son expertos en UI (MFC) por ejemplo.
Ian
1
@AlessandroTeruzzi Una prueba unitaria le indicará que un método está fallando. Por qué está fallando es un asunto diferente: incluso si tuviera pruebas unitarias para un método con ese tipo de código, le sería muy difícil tratar de descubrir qué está mal. C ++ es uno de los lenguajes más castigadores para depurar.
T. Sar
2
Creo que hay un malentendido aquí, no puedes tomar una sola oración de UncleBob y analizarla de forma aislada. Si tiene software SOLID con clases pequeñas, método corto y cobertura de prueba de unidad a prueba de balas, el estándar de codificación es redundante. Si tiene un código débil, una interfaz enorme, grandes funciones y poca cobertura, el estándar de codificación puede brindarle algún beneficio. Pero, UncleBob no sugiere no tener uno, sino difundirlo verbalmente con colaboración y refactorización (eliminar el código débil de la base de origen). Haga que su código sea el estándar de codificación de vida.
Alessandro Teruzzi
3

Que la fuente sea el estándar de codificación autodocumentado implica dos cosas.

  1. Las personas deben consultar el código base y revisarlo para convertirse en colaboradores competentes. Esto es increíblemente importante. Leer las pautas de codificación es una pérdida de tiempo en comparación con sumergirse en la base del código.
  2. Reconoce que las diferencias menores no son importantes. Es importante acordar y comprender los principios básicos. Mantener un estilo consistente no se persigue como l'art pour l'art. No permite que los no creativos molesten y distraigan a otras personas. Se trata de facilitar la comunicación a través del código en un equipo.
Peter A. Schneider
fuente
2

Un documento de estándares de código bien actualizado y bien escrito puede ser muy útil, pero generalmente este no es el caso. El documento de estándares no refleja los estándares de codificación reales utilizados por la compañía, ya que es muy difícil crear un buen documento de estándares y aún más difícil mantenerlo actualizado.

En lugar de tener un documento de estándares de codificación pobre y engañoso, es mejor no tener ninguno y dejar que el código mismo represente esos estándares. De cualquier manera, la parte más importante es aplicar los estándares en el código, y esto requiere mucho más que un simple documento. La motivación, los procesos, los entrenamientos, las herramientas, etc. son mucho más importantes.

DiseñadorAnalista
fuente
2

Una cosa muy importante que no se ha establecido con suficiente claridad es que los estándares de codificación son como el lenguaje: evolucionan. Un estándar de codificación escrito se interpone en el camino de esto, y si no lo hace, está continuamente desactualizado e inútil.

No tener un estándar de codificación definido no es tan malo. Si realiza revisiones por pares en el check-in, cada vez que algo que no cumple con el estándar de codificación ingresa al repositorio, eso significa que 2 personas lo pensaron * y decidieron que el beneficio de esta variación supera la inconsistencia con el resto del código.

No tener un estándar escrito también elimina la burocracia que evitaría que un equipo de una empresa intente una nueva variación del estándar de codificación para un nuevo proyecto, ya sea porque quieren probar algo o tal vez porque un estándar diferente tiene aplicaciones prácticas en algunas de las herramientas automatizadas que usan.

Escribir un estándar tiene una tendencia a eliminar más flexibilidad de lo que se pretendía originalmente, al tiempo que consume bastante tiempo que podría dedicarse a otras cosas. No digo que nunca debas escribir estándares de codificación, los estándares escritos ciertamente tienen sus beneficios, especialmente si los equipos que trabajan en diferentes ubicaciones trabajan en la misma base de código.

Muy relacionado: Evolución en los estándares de codificación, ¿cómo los maneja?

* Si las personas no piensan mientras revisan el código por pares en el check-in, sus problemas son mucho más grandes que los estándares de codificación.

Peter
fuente
1

Cambiarlos se convierte en un obstáculo importante, y las personas se adherirán con seguridad a la letra de la ley en lugar de comprometerse con el cerebro y hacer lo correcto.

Llegará el día en que parte del estándar no sea útil y empeore el código. Algunas personas se adherirán al estándar, porque está escrito y son seguras, y porque las reglas están ahí para ser seguidas. Las personas que desean escribir un buen código en lugar de un código que cumpla con los estándares se sentirán frustradas y enojadas. Habrá argumentos y desacuerdos, mientras que si el estándar no fuera escrito, habría exploración y discusión.

Moschops
fuente
0

Creo que muchas publicaciones aquí son un estándar de codificación confuso con una guía de estilo .

Asegurarse de que los módulos desarrollados por diferentes equipos tengan las mismas opciones de compilación y ABI es un tipo diferente de cuántos espacios están sangrados.

Deben documentarse cosas como la forma adecuada de estructurar #incluir archivos y no contaminar el espacio de nombres global en un archivo de encabezado para que puedan usarse como una lista de verificación durante la codificación inicial y las revisiones de código.

En particular, "no uses XXX porque causa problemas de compatibilidad con YYY" no es algo que verías por ejemplo al seguir otro código, ya que no está allí. Por lo tanto, deje que el código sea la forma en que se capturan los estándares, puede que no esté claro o que falte por completo para algunos tipos de estándares, por lo que este no puede ser un plan universal.

Algo gravemente dominante e importante como no usar excepciones o no usar newen ciertos sistemas integrados no puede dejarse simplemente como conocimiento cultural común, ya que "la información es cultural (solo)" contradice los principios fundamentales de los estándares de fabricación como ISO-9000, que el El desarrollador de estos sistemas integrados está utilizando (por ejemplo, para aplicaciones automotrices). Estas cosas importantes deben documentarse, firmarse y archivarse de manera formal.

Pero eso se aplica a la codificación , no al estilo .

Los inventores de C y C ++ muestran, por ejemplo, el uso de nombres en minúsculas y no CaMelCaSe. Entonces, ¿por qué tantos desarrolladores no siguen el ejemplo implícito de la fuente? ¿No debería ser el estilo de la biblioteca estándar y los materiales de enseñanza canónicos el estilo implícito a seguir?

Mientras tanto, las personas hacen seguir el ejemplo de los encabezados de biblioteca estándar para las cosas que no deben ser copiados, al igual que el uso de __Uglylos nombres de los parámetros macro y el archivo de inclusión patrón no repetición.

Por lo tanto, tener cosas a menudo no se considera un estilo importante o, por el contrario, tener ejemplos puede no ser claro en cuanto a lo que no se debe seguir en el código del proyecto. Ambos son contraejemplos de la tesis de que "estilo" (o convenciones de codificación) es mejor dejarlo implícito.

JDługosz
fuente