Come seguire la best practice del limite di 80 caratteri durante la scrittura del codice sorgente?

La migliore pratica dovrebbe essere "limitare la lunghezza di una linea in modo che tu, tutti i tuoi colleghi e tutti gli strumenti che stai utilizzando siano soddisfatti", oltre al buon senso. 80 caratteri sembra essere molto basso e tende a ridurre la leggibilità. Una volta sono stato ingannato totalmente da una battuta come questa:

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

dove la chiamata della funzione non era visibile sullo schermo (né era visibile sullo schermo di nessun collega) senza alcuna indicazione.

Ho impostato il mio editor per visualizzare un margine di 100 colonne, oltre a rewrapping del codice sul display, quindi tutto è sempre visibile durante la modifica e le righe troppo lunghe tendono a essere suddivise manualmente in due o talvolta più righe. Prega che il tuo editor formuli le dichiarazioni divise in modo corretto se esegue la formattazione automatica. Usa uno stile di codifica che non porti a dichiarazioni profondamente annidate. (Alcune persone creano un nido di venti if-statement seguite da una coda di venti altre che porta a 200 indentation di carattere profondo, e nessuno può capire a quale altro appartiene se).

Nel tuo caso particolare, Swift ha inventato un modo per evitarlo: una variabile "let" (che è circa la stessa di "final" in altre lingue) deve essere assegnata ad un valore esattamente una volta prima che venga usata, ma non necessariamente nella dichiarazione, in modo da poter dividere la tua linea problematica in due dichiarazioni indipendenti.

PS. Ho incontrato delle righe, in un vero codice scritto da umani, che avevano più di 400 caratteri. In altre parole, dovresti scorrere per anni per leggere il resto della linea, anche su un monitor da 24 pollici. Non ero divertito: - (

Sì, sembra migliore. Ecco perché "Non usare linee troppo lunghe!" il massimo è molto strong.

Per quanto riguarda le migliori pratiche, non uso mai, mai e poi mai queste espressioni costruttivamente orribili. Lo userei sempre

public class MyClass {

    public void myMethod() {

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

per un valore importato staticamente, opportunamente definito, di newMap() . Lo considero un grave difetto in Java che non ha una versione integrata.

L'obiettivo non è "mantenere le linee a 80 caratteri". L'obiettivo è "rendi il tuo codice facile da leggere e comprendere". Il limite di 80 caratteri artificiali aiuta nella leggibilità, ma non è una regola dura e veloce, a meno che la tua squadra non lo decida.

Hai chiesto le migliori pratiche e la migliore pratica è "concentrarsi sul rendere il codice il più leggibile possibile". Se questo richiede più di 80 caratteri, così sia.

Non aver paura di premere il tasto Invio. La maggior parte dei linguaggi moderni (incluso Java come nel tuo esempio) sono abbastanza contenti di affermazioni che attraversano più righe.

Basta riflettere su dove si interrompono le linee e si può ottenere qualcosa che si adatta a un limite di 80 colonne e rimane comunque perfettamente leggibile. Le convenzioni di codifica Java ufficiali specificano anche i luoghi preferiti per interrompere le linee.

Fatto bene, una linea ben divisa è molto più leggibile di una che scompare dalla parte dello schermo.

Se si applica la lunghezza della linea / larghezza del codice, utilizzare uno strumento.

• ReSharper
• Visual Assist
• ecc.

Gli sviluppatori decidono quale lunghezza ragionevole è (80, 120, 200, ecc.), imposta tale opzione nello strumento.

Dopodiché, scrivi semplicemente il codice come faresti normalmente senza riguardo alla larghezza o alla lunghezza della linea. Una volta che è funzionale e finito, fai clic con il pulsante destro e scegli Codice pulizia o un'opzione simile. Lo strumento formatterà il codice come hai detto e spezzerà le linee lunghe come indicato.

Senza pensieri e facile e ogni file sorgente sarà formattato allo stesso modo.

80 limite di caratteri potrebbe essere un po 'troppo breve in questi giorni, ma aiuta. Sarei d'accordo con tutte quelle opinioni sul fatto che anche il codice dovrebbe essere ben formattato. per esempio. codice

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

può essere all'interno di 80 chr ma crea confusione come osservazioni e le opzioni di codice sono sulla stessa riga singola.

Aderire al limite di 80 cr o no è una scelta individuale, ma se le cose sono visibili nello scatto singolo, darà sempre una visione e un feeling constrongvoli anche ai programmatori e ad altri revisori.