c++ - significa - linea indentada
¿Por qué la indentación en líneas vacías es mala? (3)
Todos los proyectos de FOSS que conozco tienen reglas contra el espacio en blanco al final en el código. Pero creo que es muy natural continuar la sangría actual en la siguiente línea:
int main()
{
....int a = 42;
....
....return a;
}
Pero git, por ejemplo, arroja advertencias de todos modos. Entonces mi pregunta es: ¿por qué esas pestañas dentro de la sangría actual son malas?
No estoy buscando respuestas como "Siempre se hace así". Supongamos que la sangría se hace de manera consistente en todo el proyecto en cuestión.
Creo que todo se reduce a "no hay bytes sorpresa ocultos redundantes en tu código por favor".
Como señala @sarnold, los bytes sorpresa redundantes hacen que los parches y diffs sean innecesariamente desordenados.
Esto también puede ser grosero para los usuarios de vi que están acostumbrados a utilizar la navegación de párrafo para saltar por el código. A veces hago esto cuando vi y es bastante sorprendente cuando omito varias funciones porque los personajes invisibles dicen que esto es en realidad parte del párrafo anterior.
Probablemente sea porque fusionar parches con espacios en blanco inútiles es más difícil de lo que debería ser.
diff(1) y patch(1) tratan espacios y pestañas como contenido importante. (Pregunte a cualquier archivo fuente Makefile o .py : ¡ son importantes!) Y si su "línea en blanco" tiene cuatro espacios, y mi "línea en blanco" tiene ocho espacios, cualquier intento de compartir parches entre nosotros fallará por razones muy triviales.
Por supuesto, si cambia al por mayor la sangría de un bloque de código, tendrá que trabajar para que los parches se apliquen de todos modos . Pero es doloroso tratar de rastrear fallas de fusión en líneas que parecen vacías. (He gastado demasiado de mi vida haciendo eso. Sí, vim listchars puede ayudar, pero leer código con listchars todo el tiempo también es molesto).
Entonces la gente se estandariza sin espacio en blanco al final . Puede que no tenga sentido preocuparse por una docena de bytes perdidos aquí o allá desde el punto de vista del almacenamiento, pero realmente facilita la fusión de parches. Probablemente también podríamos estandarizar la adición de espacios en blanco al final, exactamente como lo sugirió, y ser igual de felices, pero también podríamos estandarizar el enfoque lo más parsimonioso posible.