Bene, vero? È considerata una cattiva pratica?

IMO, è meno leggibile. Odio dover scorrere verso destra, quindi indietro a sinistra, a destra, a sinistra e così via. Rende la codifica più dolorosa e mi confonde a volte.

Ad esempio, ogni volta che sto codificando una stringa lunga, farò quanto segue ...

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

Sì, anzi lo fa, sia in senso letterale che generale.

Mi piace fare differenze di codice side-by-side e le linee troppo larghe lo rendono più difficile:

Lingue come Scala con stringhe tra virgolette triple consentono di costruire una stringa da più righe senza spese di runtime, virgolette e segni più (come si vede nell'esempio) di unire parti di una stringa.

Sì, penso che 80 caratteri per riga siano ragionevoli e comunemente usati.

È una domanda davvero importante per me! Ho lavorato 7 mesi su un laptop da 13 "con colleghi con monitor desktop da 24" e mi sono ritrovato a dedicare molto tempo ad accorciare le linee per finire con qualcosa di leggibile.

80 colonne è un po 'piccola in molti casi (tranne se stai lavorando su un terminale con vi l'unica opzione;)), ma più di ~ 150 è troppo (vedi sotto).

Questo è per la pura domanda di "leggibilità".

Ora, per la parte delle "buone pratiche", molto spesso trovo imperfette righe così lunghe, ovvero avendo una parte che dovrebbe essere estratta in una variabile temporanea o che è duplicata, ad esempio (ObjectiveC, frammento comune nella programmazione di iPhone) :

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

Si noti che questo può diventare ancora più fastidioso quando si lavora con vettori o matrici tridimensionali.

Esempio riscritto:

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

Questo si adatta ora su uno schermo più piccolo, più facile da eseguire il debug utilizzando un IDE o un po 'di scrittura sull'output standard e potrebbe anche essere più veloce, a seconda del costo dell'invocazione del metodo / proprietà. Questo è un po 'forzato, ovviamente, molti esempi del mondo reale sono molto più complessi ...

Non sempre.

Solo per aggiungere una vista alternativa, quando leggo il codice spesso riesco a capire cosa sta facendo la riga di codice senza dover leggere l'intera riga. Se riesco a leggere il nome del metodo ma i parametri del metodo si rovesciano dallo schermo, normalmente non mi agito come posso dire dal solo nome del metodo quale sia l'intento di quella riga di codice. Se alcune righe di codice si riversano dallo schermo, penso che il compromesso di dover scorrere occasionalmente (parola importante lì) in senso orizzontale valga la pena per il codice più compatto. A volte trovo che il codice multi-riga a singola istruzione sia fonte di distrazione poiché devo mentalmente mettere insieme quale codice va con quale affermazione.

Spesso, le righe di codice che si estendono orizzontalmente hanno i loro bit importanti a sinistra (visibili) e i bit meno importanti a destra (fuori schermo), quindi per me questo migliora la leggibilità in quanto posso scansionare il codice verso il basso principalmente vedendo il bit importanti su ogni riga invece dell'alternativa di avere i bit meno importanti di codice da una riga troppo lunga che occupa lo spazio visivo di sinistra visivamente importante sulle seguenti righe.

Detto questo, certamente non vorrei scorrere orizzontalmente molto spesso, ma sto riscontrando questo problema in questi giorni di monitor widescreen.

Sì, lo fa.

Per inciso un suggerimento. Se stai usando un linguaggio con stringhe multilinea (praticamente tutti i linguaggi di scripting li hanno) e includono un SQL lungo, aiuta davvero la leggibilità di inserire l'SQL in una stringa multilinea usando regole di formattazione coerenti per l'SQL. Vedi http://bentilly.blogspot.com/2011/02/sql-formatting-style.html per lo stile di formattazione che uso.

No, non lo fa.

Ho un editore. Non ha solo un ritorno a capo, ma ha anche un rientro di ritorno a capo , che (se lo schermo è largo 100 caratteri) causerebbe

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.

apparire come

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 qualsiasi livello di rientro impostato come predefinito per la lingua corrente.

Le linee più larghe del mio schermo non rendono mai il codice meno leggibile rispetto al codice con rientro a capo automatico.

modifica: ooooh, sapevo che questa risposta sarebbe impopolare :)

Certamente lo è. C'è una ragione per cui i giornali e le riviste usano le colonne. La leggibilità è un fattore significativo. Quando leggiamo i nostri occhi scansioniamo verso il basso con movimenti relativamente piccoli da un lato all'altro. L'effetto è consentire ai nostri occhi di scansionare rapidamente ciò che stiamo leggendo.

Anche quando sono visibili sullo schermo ampie colonne costringono i nostri occhi a scansionare avanti e indietro rapidamente. Durante la scansione indietro non comprendiamo davvero nulla. Ciò rallenterà in modo significativo la lettura e la comprensione. L'effetto è simile alle vecchie stampanti meccaniche. Questi spesso richiedevano l'inserimento di più caratteri null dopo un ritorno a capo per consentire il riposizionamento del carrello o della testina di stampa per la riga successiva.

Inoltre, il layout verticale viene solitamente eseguito in modo da chiarire il raggruppamento dei contenuti sulla linea. Questo di solito dovrebbe applicarsi solo alle condizioni logiche composte. Le formule lunghe possono essere strutturate meglio come una serie di affermazioni. (L'ottimizzatore risolverà qualsiasi sovraccarico aggiuntivo e alcuni ottimizzatori si arrenderanno o avranno prestazioni scarse in formule complesse.)

Gli identificatori con più punti che richiedono linee grandi indicano tecniche di codifica che dovrebbero essere corrette.

Le ruote Mouse facilitano lo scorrimento verticale veloce ... lo scorrimento in orizzontale è troppo costoso in confronto.

Evita lo scorrimento orizzontale.

~ Linee guida per l'interazione con l'esperienza utente di Windows Pg 112

Sì.

Gli inglesi leggono da sinistra a destra risultando in uno scorrimento costante = non produttivo

Per questo motivo abilito sempre il ritorno a capo automatico con glifi di linea visiva nel mio IDE.