151 meneos
1814 clics
Este envío tiene varios votos negativos. Asegúrate antes de menear
El kernel de linux abandona el estilo de programación de 80 carácteres por línea [ENG]
El kernel de Linux ha desaprobado oficialmente su estilo de codificación de que la longitud de las líneas de código cumple con 80 columnas como el "límite preferido fuerte". El kernel de Linux, como muchos proyectos de código abierto de larga data, tiene una pauta de estilo de codificación que dice que las líneas de código deben ser de 80 columnas o menos, pero ahora que, aunque todavía se recomienda, ya no será tan obligatorio. Esto se debe a que Linus Torvalds comentó el viernes que los saltos de línea excesivos son malos y está en contra.
|
comentarios cerrados
Aún así yo no lo veo tan mal para C, pero en C++ se queda corto, nosotros hemos cambiado a 120 columnas para C++.
Más de 120 podría no permitir un diff side by side en Gitlab o GitHub por ejemplo.
Aún así yo no lo veo tan mal para C, pero en C++ se queda corto, nosotros hemos cambiado a 120 columnas para C++.
Más de 120 podría no permitir un diff side by side en Gitlab o GitHub por ejemplo.
A partir del C, ya podéis utilizar la barra de desplazamiento a la derecha lo que os dé la gana.
Esto son 132 caracteres:
El kernel de Linux ha desaprobado oficialmente su estilo de codificación de que la longitud de las líneas de código cumple con 80
80 serían esto:
El kernel de Linux ha desaprobado oficialmente su estilo de codificación de que
#3 24 columnas... ostras:
El kernel de Linux ha d
me corto las venas
Es Spectrum tenía más: 32
es.wikipedia.org/wiki/Tarjeta_perforada#Tarjeta_perforada_de_formato_d
Además yo soy de los de poner nombres_de_variables_entendibles y no ndve, pero intento no tener líneas largas.
Una gran ventaja de forzar a líneas cortas es que obligas a que el código tenga una forma más parecida a los libros de texto, donde hay frases y párrafos. Es más natural de leer. Y como habéis comentado otros, para hacer diffs o tener dos paneles horizontales, es muy importante también.
Al final opté por tener dos "gutters" en el IDE, uno para 80 caracteres y otro para 100. De ese modo, intento que entre en 80 y si es poco legible voy a los 100 caracteres. Aunque al final lo mejor es usar formateadores de código (en Python uso Black), especificarles un ancho y olvidarse.
Me fastidia que haya tenido que ser Torvalds el que haya tenido que decir "basta" de golpe en el kernel. Hasta entonces todos estaban "muy orgullosos" de su límite de 80 caracteres y tabulación a 8 espacios. Me parece una falta de previsión; lo suyo hubiera sido cambiar las reglas hace un par de años de forma proactiva y no "porque Torvalds no ve ese PR legible a 80 caracteres".
Y peleare por ello. Puedo editar mas ficheros a la vez.
Además otro vicio que no me he podido quitar en la vida es programar en spanglish
Pasar de 80 caraceres a 120 es una malísima decisión desde el punto de vista de la legibilidad del código.
Con dobles pantallas grandes y buenas resoluciones nos sobra espacio para editar varios ficheros y responder a comentarios de meneame a la vez.
Antes era límite duro, no podías pasar de 80 y punto. Tenías que cortar usando \
Nosotros tenemos todo el legacy a 80 columnas, hemos cambiado a 120 precisamente porque mejora la legibilidad en C++. Podría ser 100, pero menos de 100 empeoras, no mejoras.
Yo tambien tengo varias pantallas. Pero son para maquinas virtuales. Asi
1: Desktop.
2: Windows 2 ficheros.
3: Linux 2 ficheros.
Eso es muy impreciso por no decir erróneo.
Si hubieras dicho de las consolas (ni siquiera de los emuladores de consola, que es lo que usa hoy en día)
Cuando te toca imprimir un archivo para comentarlo con alguien, para hacer algún tipo de comprobación formal, ...
que cada línea te quepa en una misma fila es la clave.
Acostumbraos a escribir de forma concisa y clara.
Mira, cada uno tiene que encontrar el formato de ancho, estilo de codigo etc, que mejor le venga a SU proyecto y a SU caso de uso.
PD: Hará 25 o 30 años que no imprimo un código fuente. Sin exagerar.
Evidentemente cada uno hará lo que quiera, como no puede ser de otra manera, pero aunque le venga mal para su caso.
También sirve muy bien para hacer verificación formal de algoritmos.
Y muchos otros casos.
Entiendo que no lo hagas, también hay gente que no hace ni un mísero test unitario. E incluso hay software que termina funcionando.
El mantenimiento ya es otra historia.
Código fuente en papel no veo desde hace 7 años, y me acuerdo perfectamente porque odiaba ese proyecto, ese equipo y esa metodología (no por lo de imprimir, pero era un plus)
Los PC por lo menos en la época cuando se empezó a escribir Linux, arrancaban siempre en 80x25 con total seguirdad. Porque había muchos programas de MSDOS, yo mismo los hice, que dibujaban directamente en el buffer de texto y asumían 80x25.
Seguro que hasta puedo encontrar especificaciones formales que dicen que un PC compatible arranca en 80x25. No me trolees, anda.
Las impresoras de 80 columnas eran insuficientes para muchas aplicaciones. Pero oye, yo ya viví los 80. Ahora estoy en 2020.
Lo de la letras monoespaciado, tiene que ser así, ahí no hay discusión, de igual manera en la pantalla.
O mejor aún, ni te molestes. No hablo con listillos con el cerebro de un niño de 4 años. Al ignore.
Lo siguiente es usar tabs en vez de espacios, los primeros más flexibles que los segundos y sin ninguna desventaja frente a los segundos.
Que tampoco es cuestión de hacer líneas a 200 columnas, pero a día de 80 columnas se hace justo, especialmente si entre otras manías está la de usar nombres de variable muy largos, al final se acaban metiendo saltos de línea y la legibilidad para mi criterio empeora.
Pero siempre que no haya problemas creo que usar palabras completas y nombres descriptivos ayuda y no solo a la comprensión en el futuro si no a detectar código que es demasiado largo, rebuscado y poco legible pero se escondía tras abreviaturas que lo hacían parecer más conciso de lo que realmente era.
He visto demasiadas veces usar abreviaturas como quien mete el polvo bajo la cama, a ver si nadie se da cuenta.
Es casi lo mismo que figura en la guia de estilo de Google que usamos en mi empresa: google.github.io/styleguide/cppguide.html#Line_Length
80 characters is the maximum.
A line may exceed 80 characters if it is
a comment line which is not feasible to split without harming readability, ease of cut and paste or auto-linking -- e.g., if a line contains an example command or a literal URL longer than 80 characters.
a raw-string literal with content that exceeds 80 characters. Except for test code, such literals should appear near the top of a file.
an include statement.
a header guard
a using-declaration
A mi personalmente me gusta el limite de 80 para C++ porque asi puedo tener una columna con el codigo, otra con el .h y otra con unit tests.
El límite de 80 columnas tiene que ver con la legibilidad y la usabilidad: se lee mejor el código en lineas cortas que en largas. Se puede comparar side-by-side código corto, y no largo. El número de columnas es al gusto; no tiene que ser 80, pero 80 es un valor perfectamente razonable.
imgs.xkcd.com/comics/real_programmers.png
Tampoco he dicho que esté en contra. Solo que para algunos proyectos (lenguajes, estilo de código, etc) puede ser más adecuado 120 que 80, por los mismos criterios de legibilidad. Si te pasas de estrecho perjudicas la legibilidad.
Hay lenguajes más "anchos" que otros. Programar C++ moderno a 80 puede ser como programar C a 70 o menos. Eso también hay que tenerlo en cuenta, no hay un ancho universal.
No sé, en ensamblador tirarías bien con 50 lineas.
Por lo que eso de dar consejos a los demás queda un poco ridículo.
También digo que sirve para hacer verificación formal de algoritmos.
Por tanto, sí, permíteme que deje en evidencia tu desconocimiento y dar consejos a quien quiera.
Hace años que hasta la discusión más básica en los equipos que he estado (tanto en una posición de liderazgo como de dev) transcurre en slack-gitlab (o si es una memez levantando el culo de la silla un segundo.
Y, en momentos como este donde el teletrabajo es generalizado, se agradece el tener esas mecánicas y procedimientos ya asimilados.
Vaya, parece que #_65 me tiene en ignore, habrá dicho alguna tontería como esta antes
Imprimir el código me parece arcaico. Antes en el pleistoceno, lo hacíamos, en papel continuo, y nos tirábamos literalmente en el suelo de la oficina con un rotulador, a repasar. Antes se tardaba tanto en hacer los cambios y probarlo que era incluso la forma rápida de corregir.
Pero es que o me falla mucho la memoria o la impresora que usábamos para imprimir en papel continuo era de 135 columnas. De 80 estoy casi seguro que no, eso eran las domésticas baratas.