¿Puede haber demasiada uniformidad en los estándares de codificación?

Uniformidad no es un problema (es bueno) pero rigidez o inflexibilidad puede ser. Si en la lucha por la uniformidad te vuelves dogmático, entonces el daño que le estás haciendo al equipo puede ser mayor que el bien que proviene de la uniformidad (posiblemente) resultante.

Es mejor establecer un estilo básico para las cosas más importantes (nomenclatura y uso de mayúsculas, sangría, nuevas líneas y ubicación de corchetes, etc.), establecer recomendaciones para cosas menos importantes (si se trata de un formato de declaración, otros espacios en blanco entre paréntesis, etc.), y luego no te preocupes por el resto.

Cuando potencialmente docenas de personas están trabajando en un proyecto a lo largo de los años de su vida útil, a veces se vuelve confuso cuando tiene que saltar estilos. Imagine leer un libro donde diferentes capítulos están escritos por diferentes autores que solo un poco mantienen el estilo de escritura. Es posible, pero es molesto.

La mayoría de los IDE pueden imponer estilos en estos días, por lo que, si es necesario, puede distribuir (como parte del código fuente del proyecto) un archivo de preferencias IDE que especifique el estilo de codificación elegido y que todos lo instalen y lo utilicen para formatear el código. estas escribiendo Apuesto a que incluso hay formas de reformatear / diseñar el código en el registro (aunque no he tenido que investigar esto todavía).

Un caso de exceso de uniformidad que he visto es tener un solo estándar que se aplique a todos los lenguajes de programación, independientemente de lo apropiado:

• Desalentador goto incluso en idiomas como C sin try ... catch .
• Usar InitialCaps names (como en MFC y C # de Microsoft) en JavaScript donde la biblioteca estándar es initialLowerCase .

No creo que exista tal cosa como demasiada uniformidad. Sin embargo, a menudo encuentro demasiada ESPECIFICIDAD en los estándares de codificación. Los beneficios de que todos pongan la abrazadera de apertura en una línea separada son dudosos en el mejor de los casos y no superan el tiempo empleado en discutir sobre esto o solucionar problemas estéticos en el código.

Tendría 2 argumentos para la uniformidad:

• Promover la propiedad colectiva. Que alguien pueda editar el código de otra persona sin temer que el "bebé" de alguien esté a punto de ser dañado por el cambio. Una especie de mentalidad de "Estamos todos juntos en esto".

• Facilidad de agregar a ella. Si ya se ha hecho algo en otro lugar, se puede tomar y reutilizar. Ciertas convenciones pueden ayudar a facilitar la lectura o el cambio de las cosas, por lo que este es otro beneficio para mi mente.