¿Deberíamos alentar los estilos de codificación a favor de la autonomía del desarrollador, o desalentarlos a favor de la coherencia?

14

Un desarrollador escribe if/else bloques con declaraciones de código de una línea como:

if (condition)
   // Do this one-line code
else
   // Do this one-line code

Otro usa llaves para todos ellos:

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

Un desarrollador crea una instancia de un objeto y luego lo utiliza:

HelperClass helper = new HelperClass();
helper.DoSomething();

Otro desarrollador crea una instancia y utiliza el objeto en una línea:

new HelperClass().DoSomething();

Un desarrollador es más fácil con matrices y for loops:

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

Otro escribe:

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

Estoy seguro de que sabes de lo que estoy hablando. Lo llamo estilo de codificación (porque no sé cómo se llama). Pero como sea que lo llamemos, ¿es bueno o malo? ¿Alentarlo tiene un efecto de mayor productividad de los desarrolladores? ¿Deberíamos pedir a los desarrolladores que intenten escribir código de la manera que les decimos, para que todo el sistema sea coherente con el estilo?

    
pregunta Saeed Neamati 13.09.2011 - 20:37
fuente

14 respuestas

19

Un documento de estándares de codificación es útil. Es lo más útil cuando es lo suficientemente corto para que cualquiera pueda recordar todo sin demasiados problemas y cuando no causa a nadie. demasiado dolor.

Cómo elige sangrar el código en su organización, o poner mayúsculas en los nombres, o implementar sus bucles, o comentar que su código no importa mucho; la parte útil es hacer que todos escriban un código que se parezca al de todos los demás.

  • Evita tener que pasar un minuto recalibrando tu expectativa de dónde deben estar los frenos y así cada vez que mires el código de otra persona.
  • Evita tener varios estilos de código diferentes en el mismo archivo.
  • Quizás lo más importante, tener un estándar escrito evita los argumentos sobre las prácticas de codificación durante las revisiones de código.

Una vez más, lo que son los estándares no importa tanto como tener algún tipo de estándar simple y directo. Entonces, ponga a todos sus desarrolladores en una sala y permita que discutan sobre cuáles deberían ser los estándares. Esta reunión podría continuar indefinidamente, por lo que las reglas son:

  • Cualquier cosa que no se haya decidido al final de la reunión será decidida por el gerente.
  • La reunión terminará después de dos horas, o cuando alguien empiece a gritar o llorar, lo que ocurra primero.
  • La norma completa se ajustará (¡en un tamaño de letra razonable!) en una hoja o dos de papel, a doble cara solo si es absolutamente necesario.

Considere adoptar alguien | else's | normas como punto de partida para su propia reunión de normas de codificación , o como una forma de evitar la reunión por completo.

Una vez acordado, los desarrolladores deben poder (y debe esperarse) controlarse ellos mismos. La desviación ocasional de la norma no debería ser un gran problema (e incluso podría ser justificable), pero la negativa obstinada a abandonar algún estilo personal favorito a favor de la norma debería dar lugar a una reubicación inmediata en la oficina con las tuberías de agua con fugas, o lo que sea .

Demian Brecht apunta a herramientas de pelusas. Estos son un complemento perfecto para un documento de estándares de codificación. Es simplemente bueno atenerse a los estándares de estilo de codificación; es importante atenerse a los estándares de codificación que se relacionan con prácticas peligrosas. Nadie más que el autor va a verificar que cada línea de código cumpla con el estándar de estilo, pero ciertamente debería considerar la creación de una herramienta de pelusas en el flujo de trabajo de su equipo para detectar automáticamente los posibles errores. Además, la propia herramienta puede codificar las prácticas aceptadas para que no tenga que enumerarlas todas individualmente en los estándares de codificación; simplemente especifique la configuración de la herramienta.

Nota: La idea de "estándares de codificación" no es exclusiva de la programación. Los "estándares de codificación" se utilizan en muchos campos, a veces dentro de una organización, más a menudo en toda una industria o profesión. Algunos ejemplos:

En cada caso (y en muchos otros), un profesional competente podría entender fácilmente el "código" que no cumple con el estándar esperado. ¿Por qué tantas industrias persisten en escribir requisitos detallados para documentos que ni siquiera necesitan ser analizados por un compilador? Porque el estilo importa . La presentación de información en un estilo estándar permite que el lector se enfoque completamente en el contenido, agilice la lectura y ayude a comprender, y reduce los errores.     

respondido por el Caleb 13.09.2011 - 23:07
fuente
16

El estilo no importa.

Allí, lo dije.

Después de 30 años, y cientos de sitios de clientes, y el código de (estimando) 500 (o más) miembros del equipo durante esos años, he encontrado que el estilo no importa.

Haz que funcione, primero.

Haga que use un volumen óptimo de recursos (es decir, la estructura de datos correcta, el algoritmo correcto).

