Dichiarazioni a linea singola e buone pratiche

11

Di recente ho acquisito un'abitudine che so che molti di voi potrebbero disapprovare, ma che, alla fine, mi aiuta a tenere d'occhio la struttura del codice globale piuttosto che la struttura di un singolo metodo (a volte) ripetitivo: raggruppare un numero di istruzioni in una sola riga, in questo modo:

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

al contrario di

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

Lo faccio per attività ripetitive per mantenere la "bellezza" generale del codice e per aiutarmi a monitorare facilmente la struttura del programma, ma ammetto che potrebbe non essere una buona pratica. In realtà lo uso molto, quindi vorrei sapere quali sono i tuoi pensieri su questo. Inoltre, pensi che qualcuno che dovrebbe mai mantenere il mio codice abbia problemi con questo approccio?

coding-style

— Utente
fonte

5

Questa potrebbe essere una buona domanda per codereview.stackexchange.com

1

Avrò problemi se dovessi mantenere. La prima cosa che vorrei fare è fare un CTRL + F per ";" e metti una pausa. Ma sono solo io :-). Mi piace una riga solo se ho una risposta, ad esempio inizializzare le proprietà abilitate di alcune caselle di testo con un valore predefinito false: textBox1.Enabled = textBox2.Enabled = false;

— Arun,

2

Se stai ponendo una domanda di stile di codifica, sarebbe utile specificare la lingua.

— Caleb,

3

Anche se potrebbe non emergere nell'esempio dato, come hai intenzione di mettere un punto di interruzione nella seconda o terza o ... dichiarazione se li stai mettendo tutti su una riga?

— Marjan Venema,

1

Inoltre, sono abituato alla formattazione automatizzata (Java), in cui il codice ottiene comunque un aspetto uniforme.

— Kwebble,

22

Penso davvero che la leggibilità soffrirebbe molto 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 analizzando il codice per vedere quali variabili e funzioni sono ... stai distruggendo la tua capacità di scansionare il tuo codice. Questo è un no-no enorme, e oltre ogni male se qualcun altro deve mai leggere il tuo codice.

Inoltre, pensa a come leggi il codice. È sempre dall'alto verso il basso, scorrendo verso il basso. Il tuo metodo non combacia con questo e introduce anche uno dei problemi più brutti possibili nella lettura del codice; scorrimento orizzontale . Non sottovalutare mai quanto difficile può rendere la lettura del codice. Non scorri mai in orizzontale, non fai mai scorrere le persone in orizzontale, in quasi tutti i contesti è estremamente innaturale.

Inoltre, se il tuo problema è l'inserimento di codice ripetitivo ... non dimenticare Ctrl-C. Dal tuo codice di esempio potrebbe essere più efficiente digitare tutto manualmente, ma se devi copiare un sacco di righe un sacco di volte sembra che sarebbe altrettanto efficiente copiare una riga più una nuova riga, incollarla x volte e apportare le modifiche, meno probabilità di fare anche un refuso.

Oh, e errori di battitura! Danneggiare la leggibilità del codice in questo modo può rendere un incubo scoprire quale delle 50 dichiarazioni di variabili impostate in modo errato. La maggior parte dei compilatori fornisce errori ai numeri di riga E colonna ora, ma trovare un errore su una riga è MOLTO più facile che trovare una colonna.

— Ben Brocka
fonte

2

a) Lettura / scansione del codice - La maggior parte delle persone durante la scansione del codice legge i primi caratteri della riga, quindi passa a meno che non sia "interessante", quindi ne legge un altro paio. Errori del compilatore: il più delle volte interpreto l'errore del compilatore come "Problema con la riga <x>". solo se posso; t risolverlo all'istante (raro), quindi in realtà ho letto l'errore.

— Mattnz,

19

Un'istruzione per riga semplifica inoltre la visualizzazione di ciò che è cambiato in una diff side-by-side.

— Hugo
fonte

2

Questo è probabilmente il motivo principale, se qualcuno deve unire quel codice, quasi tutti gli strumenti di unione renderanno più semplice isolare e spostare le linee anziché le sottostringhe delle righe.

— anon

@anon Un buon punto anche sugli strumenti di unione; un'istruzione per riga significa meno conflitti di unione da eliminare.

— Hugo,

10

Mentre 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 sola riga genera 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 dichiarazione eccessivamente lunga di qualsiasi tipo.)

— Frank Shearar
fonte

2

Lo stesso concetto si applica al debug, dove ancora una volta la granularità è in genere un numero di riga.

— David Hammen,

2

