formatting - google - java code conventions en español
Formato de código: alinea líneas similares ¿está bien? (14)
Recientemente descubrí que nuestra empresa tiene un conjunto de pautas de codificación (ocultas en un sistema de administración de documentos donde nadie puede encontrarlo). Por lo general, parece bastante sensato, y se mantiene alejado de las guerras religiosas habituales sobre dónde poner ''{'' sy si usar pestañas difíciles. Sin embargo, sí sugiere que "las líneas NO DEBEN contener espacios múltiples incrustados". Por lo que significa no hacer este tipo de cosas:
foo = 1;
foobar = 2;
bar = 3;
O esto:
if ( test_one ) return 1;
else if ( longer_test ) return 2;
else if ( shorter ) return 3;
else return 4;
O esto:
thing foo_table[] =
{
{ "aaaaa", 0 },
{ "aa", 1 },
// ...
}
La justificación para esto es que los cambios en una línea a menudo requieren que se edite cada línea. Eso hace que sea un mayor esfuerzo para cambiar, y más difícil de entender diffs.
Estoy desgarrado. Por un lado, alinear así puede hacer que el código repetitivo sea mucho más fácil de leer. Por otro lado, hace que sea más difícil de leer.
¿Cuál es su punto de vista sobre esto?
Estoy desgarrado. Por un lado, alinear así puede hacer que el código repetitivo sea mucho más fácil de leer. Por otro lado, hace que sea más difícil de leer.
Bueno, ya que hacer que el código sea comprensible es más importante que hacer que los diffs sean comprensibles, no deberías estar desgarrado.
En mi humilde opinión alinear líneas similares mejora en gran medida la legibilidad. Además, permite un corte y pegado más fácil con editores que permiten la selección vertical.
Como superviso fusiones diarias del código fuente, ... solo puedo recomendarlo en contra.
Es bonito, pero si lo haces de forma regular, el beneficio de "leer más fácilmente" es mucho menor que el esfuerzo necesario para fusionar ese código.
Como ese formato no se puede automatizar de manera fácil, el primer desarrollador que no lo siga activará fusiones no triviales.
No olvide que en la combinación de código fuente, no se puede pedir a la herramienta diff que ignore los espacios :
De lo contrario, "" y "" se verán igual durante la diferencia, lo que significa que no es necesaria ninguna fusión ... ¡el compilador (y el codificador que agregó el espacio entre las comillas dobles de String) no estarían de acuerdo con eso!
Con un buen editor, su punto es simplemente falso. :)
(Ver el modo "bloque visual" para vim)
PD: Ok, todavía tienes que cambiar cada línea pero es rápido y simple.
Esta es PRECISAMENTE la razón por la cual el buen Señor dio como pestañas: agregar un personaje en el medio de la línea no arruina la alineación.
Me gusta el primero y el último, pero no tanto el medio.
Nunca hago esto, y siempre lo recomiendo. No me importa que los problemas sean más difíciles de leer. Me importa que lleve tiempo hacer esto en primer lugar, y toma tiempo adicional cada vez que las líneas tienen que realinearse. Editar código que tiene este estilo de formato es exasperante, porque a menudo se convierte en un gran sumidero de tiempo, y termino gastando más tiempo formateando que haciendo cambios reales.
También impugno el beneficio de legibilidad. Este estilo de formato crea columnas en el archivo. Sin embargo, no leemos en estilo de columna, de arriba abajo. Leemos de izquierda a derecha. Las columnas distraen el estilo de lectura estándar y tiran de los ojos hacia abajo. Las columnas también se vuelven extremadamente feas si no están perfectamente alineadas. Esto se aplica a espacios en blanco extraños, pero también a grupos de columnas múltiples (posiblemente no relacionados) que tienen espaciado diferente, pero caen uno después del otro en el archivo.
Por cierto, me parece realmente extraño que su estándar de codificación no especifique la colocación de tabulaciones o corsé. Mezclar diferentes estilos de tabulación y colocaciones de corsé dañará la legibilidad mucho más que usar (o no usar) el formato de estilo de columna.
Personalmente prefiero la mayor legibilidad del código a expensas de diffs ligeramente más difíciles de leer. Me parece que, a la larga, una mejora en la mantenibilidad del código, especialmente a medida que los desarrolladores van y vienen, vale la pena la compensación.
Puede configurar su herramienta diff para ignorar el espacio en blanco (GNU diff: -w). De esta forma, sus diferencias omitirán esas líneas y solo mostrarán los cambios reales. ¡Muy útil!
Si planea usar una validación estándar de código automatizado (es decir, CheckStyle, ReShaper o algo así), esos espacios adicionales dificultarán la redacción y aplicación de las reglas.
Tuvimos un problema similar con diffs en contratos múltiples ... Descubrimos que las pestañas funcionaban mejor para todos. Configure su editor para mantener las pestañas y cada desarrollador puede elegir su propia longitud de pestañas también.
Ejemplo: Me gustan 2 pestañas espaciales para que el código sea muy compacto a la izquierda, pero el valor predeterminado es 4, por lo que aunque se ve muy diferente en cuanto a las sangrías, etc. vaya a nuestras distintas pantallas, los diffs son idénticos y no causan problemas con el control de fuente.
Yo nunca hago esto Como dijiste, a veces es necesario modificar cada línea para ajustar el espaciado. En algunos casos (como sus condicionales anteriores) sería perfectamente legible y mucho más fácil de mantener si eliminas el espaciado y colocas los bloques en líneas separadas de los condicionales.
Además, si tiene un resaltado de sintaxis decente en su editor, este tipo de espaciado no debería ser realmente necesario.
Hay algo de discusión sobre esto en el siempre útil Código Completo de Steve McConnell. Si no posee una copia de este libro seminal, hágase un favor y compre uno. De todos modos, la discusión está en las páginas 426 y 427 en la primera edición, que es la edición en la que tengo una mano.
Editar:
McConnell sugiere alinear los signos iguales en un grupo de declaraciones de asignación para indicar que están relacionados. También advierte contra alinear todos los signos iguales en un grupo de asignaciones porque puede implicar visualmente una relación donde no hay ninguna. Por ejemplo, esto sería apropiado:
Employee.Name = "Andrew Nelson"
Employee.Bdate = "1/1/56"
Employee.Rank = "Senator"
CurrentEmployeeRecord = 0
For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray)
. . .
Si bien esto no
Employee.Name = "Andrew Nelson"
Employee.Bdate = "1/1/56"
Employee.Rank = "Senator"
CurrentEmployeeRecord = 0
For CurrentEmployeeRecord From LBound(EmployeeArray) To UBound(EmployeeArray)
. . .
Confío en que la diferencia es evidente. También hay una discusión sobre cómo alinear las líneas de continuación.
Intento seguir dos pautas:
Use pestañas en lugar de espacios siempre que sea posible para minimizar la necesidad de reformatear.
Si le preocupa el efecto en el control de revisiones, realice primero los cambios funcionales , verifíquelos y realice solo cambios cosméticos .
La flagelación pública está permitida si se introducen errores en el cambio "cosmético". :-)
Mi postura es que este es un problema del editor: mientras usamos herramientas sofisticadas para mirar páginas web y cuando escribimos textos en un procesador de texto, nuestros editores de código todavía están atrapados en las edades ASCII. Son tan tontos como nosotros podemos hacerlos y luego, tratamos de superar las limitaciones del editor escribiendo elaboradores de códigos sofisticados.
La causa principal es que su compilador no puede ignorar las declaraciones de formato en el código que dicen "hey, esta es una tabla" y que los IDE no pueden crear una representación visualmente agradable del código fuente sobre la marcha (es decir, sin cambiar realmente uno) byte del código).
Una solución sería usar pestañas, pero nuestros editores no pueden alinear automáticamente pestañas en filas consecutivas (lo que haría mucho más fácil). Y para agregar daño a la ofensa, si te metes con el ancho de la pestaña (¡básicamente cualquier cosa! = 8), puedes leer tu código fuente pero ningún código de nadie más, digamos, el código de ejemplo que viene con las bibliotecas que usas. Y, por último, nuestras herramientas de diff no tienen opción de "ignorar espacios en blanco, excepto cuando cuenta" y los compiladores tampoco pueden producir diffs.
Eclipse puede al menos formatear asignaciones de forma tabular, lo que hará que los conjuntos grandes de constantes globales sean mucho más legibles. Pero eso es solo una gota de agua en el desierto.