Alboroto por el "estilo" después de que todo más se haya resuelto. Alboroto de "estilo" solo con herramientas, nunca de forma manual.

    
respondido por el S.Lott 13.09.2011 - 21:08
fuente
4

Hay estilos de codificación y hay olores de codificación. No fue una vez que encontré:

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

Mi empleador anterior ha prohibido rigurosamente el uso de multiline if() sin llaves. Se consideró un error de tipo "hazlo de nuevo y estás despedido". Los constructos permitidos fueron

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

Esto se debió a un error como el que mostré anteriormente, que tardó un par de horas en encontrar que se detenía la página principal del portal.

Hay cosas que debes hacer siempre. Como switch() :

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

Mientras tanto, escribiendo:

     case 1:
         something();
     case 2:
         something();
     break;

sin cerrar case con //fallthrough se considera un error.

En general, existe el estándar de codificación, que es una guía que puede ignorarse, interpretarse creativamente o modificarse para necesidades específicas. Y está la sección sobre "olores" y debe ser obedecida rigurosamente.

    
respondido por el SF. 14.09.2011 - 12:03
fuente
3

Crea consistencia con un buen diseño inicial. Lo que se describe en la pregunta es nada menos que la microgestión. Hago mucho desarrollo web. Por eso estoy a favor del desarrollo de RESTful y CRUD expuestos como servicios Esto garantiza entidades simples y bien definidas que se pueden utilizar de varias maneras.

Este diseño también me permite delegar detalles de implementación a otros desarrolladores. De esta manera, están llenando los espacios en blanco en lugar de crear un diseño de sistema completo.

La falta de un diseño general crea inconsistencias en el sistema. La crítica de las iteraciones básicas y las construcciones en bucle hace poco para mejorar el diseño del sistema. Este tipo de problemas se resuelven mejor con un enfoque directo, StyleCop.

¿Puede dibujar un diagrama relativamente simple del diseño general de su sistema? Un diseño que describe los elementos / entidades involucradas en un nuevo desarrollador de equipo. Si no puede, o está muy involucrado, entonces falta el diseño.

    
respondido por el P.Brian.Mackey 13.09.2011 - 20:53
fuente
3

En mi humilde opinión depende ...

Sus dos primeros ejemplos no son solo una cuestión de gusto personal para mí.

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(sin paréntesis) = más propenso a errores, si se agrega más código más adelante:

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

Y esto es menos conveniente para la depuración:

new HelperClass().DoSomething(GetSomeData()); // etc.

No puede simplemente establecer un punto de interrupción donde lo necesite. Si esto es excepcional, lo suficientemente justo, pero lo discutimos como una cuestión de estilo, y una vez que tienes cosas como estas por todas partes, la depuración se vuelve más desagradable de lo que es.

En cuanto a tu tercer ejemplo (para vs foreach), lo veo como cuestión de gustos.

    
respondido por el Konrad Morawski 14.09.2011 - 00:07
fuente
2

Ninguno. Evitaría las duras reglas de codificación para evitar ser tedioso, delicado, micro administrativo y, lo que es peor, perder el tiempo. Tu sentido de autonomía es tu propio problema. Si quiero que te sientas mejor contigo mismo, te compraré una ronda de tu bebida favorita. Aparte de eso, haz algo.

    
respondido por el JeffO 13.09.2011 - 21:52
fuente
2

El uso de convenciones, nombres de variables, nombres de clases, etc. es una buena práctica. Pero los estilos de codificación como los ejemplos que proporciona son bastante triviales y no tienen ningún efecto ni en la legibilidad ni en la eficiencia del código. Por otro lado, la sobrecarga de imponer un estilo dado combinado con el esfuerzo de los desarrolladores para seguirlo causará problemas.

    
respondido por el AJC 13.09.2011 - 22:55
fuente
2

