Perché le dichiarazioni "if elif else" non sono praticamente mai in formato tabella?

if   i>0 : return sqrt(i)  
elif i==0: return 0  
else     : return 1j * sqrt(-i)

VS

if i>0:  
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Dati gli esempi sopra, non capisco perché praticamente non vedo mai il primo stile nelle basi di codice. Per me, trasformi il codice in un formato tabulare che mostra chiaramente ciò che desideri. La prima colonna può essere praticamente ignorata. La seconda colonna identifica la condizione e la terza colonna fornisce l'output desiderato. Sembra, almeno per me, semplice e facile da leggere. Eppure vedo sempre questo semplice tipo di caso / interruttore emergere nel formato esteso, con rientro a schede. Perché? Le persone trovano più leggibile il secondo formato?

L'unico caso in cui ciò potrebbe essere problematico è se il codice cambia e diventa più lungo. In tal caso, penso che sia perfettamente ragionevole rielaborare il codice nel formato lungo e rientrato. Lo fanno tutti nel secondo modo semplicemente perché è il modo in cui è sempre stato fatto? Essendo un avvocato del diavolo, immagino che un'altra ragione potrebbe essere perché le persone trovano due formati diversi a seconda della complessità delle dichiarazioni if ​​/ else per essere confusi? Qualsiasi approfondimento sarebbe apprezzato.

Uno dei motivi potrebbe essere che non stai usando le lingue in cui è popolare.

Alcuni contro-esempi:

Haskell con protezioni e con motivi:

sign x |  x >  0        =   1
       |  x == 0        =   0
       |  x <  0        =  -1

take  0     _           =  []
take  _     []          =  []
take  n     (x:xs)      =  x : take (n-1) xs

Erlang con motivi:

insert(X,Set) ->
    case lists:member(X,Set) of
        true  -> Set;
        false -> [X|Set]
    end.

Emacs lisp:

(pcase (get-return-code x)
  (`success       (message "Done!"))
  (`would-block   (message "Sorry, can't do it now"))
  (`read-only     (message "The shmliblick is read-only"))
  (`access-denied (message "You do not have the needed rights"))
  (code           (message "Unknown return code %S" code)))

