¿Cómo seguir las mejores prácticas del límite de 80 caracteres al escribir el código fuente?

Entonces, como saben, hay una mejor práctica que dice

Limite una fila de código fuente en 80 caracteres.

Aquí hay 2 enlaces:

¿Por qué 80 caracteres es el límite 'estándar' para el ancho del código?

¿Sigue siendo relevante el límite de 80 caracteres en tiempos de monitores de pantalla ancha?

Y estoy seguro de que puedes multar más si buscas esta mejor práctica.

Pero encuentro esto extremadamente difícil, aquí hay un ejemplo de ejemplo:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference

Entonces sangra cada clase y cada método y cada declaración.

Y ya estoy en la columna 60 al final de la última 'e' que tengo en 'myReference'.

Me quedan 20 espacios, en realidad llamo al constructor y asigno el objeto a la referencia que tengo.

Quiero decir, esto realmente se ve mejor:

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> myReference 
                = new HashMap<String, List<MyInterfaceHere>>(); 

¿Cuál es la mejor práctica aquí?

La mejor práctica debe ser "limitar la longitud de una línea para que usted, todos sus colegas y todas las herramientas que esté utilizando estén contentos", más un poco de sentido común. 80 caracteres parece ser muy bajo y tiende a reducir la legibilidad. Una vez he sido totalmente engañado por una línea como esta:

/* Very long comment to the end of the line */ realCode ();

donde la llamada a la función no era visible en la pantalla (tampoco era visible en la pantalla de ningún colega) sin ninguna indicación.

Configuré mi editor para mostrar un margen de 100 columnas, además de volver a envolver el código en la pantalla, para que todo esté siempre visible durante la edición, y las líneas demasiado largas tienden a dividirse manualmente en dos o, a veces, más líneas. Ore para que su editor formatee bien las declaraciones divididas si realiza el formateo automático. Use un estilo de codificación que no conduzca a declaraciones profundamente anidadas. (Algunas personas crean un nido de veinte sentencias if seguidas de una cola de veinte más que conduce a una sangría profunda de 200 caracteres, y nadie puede descubrir qué más pertenece a qué if).

En su caso particular, Swift inventó una forma de evitar esto: una variable "let" (que es casi lo mismo que "final" en otros idiomas) debe tener asignado un valor exactamente una vez antes de usarse, pero no necesariamente en la declaración , para que pueda dividir su problemática línea en dos declaraciones independientes.

PD. He encontrado líneas, en código real escrito por humanos, que tenían más de 400 caracteres. En otras palabras, tendría que desplazarse por edades para leer el resto de la línea, incluso en un monitor de 24 pulgadas. No me hizo gracia :-(

Sí, se ve mejor. Es por eso que el "¡No uses líneas demasiado largas!" La máxima es muy fuerte.

En cuanto a las mejores prácticas, nunca, nunca uso estas expresiones de constructor horriblemente largas. Siempre usaría

public class MyClass {

    public void myMethod() {

        final Map<String, List<MyInterfaceHere>> yReference = newMap();

para algún valor adecuadamente definido, importado estáticamente de newMap(). Considero un grave defecto en Java que no tenga una versión incorporada.

El objetivo no es "mantener líneas hasta 80 caracteres". El objetivo es "hacer que su código sea fácil de leer y comprender". El límite artificial de 80 caracteres ayuda a la legibilidad, pero no es una regla difícil y rápida a menos que su equipo decida que sí.

Solicitó la mejor práctica, y la mejor práctica es "centrarse en hacer que el código sea lo más legible posible". Si eso requiere más de 80 caracteres, que así sea.

No tengas miedo de presionar la tecla Retorno. La mayoría de los lenguajes modernos (incluido Java como en su ejemplo) están bastante contentos con las declaraciones que se ejecutan en varias líneas.

Solo piense un poco sobre dónde rompe las líneas, y puede obtener algo que se ajuste a un límite de 80 columnas y que siga siendo perfectamente legible. Las convenciones oficiales de codificación de Java incluso especifican lugares preferidos para romper líneas.

Bien hecho, una línea cuidadosamente dividida es mucho más legible que una que desaparece del costado de la pantalla.

Si aplica el largo / ancho de línea del código, use una herramienta.

• Resharper
• Asistencia visual
• etc.

Los desarrolladores deciden cuál es una longitud razonable (80, 120, 200, etc.), configuran esa opción en la herramienta.

Después de eso, simplemente escriba el código como lo haría normalmente sin tener en cuenta qué tan ancha o larga es la línea. Una vez que esté funcional y terminado, haga clic con el botón derecho y elija Limpiar código o una opción similar. La herramienta formateará el código tal como lo indicó y dividirá las líneas largas como se indica.

Sin sentido y fácil, y cada archivo fuente se formateará de la misma manera.

El límite de 80 caracteres puede ser demasiado corto en estos días, pero ayuda. Estoy de acuerdo con todas esas opiniones en que el código también debe estar bien formateado. por ejemplo, código

/ * Comentario muy largo hasta el final de la línea * / realCode ();

puede estar dentro de 80 chr pero crea confusión ya que los comentarios y las opciones de código están en la misma línea.

Adherirse al límite de 80 chr o no es una opción individual, pero si las cosas son visibles en una sola toma, siempre brindará una visión y un sentimiento cómodos a los programadores y otros revisores también.