Dichiarazioni su riga singola e buone pratiche

Credo davvero che la leggibilità possa essere di grande sofferenza sia per te che per chiunque altro leggendo il codice. Tutto ha senso quando lo scrivi la prima volta perché è attivamente nella tua mente. È diverso quando stai scandendo il codice per vedere quali variabili e funzioni sono dove ... stai distruggendo la tua capacità di scansionare il tuo codice. È un enorme no-no, e oltre il male se qualcun altro mai deve leggere il tuo codice.

Inoltre, pensa a come leggi il codice. È sempre dall'alto in basso, scorrendo verso il basso. Il tuo metodo non si adatta a questo e introduce uno dei problemi più brutti nella lettura del codice; scorrimento orizzontale . Mai sottovalutare quanto sia difficile fare codice di lettura. Non scorri mai orizzontalmente, non fai mai scorrere le persone in orizzontale, in quasi tutti i contesti è estremamente innaturale.

Inoltre, se il tuo problema è l'immissione di codice ripetitivo ... non dimenticare Ctrl-C. Dal tuo codice di esempio potrebbe essere più efficiente scrivere tutto manualmente, ma se devi copiare un mucchio di righe un po 'di volte sembra che sia altrettanto efficiente copiare la riga uno e una nuova riga, incollarla x volte e apporta le modifiche, con meno probabilità di sbagliare.

Oh, e refusi! Danneggiare la leggibilità del tuo codice come quello può rendere un incubo trovare quale delle 50 dichiarazioni variabili hai impostato in modo errato. La maggior parte dei compilatori genera errori con i numeri di riga E di colonna, ma trovare un errore in una riga è MOLTO più facile che trovare una colonna.

Una dichiarazione per riga rende anche più facile vedere cosa è cambiato in un confronto affiancato

Anche se l'esempio non mostra questo, c'è un altro problema con il raggruppamento di più istruzioni su una riga. Cosa succede se una delle cinque affermazioni che hai su una singola linea lancia un'eccezione?

La traccia dello stack dirà "EBlah alla riga N" ... e ora non hai idea di quale di queste cinque affermazioni abbia generato l'eccezione.

(La stessa cosa accade con una frase eccessivamente lunga di qualsiasi tipo.)

One-statement-per-line è uno stile di codifica ampiamente utilizzato. Di conseguenza, la maggior parte degli sviluppatori che guardano il tuo codice in futuro probabilmente si bloccherà quando vedranno più istruzioni per riga. Quando sei abituato a vedere qualcosa in un modo, può essere disorientante vederlo in un altro modo.

Per questo motivo sconsiglio di farlo, tranne in rare circostanze.

L'ho fatto l'ultima volta 25 anni fa usando linguaggi interpretati su piccoli micros che giravano con basse velocità di clock, dove ogni spazio o ritorno del carrello eliminato ha dato un aumento delle prestazioni.

Ora me ne vado al pensiero (anche se è stato fatto per una buona ragione).

Sfortunatamente tale codice è difficile da leggere e quindi difficile da mantenere.

Sintatticamente, non c'è davvero niente di sbagliato in questo. Dipende molto dallo stile di codice della tua squadra.

Dato che la maggior parte del codice che ho visto (incluso il codice che si trova all'interno delle intestazioni standard del c ++) è fatto in questo modo, vorrei andare con il tuo primo metodo.

textBox1.Text = "Something!";
textBox2.Text = "Another thing!";
textBox3.Text = "Yet another thing!";

Questo è uno stile di codifica davvero inusuale.

Ti consiglio di utilizzare le righe vuote per delimitare invece le parti logiche del codice.

Andare troppo lontano a destra può creare altrettanti problemi quante più linee.

Ho dovuto occuparmi di alcune istruzioni SQL con dozzine di campi. Normalmente, ne inserivo uno per riga, ma in alcune occasioni, ho consolidato 3 o 4 in una riga. Questa sembra una buona idea durante lo sviluppo quando devi scorrere su e giù più volte.

Mi dispiace tornare a questo codice. Avere righe aggiuntive non sembra creare un gran problema, quindi di solito lo pulisco.

Also, do you think that anyone which would ever have to maintain my code have problems with this approach?

Dopo aver messo le mani sulla sua testa per un minuto, userà le sue funzionalità IDE preferite di Regex per separare automaticamente tutto il codice illeggibile in una dichiarazione per riga.

Solo un rapido sguardo all'esempio che hai mostrato è sufficiente per capire quanto più leggibile è il secondo approccio.

È molto più semplice seguire il flusso della pagina verticale, senza che gli occhi si spostino orizzontalmente per sempre.

Guarda il tuo esempio: sai immediatamente che il codice riguarda esclusivamente la proprietà Text di diversi oggetti textBox e contengono string come valori. Piuttosto semplice.

Non utilizzerei personalmente un tale stile. Per riassumere

Professionisti

• meno righe di codice per scorrere
• può essere usato per raggruppare semanticamente il codice per esprimere: "un sacco di cose da assegnare". MA puoi sempre refactoring tale blocco in una funzione se ti dà fastidio troppo.

Contro

• difficile da leggere, in genere è più facile leggere il codice in orizzontale (sfiorando, senza movimento oculare, ...)
• diff diventa facilmente un incubo, inclusa la fusione
• più difficile da modificare (copia e incolla, commenta, ...)
• il debugging può essere un problema in molti IDE poiché funzionano sulle linee anziché sulle singole espressioni.