Generalmente vedo che il formato della tabella è piuttosto popolare con i linguaggi funzionali (e in generale quelli basati sull'espressione), mentre spezzare le righe è più popolare in altri (principalmente basati su istruzioni).

È più leggibile. Alcuni motivi per cui:

• Quasi tutte le lingue usano questa sintassi (non tutte, la maggior parte - il tuo esempio sembra essere Python, però)
• isanae ha sottolineato in un commento che la maggior parte dei debugger sono basati su linee (non su istruzioni)
• Inizia a sembrare ancora più brutto se devi incorporare punti e virgola o parentesi graffe
• Legge dall'alto verso il basso più uniformemente
• Sembra orribilmente illeggibile se hai qualcosa di diverso dalle banali dichiarazioni di ritorno
  • Qualsiasi sintassi significativa del rientro viene persa quando si sfoglia il codice poiché il codice condizionale non è più visivamente separato (da Dan Neely )
  • Ciò sarà particolarmente negativo se continui a patchare / aggiungere elementi nell'istruzione if di 1 riga
• È leggibile solo se tutti i tuoi controlli if hanno circa la stessa lunghezza
• Essa significa che non è possibile formattare complicato se le dichiarazioni in istruzioni su più righe, si devono essere oneliners
• Sono molto più propenso a notare bug / flusso di logica durante la lettura verticale riga per riga, non cercando di analizzare più righe insieme
• I nostri cervelli leggono il testo più stretto e più alto MOLTO più velocemente del testo orizzontale lungo

Nel momento in cui provi a fare tutto ciò, finirai per riscriverlo in istruzioni multilinea. Ciò significa che hai perso tempo!

Inoltre le persone inevitabilmente aggiungono qualcosa come:

if i>0:  
   print('foobar')
   return sqrt(i)  
elif i==0:  
   return 0  
else:  
   return 1j * sqrt(-i)  

Non ci vuole molto spesso a farlo prima di decidere che questo formato è molto meglio della tua alternativa. Ah, ma potresti incorporare tutto in una riga! enderland muore all'interno .

O questo:

if   i>0 : return sqrt(i)  
elif i==0 and bar==0: return 0  
else     : return 1j * sqrt(-i)

Il che è davvero molto fastidioso. A nessuno piace formattare cose come questa.

E infine, inizierai la guerra santa del problema "quanti spazi per le schede". Ciò che viene visualizzato perfettamente sullo schermo come formato di tabella potrebbe non essere visualizzato sul mio a seconda delle impostazioni.

La leggibilità non dovrebbe comunque dipendere dalle impostazioni IDE.

Sono fermamente convinto che "il codice viene letto molte volte, scritto poche volte, quindi la leggibilità è molto importante".

Una cosa fondamentale che mi aiuta quando leggo il codice di altre persone è che segue gli schemi "normali" che i miei occhi sono addestrati a riconoscere. Riesco a leggere più facilmente la forma rientrata perché l'ho vista così tante volte che si registra quasi automaticamente (con un piccolo sforzo cognitivo da parte mia). Non è perché è "più bello" - è perché segue le convenzioni a cui sono abituato. La convenzione batte "meglio" ...

Insieme agli altri inconvenienti già menzionati, il layout tabulare aumenta le probabilità del controllo della versione unendo conflitti che richiedono un intervento manuale.

Quando è necessario riallineare un blocco di codice tabellare, il sistema di controllo della versione tratterà ciascuna di quelle righe come modificata:

diff --git a/foo.rb b/foo.rb
index 40f7833..694d8fe 100644
--- a/foo.rb
+++ b/foo.rb
@@ -1,8 +1,8 @@
 class Foo

   def initialize(options)
-    @cached_metadata = options[:metadata]
-    @logger          = options[:logger]
+    @metadata = options[:metadata]
+    @logger   = options[:logger]
   end

 end

Supponiamo ora che nel frattempo, in un altro ramo, un programmatore abbia aggiunto una nuova riga al blocco di codice allineato:

diff --git a/foo.rb b/foo.rb
index 40f7833..86648cb 100644
--- a/foo.rb
+++ b/foo.rb
@@ -3,6 +3,7 @@ class Foo
   def initialize(options)
     @cached_metadata = options[:metadata]
     @logger          = options[:logger]
+    @kittens         = options[:kittens]
   end

 end

La fusione di quel ramo fallirà:

wayne@mercury:/tmp/foo$ git merge add_kittens
Auto-merging foo.rb
CONFLICT (content): Merge conflict in foo.rb
Automatic merge failed; fix conflicts and then commit the result.

Se il codice modificato non avesse utilizzato l'allineamento tabulare, l'unione avrebbe avuto successo automaticamente.

(Questa risposta è stata "plagiata" dal mio articolo scoraggiando l'allineamento tabulare nel codice).

I formati tabulari possono essere molto utili se le cose si adattano sempre alla larghezza assegnata. Se qualcosa supera la larghezza assegnata, tuttavia, spesso diventa necessario avere una parte della tabella che non è allineata con il resto di essa, oppure regolare il layout di tutto il resto della tabella per adattarlo all'elemento lungo .

Se i file di origine sono stati modificati utilizzando programmi progettati per funzionare con dati in formato tabulare e in grado di gestire elementi eccessivamente lunghi utilizzando una dimensione del carattere più piccola, suddividendoli in due righe all'interno della stessa cella, ecc., Potrebbe essere logico utilizzare tabulare formati più spesso, ma la maggior parte dei compilatori desidera file di origine liberi dal tipo di markup che tali editor dovrebbero archiviare per mantenere la formattazione. L'uso di linee con quantità variabili di rientro ma nessun altro layout non è bello come la formattazione tabellare nel migliore dei casi, ma non causa quasi tutti i problemi nel peggiore dei casi.

C'è l'istruzione 'switch' che fornisce questo tipo di cose per casi speciali, ma immagino che non sia quello che stai chiedendo.

Ho visto se le dichiarazioni in formato tabella, ma ci devono essere molte condizioni per renderlo utile. 3 se le istruzioni sono mostrate al meglio nel formato tradizionale, ma se ne avevi 20, è molto più facile visualizzarle in un grande blocco formattato per renderlo più chiaro.

E c'è il punto: chiarezza. Se è più facile vedere (e il tuo primo esempio non è facile vedere dove si trova: delimitatore), formattalo per adattarlo alla situazione. Altrimenti, attenersi a ciò che le persone si aspettano, poiché è sempre più facile da riconoscere.

Se la tua espressione è davvero così facile, la maggior parte dei linguaggi di programmazione offre l'operatore?: Branching:

return  ( i > 0  ) ? sqrt( i)
      : ( i == 0 ) ? 0
        /* else */ : 1j * sqrt( -i )

Questo è un formato tabulare leggibile breve. Ma la parte importante è: vedo a prima vista qual è l'azione "maggiore". Questa è una dichiarazione di ritorno! E il valore è deciso da determinate condizioni.

Se invece hai rami che eseguono codice diverso, trovo molto più leggibile indentare questi blocchi. Perché ora ci sono diverse azioni "principali" a seconda dell'istruzione if. In un caso lanciamo, in un caso registriamo e ritorniamo o semplicemente ritorniamo. Esiste un flusso di programma diverso a seconda della logica, quindi i blocchi di codice incapsulano i diversi rami e li rendono più importanti per lo sviluppatore (ad es. Lettura veloce di una funzione per comprendere il flusso del programma)

if ( i > 0 )
{
    throw new InvalidInputException(...);
}
else if ( i == 0 )
{
    return 0;
}
else
{
    log( "Calculating sqrt" );
    return sqrt( -i );
}

Come ha già detto Enderland, stai assumendo che tu abbia sempre un solo "ritorno" come azione e che puoi taggare quel "ritorno" alla fine della condizione. Vorrei dare qualche dettaglio in più sul perché questo non avrà successo.

Non so quali siano le tue lingue preferite, ma sto scrivendo codice in C da molto tempo. Esistono numerosi standard di codifica che mirano a evitare alcuni errori di codifica standard impedendo la costruzione di codici che sono soggetti a errori, sia nella codifica iniziale che durante la manutenzione successiva. Conosco molto bene MISRA-C, ma ce ne sono altri e generalmente hanno regole simili perché affrontano gli stessi problemi nella stessa lingua.

Un errore popolare a cui spesso si rivolgono gli standard di codifica è questo piccolo errore: -

if (x == 10)
    do_something();
    do_something_else();

Questo non fa quello che pensi che faccia. Per quanto riguarda C, se x è 10 allora chiami do_something(), ma poi do_something_else()viene chiamato indipendentemente dal valore di x . Solo l'azione immediatamente successiva all'istruzione "if" è condizionata. Questo potrebbe essere ciò che intendeva il programmatore, nel qual caso esiste una potenziale trappola per i manutentori; o potrebbe non essere quello che intendeva il programmatore, nel qual caso c'è un bug. È una domanda di intervista popolare.

La soluzione negli standard di codifica è imporre le parentesi graffe attorno a tutte le azioni condizionali, anche se sono a linea singola. Ora capiamo

if (x == 10)
{
    do_something();
    do_something_else();
}

o

if (x == 10)
{
    do_something();
}
do_something_else();

e ora funziona correttamente ed è chiaro per i manutentori.

Noterai che questo è del tutto incompatibile con il tuo formato da tavolo.

Alcuni altri linguaggi (ad esempio Python) hanno esaminato questo problema e hanno deciso che, poiché i programmatori utilizzavano gli spazi bianchi per chiarire il layout, sarebbe una buona idea usare gli spazi bianchi anziché le parentesi graffe. Quindi in Python,

if x == 10:
    do_something()
    do_something_else()

rende le chiamate a entrambi do_something()e do_something_else()subordinate a x == 10, mentre

if x == 10:
    do_something()
do_something_else()

significa che do_something()è solo condizionale su x ed do_something_else()è sempre chiamato.

È un concetto valido e alcune lingue lo usano. (L'ho visto per la prima volta in Occam2, molto tempo fa.) Ancora una volta, tuttavia, puoi facilmente vedere che il tuo formato di tabella è incompatibile con la lingua.

Il layout tabulare può essere utile in pochi casi limitati, ma ci sono poche volte con cui è utile.

In casi semplici?: Potrebbe essere una scelta migliore. In casi medi, uno switch è spesso più adatto (se la tua lingua ne ha uno). In casi complicati potresti scoprire che le tabelle di chiamata sono più adatte.

Ci sono state molte volte in cui il refactoring del codice l'ho riorganizzato per essere tabulare per renderlo ovvio. È raro che io lo lasci così in quanto nella maggior parte dei casi esiste un modo migliore per risolvere il problema una volta compreso. Occasionalmente una pratica di codifica o standard di layout lo proibiscono, nel qual caso è utile un commento.

C'erano alcune domande su ?:. Sì, è l'operatore ternario (o come mi piace pensarlo il valore se). al primo blush questo esempio è un po 'complicato per?: (e abusando?: non aiuta la leggibilità ma fa male), ma con qualche pensiero L'esempio può essere riorganizzato come di seguito, ma penso che in questo caso un interruttore sia il più leggibile soluzione.

if i==0: return 0
return i>0?sqrt(i):(1j*sqrt(-i))

Non vedo nulla di sbagliato nel formato della tabella. Preferenza personale, ma vorrei usare un ternario come questo:

return i>0  ? sqrt(i)       :
       i==0 ? 0             :
              1j * sqrt(-i)

Non c'è bisogno di ripetere returnogni volta :)