Portada
mis comunidades
otras secciones
#1:
El límite de 80 columnas es porque el modo de texto por defecto en los PC es de 80x25. Es un criterio claramente obsoleto.
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.
#60:
#59 Sí, todos los días cojo mi impresora matricial de papel continuo e imprimo mi código C++17 para comentarlo con el equipo.
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.
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.
#13:
Que nadie haya comentado que las 80 columnas provienen del ancho de las tarjetas perforadas de IBM (diseño de 1928), que fueron un estándar de facto en su momento, deja claro que aquí mucho pantomima full de qué frikis somos pero la peña no tiene ni idea.
https://es.wikipedia.org/wiki/Tarjeta_perforada#Tarjeta_perforada_de_formato_de_80_columnas_de_IBM
https://es.wikipedia.org/wiki/Tarjeta_perforada#Tarjeta_perforada_de_formato_de_80_columnas_de_IBM
#5:
#1 al final el objetivo es ese, poder tener dividida la pantalla con split vertical y leer el fuente sin scroll horizontal.
Si las resoluciones que usáis van bien con 120, de lujo. Alguna vez he tenido que hacer cosas en terminal con alguna conexión de mierda (en plan minicom puerto de serie) y ahí era muy útil mantener los 80 caracteres
Si las resoluciones que usáis van bien con 120, de lujo. Alguna vez he tenido que hacer cosas en terminal con alguna conexión de mierda (en plan minicom puerto de serie) y ahí era muy útil mantener los 80 caracteres
#9:
#1 Yo tengo el límite a 132. 80 me parece acertado para resoluciones de 640x480, pero a estas alturas no tiene sentido.
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
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
Comentarios
El límite de 80 columnas es porque el modo de texto por defecto en los PC es de 80x25. Es un criterio claramente obsoleto.
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.
#1 al final el objetivo es ese, poder tener dividida la pantalla con split vertical y leer el fuente sin scroll horizontal.
Si las resoluciones que usáis van bien con 120, de lujo. Alguna vez he tenido que hacer cosas en terminal con alguna conexión de mierda (en plan minicom puerto de serie) y ahí era muy útil mantener los 80 caracteres
#5 Yo uso line wrap siempre que puedo, y lo primero que hago en cualquier ide es buscar el modo vi. No entiendo a la gente que hace scroll horizontal en los editores pudiendo verlo todo en la misma pantalla
#15 yo soy de vim también, pero el line wrap me molesta muchísimo. Lo mismo que el scroll horizontal. Es como que me confunde la navegación.
Si tengo que trabajar en código con este problema siempre ‘arreglo’ la sección donde me toca trabajar para que no haya líneas de 300 caracteres.
#17 Yo hago igual, no me gusta ni el line wrap ni el scroll horizontal, unas veces tengo configurado line wrap y otras veces no, sin criterio alguno, según me levanto, porque me dan por saco ambos a partes iguales.
Además yo soy de los de poner nombres_de_variables_entendibles y no ndve, pero intento no tener líneas largas.
#26 yo un día llevé al extremo lo de las variables entendibles y salían nombres tan largos que dejé de usarlo. Intento acortar las palabras siempre que puedo cnt, idx, descrip, nom_pag, nom_reg etc.
Además otro vicio que no me he podido quitar en la vida es programar en spanglish
#36 mientras las abreviaturas sean comprensibles no lo veo tan mal.
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.
#15 Yo no sé vosotros, pero yo en mi editor tengo habilitado el wrap que hace que las líneas largas la pinte en 2 y no haya nunca scroll horizontal.
#1 #5 #9 #27 El problema no solo es la pantalla, también lo son las hojas.
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.
#59 Sí, todos los días cojo mi impresora matricial de papel continuo e imprimo mi código C++17 para comentarlo con el equipo.
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.
#60 No te digo que se haga todos los días ni mucho menos, pero desde luego que se hace para porciones de código, varias veces al mes.
Evidentemente cada uno hará lo que quiera, como no puede ser de otra manera, pero aunque le venga mal para su caso.
#62 Nosotros las revisiones de código las hacemos siempre online. Las pocas veces que no es suficiente con el diff de git o el del IDE que use el que revisa, te llama a su pantalla y lo miráis entre los dos.
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)
#60 Imprimir tiene la ventaja de poder comentar con compañeros de forma más ágil y efectiva.
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.
#65 bueno, ya se te ha notado demasiado que eres un troll. Paso de ti.
#69 teniendo GitHub/GitLab la verdad es que no veo el caso de uso de una impresión ni que aporta de agilidad (sí aporta probabilidad de traspapelarlo, olvidarlo y falta de histórico visualizable por todo el equipo, así a bote pronto).
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
#97 en gitlab/github un momento se ponen varios comentarios y se hacen varios fixup! hasta que se arregla el problema.
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.
#65 y sin quemarte la vista. Después de horas mirando la pantalla se agradece poder mirar un papel. Además, en un papel se puede apuntar, marcar, tomar notas...
#59 #60 olicarca hace honor a su nombre
Sí, la verdad es que eso de imprimirse el código tampoco lo he visto nunca. Si discutimos algo es en la pantalla. Imprimir es más diagramas de flujo o clases, pero no código.
Algún proyecto sin embargo requiere mandar el código impreso como parte de la entrega. Medio amazonas se suele ir en ello
#71 hasta las impresoras matriciales mínimamente decentes de los años 80 tenían 136 columnas de "anchura de carro" que se decía.
Las impresoras de 80 columnas eran insuficientes para muchas aplicaciones. Pero oye, yo ya viví los 80. Ahora estoy en 2020.
#60 cómo añoro ese "pirriteo" a las 3 de la mañana, cuando tenía que imprimir un trabajo para el día siguiente en clase, que iba contando las líneas... ¡ya, ya casi está! ¡joder qué ruido mete la puñetera!
#76 era un ruido bastante insoportable, la verdad. En algunas oficinas hasta las tenían dentro de cajas insonorizadas. Menudos trastos del infierno, y que gasto de papel.
#60 yo sí suelo imprimir, pero lo saco por la láser, que va de lujo para eso.
#59 Impri-que?
#59 igualmente puedes imprimir en 132 columnas, no hay problema por eso. Eso sí, siempre imprimo con letra monoespaciada, para que sea más legible el código.
#72 En una hoja puedes meter las columnas que quieras, pero hace falta que luego se pueda leer. Ahí cada uno tendrá su opinión hasta qué punto la letra es suficientemente legible.
Lo de la letras monoespaciado, tiene que ser así, ahí no hay discusión, de igual manera en la pantalla.
#59 si tienes que imprimir en papel para comentar esto o aquello y no te valen los comentarios en la pantalla, algo estás haciendo MAL.
Por lo que eso de dar consejos a los demás queda un poco ridículo.
#92 No te estoy diciendo de imprimir algoritmos triviales, sino algoritmos con cierta complejidad (NP).
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.
#5 :set wrap
#1 Yo tengo el límite a 132. 80 me parece acertado para resoluciones de 640x480, pero a estas alturas no tiene sentido.
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
#1 He mirado en mi IDE y yo en java lo tengo puesto a 150 (por defecto venia mucho mas bajo). Pero es verdad que para los diffs algo menos vendría mejor.
#1 "El límite de 80 columnas es porque el modo de texto por defecto en los PC es de 80x25"
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)
#56 es impreciso porque hay más cosas a 80x25, pero erróneo no es. Tu cuando arrancas un Linux en texto estás a 80x25 si no has cambiado nada del modo de texto por defecto. En PC claro, porque Linux se empezó a desarollar para PC 386. La multiplataforma vino luego.
#57 Es incorrecto porque " el modo de texto por defecto en los PC", no tiene sentido por sí mismo y falta a la verdad si tienes en cuenta todos los casos. Aquí el problema es que creo que está reduciendo todo a algunas distribuciones de linux que conoces.
#61
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.
#68 los modos CGA del PC y clónicos eran 80x25 y 40x25. Yo siempre recuerdo el arranque en 80x25
#1 Es un error muy común pensar que los limites de 80 columnas son herederos de límitaciones físicas anticuadas.
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.
#89 el codigo tiene que ser corto, pero que sea concretamente 80 y no 79 o 81, no es coincidencia.
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.
#91 Has usado el hecho de que el criterio original esté obsoleto para justificar 120 columnas, yo te digo que lo que tenemos que evaluar es qué es más legible o usable. Nadie hoy en dia recomienda 80 caracteres ciegamente por "tradición", se hace porque es un estandar que funciona. Cada lenguaje tendrá su valor óptimo, pero no estará lejos de estos 80, que por cierto no se eligieron arbitrariamente si no porque son más legibles; más concretamente porque era la longitud típica de una linea en una máquina de escribir; de ahí saltó a las tarjetas perforadas, y de ellas a los terminales. En ningún caso es una limitación tecnológica sino una decisión consciente de cuál es un ancho de linea adecuado para que el ojo humano pueda trabajar con texto de manera eficiente.
#89 El error común es el que cometes tú. Es un hecho se debe a limitaciones técnicas. Aquí lo explican:
https://en.wikipedia.org/wiki/Characters_per_line
Y el hecho de que sea más fácil de leer es una consecuencia (y también obvia)
#89 Pero el número 80 sale de aquí
https://es.wikipedia.org/wiki/Tarjeta_perforada
#1 Es una buena medida, de hecho acabo de mirar el código en el que estoy trabajando y no excede de 120.
No obstante tengo comprobado que si una línea es lo suficientemente larga, la posibilidad de bug tiende a uno. Si tu código es limpio, seguramente es corto, auto descriptivo y fácil de debuggear.
#1 Las 80 columnas les vienen bien a los cegatos como yo, que necesitan un tamaño de letra tirando a grande. Los programadores jóvenes no se dan cuenta de eso, pero ya lo averiguarán. Aunque para ese entonces es posible que ya sea demasiado tarde para ellos.
Que nadie haya comentado que las 80 columnas provienen del ancho de las tarjetas perforadas de IBM (diseño de 1928), que fueron un estándar de facto en su momento, deja claro que aquí mucho pantomima full de qué frikis somos pero la peña no tiene ni idea.
https://es.wikipedia.org/wiki/Tarjeta_perforada#Tarjeta_perforada_de_formato_de_80_columnas_de_IBM
#13 menos mal que has venido a iluminarnos con tu sabiduría, tú que eres un friki de verdad TM
#16 Sí, habéis tenido mucha suerte, no siempre estoy de humor para reducir la ignorancia de la humanidad.
#20 se dice "refactorizar"
#20 Muchisimas gracias. Hasta hoy mi vida no tenía sentido.
#13 pues si tan friki eres y tanto sabes, también habrías comentado que las 80 columnas de las tarjetas perforadas vienen de que su creador (John M. Farwell) se inspiró en la obra "La vuelta al mundo en 80 días" de Julio Verne, el libro que estaba leyendo en ese momento.
#24 Eso es incierto, me acuerdo cuando estuve con él comentando la leyenda urbana, se moría de la risa.
#24 A ver si alguien nos explica por qué Julio Verne eligió 80 días para su novela. Creo que tirando del hilo podemos llegar a antes del Big Bang
#30 Es sencillo, ya que poner "La vuelta al mundo en casi 3 meses" no quedaba muy literario.
#13 Ya estamos repartiendo carnets?
#39 Tu a callar, disidente!
#13 Estabas quedando super bien dando un dato informativo y curioso, pero te las ha apañado para quedar como un prepotente
#43 No os merecéis otra cosa. Esto me pasa por mezclarme con el vulgo.
#13 No sé cómo he podido vivir 45 años sin saber esto.
#13 Por cierto, os dejo como ejercicio descubrir la relación entre las 80 columnas y el puerto HTTP.
#14 putos noobs
#21: C-x M-c M-butterfly... https://xkcd.com/378/
#7 Los programadores de hoy en día son unos pusilánimes. En mis tiempos se programaba con picos de voltaje.
#8 y en los míos, bobinando núcleos manualmente...
#14 Pfff... qué pringaos. Yo fui asesor técnico de Ada Lovelace.
#28 Y yo encargado de IT en la nave de los extraterrestres que trajeron la vida a la tierra.
#28 Ada no fue programadora, y mucho menos de ordenadores. Lo que pasa es que vende decir que fue la primera programadora de la historia, y termina calando en gente como tú.
#55 ¿Y cuál es esa realidad que nos están ocultando? Como comprenderás, no voy a creerme lo primero que me diga un don nadie que ni siquiera aporta información.
#67 jajaja, entonces tú das por hecho que ada fue la primera programadora de la historia, verdad? Seguramente porque en la wikipedia te dicen que un "algoritmo" era "interpretado" por una "máquina".
#73 Te lo repito. Menos risas y menos dártelas de listo y aporta información sobre lo que dices.
O mejor aún, ni te molestes. No hablo con listillos con el cerebro de un niño de 4 años. Al ignore.
#8 Los verdaderos programadores usan mariposas!!!...
https://imgs.xkcd.com/comics/real_programmers.png
#4 6 columnas debería ser más que suficiente para todo. Y el que necesite más, que programe en assembler.
#6 Más de un bit por línea te coloca en mi lista "flojos de espíritu".
Yo he pasado de los 140 caracteres en Python a 120, y de ahí bajé otra vez a 100. Me he dado cuenta con el tiempo que líneas demasiado largas son un problema en general para la legibilidad, porque terminas con un código muy estrecho en la mayoría de líneas y luego unas pocas se van a la derecha una barbaridad. Eso hace que a veces dejes pasar por alto una parte importante del código.
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".
#32 Yo con menos de 120 en java es imposible. En cuanto tienes un set dentro de un if, ya se te va a dos lineas. O si el if tiene un AND/OR minimamente largo. Pero es cierto que java es muy 'verbose'
En otros lenguajes no dudo que 100 funcione.
#32 140 en Python me parece una barbaridad. La PEP-8 dice un maximo de 79 carácteres. Yo intento respetar ese límite pero alguna vez lo supero.
#50 en el equipo usamos 120 para todo el proyecto, incluido python, y perfecto.
Llámame antiguo, pero al pan pan y al C, las 24 columnas.
A partir del C, ya podéis utilizar la barra de desplazamiento a la derecha lo que os dé la gana.
#3 24 columnas? Un poquito corto, no?
#4 Siempre me equivoco entre filas y columnas, quise decir hileras... jajajaj
#3 Los terminales VT que eran los que se usaban en los PDP donde se desarrolló el lenguaje C ya tenían 80 columnas por 24 líneas desde el VT-52 (1973)
#3
Es Spectrum tenía más: 32
#3 e indexaciones de 4 espacios
Simplemente han permitido una excepcion para hacer la linea de mas de 80 caracteres si cuando cortas la linea queda como el culo. Nada mas. El limite sigue siendo 80.
Es casi lo mismo que figura en la guia de estilo de Google que usamos en mi empresa: https://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.
#53 En mi proyecto también se recomienda seguir a 80 columnas y la verdad es que el primer día que trabaje desde de cada y abrí el ide en mi monitor 4K me vino a la cabeza un “alquilo espacio para publicidad”.
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.
#85 eso es lo que ha pasado, que Linus ha cambiado por fin su torre por un AMD con tropecientos núcleos que solo el procesador vale más que mi pepinaco de torre, y monitor 4k y claro a tocar las narices a todo el mundo..
Palabra de dios Linus.
#2. Un respeto a los ingenieros de software, y aún más con el curriculum de Linus Torvalds.
#33 En la mía lo cambiamos antes que Linus
Con dobles pantallas grandes y buenas resoluciones nos sobra espacio para editar varios ficheros y responder a comentarios de meneame a la vez.
#40 Hoy es festivo en Bayern
Yo tambien tengo varias pantallas. Pero son para maquinas virtuales. Asi
1: Desktop.
2: Windows 2 ficheros.
3: Linux 2 ficheros.
Me pongo a mirar un código fuente mío y... hasta 400 caracteres, y eso que mi indentación es estrecha.
#53 Pa lo que me queda aqui. Pero da igual, en mi ordenador privado tambien lo hago.
Pues yo voy a seguir a 80, lo diga Linus o quien sea.
#23 Te va a dar igual, cuando pilles cambios de otros, estos estarán a 120, porque ya usamos pantallas de verdad y el límite de 80 se nos queda corto.
#27 Nop. Coding rules en mi empresa: 80.
Y peleare por ello. Puedo editar mas ficheros a la vez.
#33 Mejor pelea por monitores decentes. En un monitor 2560x1440 con 3 terminales abiertos tengo un ancho de de 104 caracteres.
#23 Linus lo que ha dicho es que si necesitas pasarte de las 80 columnas para no tener que meter tantos avances de línea, que lo hagas. No que debas dejar de usar 80 columnas.
¿Qué será lo próximo?¿Sustituir las tabulaciones por espacios?
#81 buena idea!
Han sellado su muerte. Éste es el año de Hurd en el escritorio.
sin duda un antes y un después en la historia de la humanidad.
yo no se porque todo el mundo dice que los 80 caracteres se han quedado cortos… personalmente creo que son muy útiles y especialmente en diversos entornos. Está claro que si hay una linea que tiene que ser más que sea, pero la lectura a 80 es bien maja y al menos a mi me facilita la lectura.
#34 es que lo de que "si una linea tiene que ser más larga que sea" es precisamente lo que acaban de aprobar. Que sea más larga, hasta 100.
Antes era límite duro, no podías pasar de 80 y punto. Tenías que cortar usando \
Existen multitud de estudios sobre el ancho óptimo que debe tener un texto para una legibilidad óptima, y todos están de acuerdo en que estaría entre 50 y 75 caracteres. ¿Nunca os habéis preguntado por qué los libros tienen el ancho que tienen?¿O por qué los periódicos se organizan en columnas?
Pasar de 80 caraceres a 120 es una malísima decisión desde el punto de vista de la legibilidad del código.
#37 leer código no es como leer un libro de texto. En un texto normal no pierdes espacios por identaciones en una class, namespace, etc, ni adornas la frase con "virtual (tu frase aqui) . const noexcept"
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.
#37 El código tiene de por sí una sangría y elementos de la sintaxis que se repiten constantemente . Si además es de calidad suele ser mayormente corto. Qué algunas líneas lleguen a máximo de longitud, no debería afectar de forma relevante la legibilidad de todo el código.
Un ancho de 80 también tiene su propósito para intentar evitar escribir código espagueti
La verdad es que en C hay que tener cuidado, el código debe ser legible, por ejemplo si usas variables globales debes añadir comentarios de donde las vas a usar, modificar etc. Estos comentarios aclaratorios, deben aclarar y no estorbar... Pero vamos poner un limite así lo veo exagerado, han hecho bien en quitarlo.
Bien.
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.