Bien, lo hace? ¿Se considera una mala práctica?

OMI, es menos legible. Odio tener que desplazarme hacia la derecha, luego hacia la izquierda, derecha, izquierda, etc. Hace que la codificación sea más dolorosa y a veces me confunde.

Por ejemplo, cada vez que estoy codificando una cadena larga, haré lo siguiente ...

bigLongSqlStatement = "select * from sometable st inner join anothertable at" +
"on st.id = at.id" +
"and so on..." +
"and so on..." +
"and so on..."

Sí, de hecho lo hace, tanto en el sentido literal como en el sentido general.

Me gusta hacer diferencias de código de lado a lado, y las líneas demasiado anchas lo hacen más difícil:

Los lenguajes como Scala con cadenas entre comillas triples le permiten construir una cadena a partir de muchas líneas sin el gasto de tiempo de ejecución, comillas desagradables y signos más (como se ve en su ejemplo) de unir partes de una cadena.

Sí, creo que 80 caracteres por línea son razonables y de uso común.

¡Es una pregunta realmente importante para mí! He trabajado 7 meses en una computadora portátil de 13 "con colegas que tienen monitores de escritorio de 24", y me encontré pasando mucho tiempo acortando líneas para terminar con algo legible.

80 columnas es un poco pequeña en muchos casos (excepto si está trabajando en un terminal con vi la única opción;)), pero más de ~ 150 es demasiado (ver más abajo).

Eso es para la pura pregunta de 'legibilidad'.

Ahora, para la parte de 'buenas prácticas', a menudo encuentro que tales líneas largas tienen fallas, es decir, que tienen alguna parte que debe extraerse en una variable temporal, o que está duplicada, por ejemplo (ObjectiveC, fragmento común en la programación de iPhone) :

CGPoint point = CGPointMake(someOtherView.frame.origin.x + someOtherView.frame.size.width, someOtherView.frame.origin.x + someOtherView.frame.size.height);

Tenga en cuenta que esto puede volverse aún más desagradable cuando se trabaja con vectores o matrices tridimensionales.

Ejemplo reescrito:

CGRect frame = someOtherView.frame;
CGPoint origin = frame.origin;
CGSize size = frame.size;
CGPoint point = CGPointMake(origin.x + size.width, origin.x + size.height);

Esto ahora se ajusta en una pantalla más pequeña, más fácil de depurar usando un IDE o alguna escritura en la salida estándar, e incluso podría ser más rápido, dependiendo del costo de la invocación del método / propiedad. Esto es un poco forzado, por supuesto, la mayoría de los ejemplos del mundo real son mucho más complejos ...

No siempre.

Solo para agregar una vista alternativa, cuando leo el código, a menudo puedo entender lo que está haciendo la línea de código sin tener que leer la línea completa. Si puedo leer el nombre del método pero los parámetros del método se derraman de la pantalla, normalmente no me preocupo, ya que puedo decir solo por el nombre del método cuál es la intención de esa línea de código. Si algunas líneas de código se derraman de la pantalla, creo que la compensación de tener que desplazarse horizontalmente (palabra importante allí) vale la pena para el código más compacto. A veces encuentro que el código de una sola línea de varias líneas me distrae, ya que tengo que juntar mentalmente qué código va con cada declaración.

A menudo, las líneas de código que se extienden horizontalmente tienen sus bits importantes a la izquierda (visibles) y los bits menos importantes a la derecha (fuera de la pantalla), por lo que para mí esto mejora la legibilidad ya que puedo escanear el código hacia abajo principalmente viendo el bits importantes en cada línea en lugar de la alternativa de tener los bits de código menos importantes de una línea demasiado larga que ocupa el espacio del lado izquierdo visualmente importante en la (s) línea (s) siguiente (s).

Habiendo dicho todo eso, ciertamente no me gustaría desplazarme horizontalmente con mucha frecuencia, pero encuentro que esto es un problema menor en estos días de monitor de pantalla ancha.

Si lo hace.

Por cierto una propina. Si está utilizando un lenguaje con cadenas de varias líneas (prácticamente todos los lenguajes de secuencias de comandos los tienen) e incluye SQL largo, realmente ayuda a la legibilidad para colocar el SQL en una cadena de varias líneas utilizando reglas de formato consistentes para el SQL. Consulte http://bentilly.blogspot.com/2011/02/sql-formatting-style.html para conocer el estilo de formato que uso.

No lo hace

Tengo un editor No solo tiene ajuste de línea, sino que también tiene sangría de ajuste de línea , lo que (si la pantalla tiene 100 caracteres de ancho) causaría

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

aparecer como

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
    labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco 
    laboris nisi ut aliquip ex ea commodo consequat.

o con cualquier nivel de sangría establecido como predeterminado para el idioma actual.

Las líneas más anchas que mi pantalla nunca hacen que el código sea menos legible en comparación con el código de sangría manual.

editar: ooooh, sabía que esta respuesta sería impopular :)

Ciertamente es hace. Hay una razón por la cual los periódicos y las revistas usan columnas. La legibilidad es un factor significativo. Al leer, nuestros ojos escanean con relativamente poco movimiento de lado a lado. El efecto es permitir que nuestros ojos escaneen lo que estamos leyendo rápidamente.

Incluso cuando es visible en la pantalla, las columnas anchas obligan a nuestros ojos a escanear rápidamente. Mientras escaneamos, realmente no comprendemos nada. Esto disminuirá significativamente la lectura y la comprensión. El efecto es similar a las viejas impresoras mecánicas. Estos a menudo requerían que se insertaran varios caracteres nulos después de un retorno de carro para permitir que el carro o el cabezal de impresión se reposicionaran para la siguiente línea.

Además, el diseño vertical generalmente se realiza para aclarar la agrupación de los contenidos en la línea. Esto normalmente solo debe aplicarse a condiciones lógicas compuestas. Las fórmulas largas pueden estructurarse mejor como una serie de declaraciones. (El optimizador reparará cualquier sobrecarga adicional, y algunos optimizadores se rendirán o funcionarán mal en fórmulas complejas).

Los identificadores con múltiples puntos que requieren líneas grandes indican técnicas de codificación que deben rectificarse.

Las ruedas de ratón facilitan el desplazamiento verticalmente rápido ... el desplazamiento horizontal es demasiado costoso en comparación.

Evite el desplazamiento horizontal.

~ Pautas de interacción de la experiencia del usuario de Windows Pg 112

Si.

Los ingleses leen de izquierda a derecha dando como resultado un desplazamiento constante = no productivo

Por esta razón, siempre habilito el ajuste de palabras con glifos de líneas visuales en mi IDE.