Este es un tema muy subjetivo, pero puede tomar algunas señales de 1000 años de historia tipográfica.
La investigación se ha hecho en espacios en blanco en tipografía, pero menos en el código. Pero puede suponer que muchos de los hallazgos básicos en legibilidad y comprensión también se aplican al código. Este estudio, Reading Online Text: A Comparison of Four White Space Layouts, muestra que el espaciado vertical adecuado con grandes márgenes aumenta la comprensión, pero ralentiza la velocidad. Para el código, se puede suponer con seguridad que la comprensión es más importante que la velocidad. Entonces, podría decir objetivamente, más espacio es mejor para el código. Pero cuando te adentras en los detalles del tamaño de las pestañas y el posicionamiento del corsé, se vuelve muy subjetivo. En el código, los márgenes son sangría, los párrafos son funciones y bloques de código, y los períodos son saltos de línea, llaves, parens, etc.
Cuando se comienza a preguntar a los programadores qué formato de espacio en blanco es más legible, las respuestas están en todo el espectro. Lo mejor que puedes hacer es buscar generalidades que parezcan universales.
Tales como:
- espacios en blanco de venta antes y después de los bloques de código, como funciones y clases
- poner espacios en blanco antes y después de agrupaciones lógicas de código dentro de los bloques
- largos bloques de código con ningún verticales los espacios en blanco son más difíciles de leer
- bloques largos de código sin indentación son más difíciles de leer
- largas líneas de código sin espacios en blanco horizontales son más difícil de leer
Creo que la mayoría de los programadores estarán de acuerdo con esas afirmaciones.
Ejemplo (pseudo-código):
thisismore(difficult<toread)because,itsall-smushed{together}
this-is-less (difficult < to-read) because, it's-not-all - smushed { together }
para tocar en sus últimos cuatro puntos:
de denominación de variables:
Esto es tan subjetivo como espacios en blanco, pero de nuevo se puede mirar a tipografía para pistas. La tipografía tiene fuentes serif, mayúsculas que comienzan oraciones, períodos que terminan oraciones y un espacio después de puntos. Todas estas cosas son para permitir que tus ojos hagan la transición entre las palabras y las oraciones. Con las variables, la claridad es importante, por lo que a menudo son nombres de varias palabras. Para que sus ojos los lean fácilmente, algo debe alertarlos de que ha comenzado una nueva palabra.
Esto es más difícil de leer (para la mayoría de la gente):
que éstos:
- mi larga nombre-variable-
- myLongVariableName
- my_long_variable_name
- MY_LONG_VARIABLE_NAME
Ahora cuál de ellos es mejor o más legible es subjetiva, y puede estar siempre. Pero lo importante es que algo separe las palabras.
sangría horizontal:
código que no se sangría en todo es más difícil de leer que el código que es. Decadencia demasiado pequeña y tus ojos tienen problemas para distinguir bloques. Demasiado grande y desperdicia espacio y no agrega más claridad. En algún lugar entre cuatro y ocho parece estar bien basado en las líneas de código de once mil millones escritas usando esos tamaños.
Alineación horizontal:
Una vez más, la tipografía al rescate. Las listas de elementos alineados en columnas son más fáciles de leer. Para los datos de elementos de lista que son más largos que una o dos palabras o números (como oraciones), se utilizan listas con viñetas. Para datos de texto, se usan columnas alineadas a la izquierda. Para datos numéricos, se usan columnas alineadas a la derecha. Puede aplicar estos principios al código. Las listas con viñetas se pueden ver como bloques de código, todos alineados al mismo nivel de sangría. Las variables son datos textuales, por lo que la alineación izquierda sería más fácil de leer. Si los valores que estaba asignando fueran numéricos, la alineación correcta sería lo mejor.
Esto es más difícil de leer (para la mayoría de la gente):
var oneVariable = 10023, a = 370,
p = 4,
answerToLife = 42,
openThePodBayDoorHal = false;
que esto:
var oneVariable = 10023,
a = 370,
p = 4,
answerToLife = 42,
openThePodBayDoorHal = false;
Y esto es probablemente más fácil:
var oneVariable = 10023,
a = 370,
p = 4,
answerToLife = 42,
openThePodBayDoorHal = false;
vertical y distancia entre ejes
Im agine todo este post sin espacios entre párrafos. Casi todos pueden estar de acuerdo en que sería más difícil de leer y entender. Ahora, muchos podrían argumentar que más espacio entre las secciones sería aún mejor. En la tipografía, las secciones se delinean con encabezados que tienen un tamaño de fuente más grande y más espacio vertical (como se ve en HTML con H1, etc.). En el código, tenemos un tamaño de letra, así que tenemos que trabajar con espacios en blanco y cualquier concepto de refuerzo que utilice el lenguaje (si lo hay). Al igual que el espaciado horizontal, más es mejor que menos. Las características específicas de lo que eso significa son subjetivas, pero en la mayoría de los lenguajes, los programadores se instalan en una convención para ese idioma que usa la mayoría de las personas. Si está definiendo su propio idioma (o estándar de codificación), puede establecer la convención.
Lo más importante, no importa cuál sea el estándar, es que es usado consistentemente en todo su código. Esto es mucho más importante que los detalles del estándar. El código formateado consistentemente es mucho más fácil sin importar el estándar.
Busque typography readability studies para obtener más información.
WRT camelCase vs. snake_case, depende de la mayúscula/minúscula del idioma. En C puede 'ejecutar' una función de función de nombre de sitio donde en PHP la función acamelcased funcionará igual de bien. Entonces, para idiomas que no distinguen entre mayúsculas y minúsculas, el uso de guiones bajos es probablemente más legible en la práctica. – Bink