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

12

¿Existe tal cosa como demasiada uniformidad? Donde trabajo, por supuesto, tenemos estándares que incluyen convenciones de nombres, arquitecturas, marcos para aprovechar, etc. Sin embargo, últimamente ha habido muchas críticas sobre cosas que consideraría más estilo.

Por ejemplo, escribir ifdeclaraciones en varias líneas frente a una línea, utilizando el ??operador de fusión nula c # en lugar de == null, por ejemplo , cantidades de espaciado para sangrías, etc.

Me parece que esto comienza a convertirse en una elección de estilo personal y no necesita ser uniforme en un equipo o empresa. Lo que una persona piensa lee más claramente, otra no. ¿Hay algún valor en esta uniformidad "extra"?

programming-practices team coding-standards Gratzy
fuente
2
Hola Gratzy, Programmers.SE no es un panel de discusión ; Estamos aquí para resolver los problemas reales que pueda enfrentar. ¿Tienes un problema real que estás tratando de resolver? Si es así, ¿puede reformular su pregunta para mantener las respuestas constructivas y fuera de las trampas de convertirse en una discusión?
1
@Gratzy para decirlo de otra manera, dada una situación que usted enfrenta personalmente, ¿cuál sería el criterio para una respuesta correcta?
2
@ Mark Trapp de acuerdo con las preguntas frecuentes, estos son los criterios para una pregunta Se espera que todas las preguntas subjetivas sean constructivas. ¿Cómo definimos eso? Preguntas subjetivas constructivas ... 1. inspire respuestas que expliquen "por qué" y "cómo". 2. tienden a tener respuestas largas, no cortas. 3. Tener un tono constructivo, justo e imparcial. 4. invita a compartir experiencias sobre opiniones. 5. Insista en que la opinión se respalde con hechos y referencias. 6. son más que diversión social sin sentido. Creo que mi pregunta cubre los primeros 4 como mínimo
Gratzy
2
@Gratzy también de las preguntas frecuentes: "Solo debe hacer preguntas prácticas y que respondan en función de los problemas reales que enfrenta. Las preguntas charlatanas y abiertas disminuyen la utilidad de nuestro sitio y empujan otras preguntas fuera de la página principal".
2
@ Mark Trapp Ya he establecido criterios para una respuesta aceptable y sí, como he dicho, este es un problema real y, francamente, por el interés en la pregunta y las respuestas, diría que otros están de acuerdo.
Gratzy

Respuestas:

16

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

Es mejor establecer un estilo básico para las cosas más importantes (estándares de nomenclatura y capitalización, sangría, líneas nuevas y colocación de corchetes, etc.), establecer recomendaciones para cosas menos importantes (si el formato de la declaración, otros espacios en blanco alrededor de paréntesis, etc.) , y luego no te preocupes por el resto.

Nicole
fuente
1
He estado allí
+1, dijo lo que quería decir, ¡pero mejor!
FrustratedWithFormsDesigner
@Pierre, ¿por eso eres independiente ahora? :)
Nicole
en realidad no, pero he conocido a muchas personas obsesivas sobre pautas. Da miedo cómo puede ser extremo. Creo que definiste el límite bastante bien.
7

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

La mayoría de los IDE pueden aplicar 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 usen para formatear el código que están escribiendo. . Apuesto a que incluso hay formas de reformatear / diseñar el código en el check-in (aunque todavía no he tenido que investigar esto).

FrustratedWithFormsDesigner
fuente
Sí, probablemente podrías poner un guión de hormigas allí en alguna parte.
Michael K
1
IntelliJ, al menos, tiene una opción para reformatear el código antes de registrarse.
Nicole
3

Un caso de sobre-uniformidad que he visto es tener un único estándar que se aplica a todos los lenguajes de programación, independientemente de lo apropiado:

  • Desalentar gotoincluso en lenguajes como C sin try... catch.
  • Usar InitialCapsnombres (como en MFC y C # de Microsoft) en JavaScript donde está la biblioteca estándar initialLowerCase.
dan04
fuente
2

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

JohnFx
fuente
2
@Tungano No podría estar más de acuerdo. La paradoja de los estándares de codificación es que vale la pena tenerlos, pero no vale la pena discutirlos.
Charles E. Grant
3
No veo cómo forzar un estilo particular en la garganta de un programador te ayudará a evitar esos argumentos. De hecho, argumentaría que hacer que un programador se adapte a un estilo que no le gusta ALIENTA esos argumentos, o al menos resentimiento.
JohnFx
1
@JohnFx, porque la mayoría de los programadores se darán cuenta de que la consistencia del estilo contribuye mucho más a la calidad del código y al mantenimiento que cualquier elección particular de estilo. En mi experiencia, puede hacer un recuento rápido del equipo, ver lo que le gusta y no le gusta a la gente, y llegar rápidamente a un consenso. Ocasionalmente, alguien tendrá un bugaboo peculiar y usted lo acomodará, y luego cederá ante el bugaboo de otra persona. Si me encuentro discutiendo con el equipo durante cinco minutos sobre por qué el caso de los camellos es malo, simplemente lo dejo y cedo como prueba de mi flexibilidad personal.
Charles E. Grant
1
Yo diría que la mayoría de los programadores PIENSAN que la consistencia del estilo hace una gran contribución, pero realmente no lo hace. Parece que debería ser, es molesto mirar el código que no coincide con el estilo de su mascota, y pasar por un bloque de código "limpiarlo" por problemas cosméticos menores es una buena manera de postergar. Mire, yo también solía estar en ese carro hasta que me di cuenta de que me estaba centrando en el chapado en oro y no en el entregable.
JohnFx
1
Trabajo con código de nuestro equipo alemán, un par de proyectos de OSS y algunos códigos antiguos que tenemos, así como nuestras cosas actuales. Algunos son C, algunos C ++, algunos C #. Así que tengo que trabajar con varios estilos de código diferentes todo el tiempo. Cuando haces eso, te das cuenta de lo insignificantes que son las pautas de estilo que se imponen en los estándares. Si puedo cambiar de un proyecto a otro, puedo manejar a alguien que ponga su {} en diferentes lugares. Es por eso que creo que el único estándar que vale la pena es el que tiene 1 regla: "consistencia dentro de cada proyecto".
gbjbaanb
2

Tendría 2 argumentos para la uniformidad:

  • Promoción de la propiedad colectiva. Que alguien puede ir a editar el código de otra persona sin temer que el "bebé" de alguien esté a punto de sufrir el cambio. Una especie de mentalidad de "Estamos todos juntos en esto".

  • Facilidad de agregarle. Si ya se ha hecho algo en otro lugar, esto puede tomarse y reutilizarse posiblemente. Algunas convenciones pueden ayudar a hacer que las cosas sean más fáciles de leer o cambiar a veces, por lo que este es otro beneficio para mi mente.

JB King
fuente