¿Por qué la sangría en las líneas vacías es mala?

Cada proyecto de software libre que conozco tiene reglas contra los espacios en blanco finales 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, lanza advertencias de todos modos. Así que mi pregunta es: ¿Por qué esas pestañas dentro de la sangría actual son malas?

No estoy buscando respuestas como "Siempre se hace de esta manera". Supongamos que la sangría se realiza consistentemente en todo el proyecto en cuestión.

Author: Max, 2011-05-07
Source

3 answers

Probablemente se deba a que combinar parches con espacios en blanco inútiles es más difícil de lo que debería ser.

diff(1) y patch(1) trata los espacios y las pestañas como contenido importante. (Pregunte a cualquier archivo fuente Makefile o .py they ellos son importantes!) Y si su "línea en blanco" tiene cuatro espacios en ella, y mi "línea en blanco" tiene ocho espacios en ella, cualquier intento de compartir parches entre nosotros fallará por razones muy triviales.

Concedido, si al por mayor cambiar la sangría de un bloque de código, tendrás que ir a algún trabajo para hacer que se apliquen parches de todos modos. Pero tratar de rastrear fallas de fusión en líneas que parecenen blanco es doloroso. (He desperdiciado demasiado de mi vida haciendo precisamente eso. Sí, vim listchars puede ayudar, pero leer código con listchars encendido todo el tiempo es también molesto.)

Así que la gente estandariza en sin espacios en blanco al final. Puede que no tenga sentido preocuparse por una docena de bytes perdidos aquí o allá de un desde el punto de vista del almacenamiento, pero realmente facilita la fusión de parches. Probablemente podríamos estandarizar la adición de espacios en blanco finales, exactamente como ha sugerido, y ser tan felices, pero también podríamos estandarizar el enfoque que es lo más parsimonioso posible.

 46
Author: sarnold,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-05-06 23:24:21

Esto también puede ser grosero para los usuarios de vi que están acostumbrados a usar la navegación de párrafos para saltar a través del código. A veces hago esto cuando vi y es bastante sorprendente cuando omito varias funciones porque los caracteres invisibles dijeron que esto es en realidad parte del párrafo anterior.

 4
Author: Dustin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-05-07 07:54:25

Creo que se reduce a "no hay bytes sorpresa ocultos redundantes en su código plz".

Como señala @sarnold, los bytes sorpresa redundantes hacen que los parches y las diferencias sean innecesariamente desordenados.

 1
Author: Már Örlygsson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-05-06 23:47:44