Use una herramienta de línea estándar de la industria (aparentemente FxCop para C #). Si bien no es el fin de todo, la coherencia es importante en los proyectos grandes que tienen una cantidad de personas trabajando en ellos.

Si solo estás trabajando en tu propio proyecto o equipo pequeño, muchos argumentarán que es una exageración. Creo lo contrario (uso PEP8 para Python, incluso en mis proyectos personales de desarrollador único).

Sin embargo, es muy probable que la mayoría de los ejemplos que proporcionó no sean captados por una herramienta de alineación, ya que simplemente no importan.

    
respondido por el Demian Brecht 13.09.2011 - 23:05
fuente
1

Hacer cumplir el estilo de codificación uniforme siempre es difícil. Idealmente, una tarea tan mundana debería dejarse en manos de una herramienta para manejar. Aplaudo a la comunidad lingüística Go por hacer eso.

    
respondido por el grokus 13.09.2011 - 21:20
fuente
1

Es una mezcla de ambos. Solo porque es un estándar no lo hace legible y mantenible. Si todavía no hay un estándar instilado, o si hay aspectos defectuosos e ilegibles de él, la revisión es apropiada.

    
respondido por el user29981 13.09.2011 - 23:06
fuente
1

En el análisis final, es el programador el que impulsa la programación. Existen problemas de estilo, pero son secundarios para sacar el programa.

ES útil darles a los programadores ALGUNA guía de estilo. Esto puede / debe hacerse antes de que los programadores se pongan a trabajar, especialmente si son principiantes relativos al entorno o a la programación en sí. Teniendo en cuenta la orientación, algunos programadores serán muy conscientes del estilo, otros no tanto. La orientación proporcionada al comienzo del proyecto ayudará al primer grupo de programadores, facilitando así la tarea general. Podría hacer poco por el segundo grupo, que (con suerte) compensará con creatividad, lo que les falta en conformidad.

    
respondido por el Tom Au 14.09.2011 - 01:43
fuente
1

Creo que todo se reduce al tamaño del proyecto y a cuántas personas están trabajando en él. Un programador experto puede observar los dos estilos de formatos diferentes y saber lo que estaba sucediendo en ambos, pero es necesario que haya una asociación para que el ojo pueda captarlo fácilmente. Si va a hacer su línea única si los estados sin las llaves no están disponibles, entonces el proyecto no debería usarlos. Quien esté liderando ese proyecto debería tener esa opción. Me gusta que las cosas se vean claras y también muy compactas, ya que puedo conseguirlas. Si vas a hacer una sola línea si los estados se ven mejor así

if() {}
else() {}

O incluso:

if() {} else () {}

Pero una sola línea si no debe usar el espaciado de una mulitilina si. Así es como hago las cosas. No me importa la forma en que se llama el objeto y eso depende de cuántas veces se llama. Si se llama un par de veces, entonces prefiero iniciar el objeto y depende de si tiene constantes y qué no también. Porque si tienes un constructor y llamas:

Object.method();
Object.method2();

Luego, terminaste de llamar al método constuctor de objetos dos veces cuando podría haberse evitado instancizando el objeto completamente.

Cuando se trata de foreach y para bucles También se trata del lanauge que algunos lanauges le brindan un mejor control al mirar la matriz en un bucle foreach para que tenga la clave y el valor de las matrices temporales. Y sé que algunos lanagues tienen algún tipo de optimización porque pueden mirar el bucle y saber exactamente cuántas veces se llamará.

    
respondido por el WojonsTech 14.09.2011 - 03:28
fuente
1

Si bien su primer ejemplo no es bueno (el argumento de que es más propenso a los errores en la modificación tiene cierto peso), en general he llegado a preferir que los desarrolladores usan estilos de codificación ligeramente diferentes.

Después de trabajar con el código de otros miembros del equipo, a veces durante unos pocos meses, esencialmente comienza a trabajar en línea un git blame en línea. Después de haber estado en mi compañía por más de 10 años, probablemente pueda decirle con una precisión del 80% o más quién escribió una clase determinada en cualquier lugar de nuestras 500 mil líneas de código, solo con verlo.

Aunque hay un poco de "tiempo de rampa" cuando empiezas a mirar un código que usa un estilo con el que no estás de acuerdo, lo que realmente estás haciendo en ese momento es "oh, esto se parece a John Doe's código (porque usa el estilo X pero no el estilo Y, etc.) ". Y eso trae consigo un montón de contexto. Para una primera aproximación, sabes qué esperar del código de John: qué otras partes del código base entiende bien y qué partes no, ya sea un gurú de SQL o un novato en GUI, etc., etc.

Ejecutar el código de todos a través de un formateador esencialmente elimina esta información, ocultándola detrás de un git blame , que no debes molestarte en ejecutar.

    
respondido por el Matt McHenry 14.09.2011 - 03:09
fuente
0

Esto realmente depende mucho del tipo de organización.

Si eres un grupo pequeño de superhéroes, entonces cualquier tipo de estilo está bien. Si cada uno tiene su propio estilo y es bueno y coherente internamente, ese es todo el proceso que necesita. Los superhéroes dirán: "Jane tiene corchetes, así que esto es lo que quiere decir" o "Jack usa camelCase para las variables".

Los estándares universales tienden a ser los mejores para hacer que todos sean jugadores B +. Tus superhéroes serán derribados por esto. Pero si quieres un jugador A y media docena de jugadores B y media docena de jugadores C para promediar hasta el B +, entonces quieres estándares consistentes. En este caso, querrá que todos hagan las cosas de la misma manera para que el jugador de Un A pueda revisar el código de todos lo más rápido posible.

Muchos de vosotros, "Pero espera, ¿por qué no acabas con los jugadores B y C?"

La realidad es que no hay muchos superhéroes. Si bien puede costar encontrarlos y cuidarlos en Google, implementar un nuevo sistema de facturación para Ma Bell puede ser más rentable con este último equipo. (Y si realmente tienes superhéroes, 4 o 5 de ellos serán dos veces más caros que una docena de juniors)

    
respondido por el MathAttack 24.03.2012 - 05:10
fuente

Lea otras preguntas en las etiquetas