Oh mio sì, questo può essere un problema. Un "preferito" è quando si allenta un puntatore null in qualcosa di simile foo.bar[grill.boo].flip.flap[flop].mickey(minnie).marshmallow(sintassi Java / C #). L'ordinamento attraverso quel tipo di pasticcio è sempre meglio con linee extra (e variabili temporanee ... e un Brick Of Clue 2D6 per lo sviluppatore originale).

— Donal Fellows,

7

Un'istruzione per riga è uno stile di codifica ampiamente utilizzato. Di conseguenza, la maggior parte degli sviluppatori che guarderanno il tuo codice in futuro probabilmente trarranno fastidio 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, tranne in rare circostanze.

— Igby Largeman
fonte

4

L'ho fatto per l'ultima volta 25 anni fa utilizzando linguaggi interpretati su piccoli micro che funzionano con basse velocità di clock, dove ogni spazio o ritorno a capo eliminato ha dato un aumento delle prestazioni.

Ora sussulto al pensiero (anche se è stato fatto per una buona ragione).

Purtroppo tale codice è difficile da leggere, e quindi difficile da mantenere.

— quickly_now
fonte

1

Quindi lo scrivi correttamente, quindi togli gli spazi bianchi e qualsiasi altra preparazione per la "copia della macchina". Proprio come minimizzare javascript al giorno d'oggi.

— CaffGeek,

1

Sì, ho scritto un programma per rielaborare in questo modo anche il codice sorgente, nel 1986. Un'altra cosa che spero di non dover mai più fare.

— quick_now

1

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

Come la maggior parte del codice che ho visto (incluso il codice che si trova nelle intestazioni standard di c ++) è fatto in questo modo, andrei con il tuo primo metodo.

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

— CuriousGeorge
fonte

0

Questo è uno stile di programmazione davvero insolito.

Ti consiglierei invece di usare righe vuote per delimitare parti logiche di codice.

— svick
fonte

0

Andare troppo lontano a destra può creare tanti problemi quanti più righe.

Ho avuto a che fare con alcune dichiarazioni sql con dozzine di campi. Normalmente, ne metterei uno per riga, ma in alcune occasioni, ho consolidato 3 o 4 di fila. Sembra una buona idea durante lo sviluppo quando devi scorrere su e giù più volte.

Mi dispiace tornare a questo codice. Avere file extra non sembra creare un grosso problema, quindi di solito lo pulisco.

— Jeffo
fonte

0

Inoltre, pensi che qualcuno che dovrebbe mai mantenere il mio codice abbia problemi con questo approccio?

Dopo aver messo le mani sulla testa per un minuto, userà le sue funzionalità IDE Regex preferite per separare automaticamente tutto quel codice illeggibile in un'istruzione per riga.

Basta una rapida occhiata all'esempio che hai mostrato per capire quanto è più leggibile il secondo approccio.

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

Guarda il tuo esempio: sai subito che il codice riguarda la Textproprietà di textBoxoggetti diversi e contengono stringhe come valori. Abbastanza diretto.

— Jose Faeti
fonte

0

Personalmente non userei un tale stile. Riassumere

Professionisti

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

Contro

difficile da leggere, è generalmente più facile leggere il codice in orizzontale (scrematura, nessun movimento degli occhi, ...)
diff diventa facilmente un incubo, inclusa la fusione
più difficile da cambiare (copia e incolla, commentando, ...)
il debug può essere un problema in molti IDE poiché funzionano su righe anziché su singole espressioni.

— MaR
fonte

Alcuni dei "contro" possono a volte essere pro. Ad esempio, supponiamo che un pezzo di codice abbia otto operazioni consecutive del modulo if (x > maxX) {x=maxX; peggedAny = true;}. Se ciascuna di queste operazioni si adatterà facilmente su una singola riga, preferirei avere otto righe come quella di dozzine di righe che dividono le dichiarazioni. Se tali confronti venissero utilizzati in un numero sufficiente di posti, quattro affermazioni del modulo peggedAny |= pegValueMinMax(ref x, minX, maxX);potrebbero essere migliori, ma qualcuno che legge dovrebbe leggere pegValueMinMaxper vedere cosa fa.

— supercat

Inoltre, se un piccolo pezzo di una linea cambia, un "diff" lo considererà come un cambiamento dell'intera linea. Se la linea dovesse comportarsi funzionalmente come un'unità, sarebbe una buona cosa. Altrimenti, se un'operazione semantica è suddivisa su più righe, le modifiche ad alcune righe potrebbero influire sull'operazione in modi che non sarebbero evidenti.

— supercat