La frase ‘if’ dovrebbe sempre avere una clausola ‘else’?

Questo può essere un argomento religioso, ma è stato discusso ad-nausea qui al mio lavoro se tutte le istruzioni IF dovessero includere una clausola ELSE – anche se la clausola ELSE contiene solo un commento che afferma che è stato “lasciato intenzionalmente in bianco”.

Ho sentito argomenti per entrambe le parti: Il campo “Per” – assicura che i codici abbiano effettivamente affrontato se la condizione richiede una clausola ELSE Il campo “Contro” – il codice è più difficile da leggere, aggiunge troppo rumore

Sono interessato a qualsiasi altro punto di vista in quanto devo risolvere questo dibattito con una risposta che soddisfi entrambe le parti.

Grazie per l’aiuto.

A proposito: ho cercato StackOverflow per una risposta a questo e non è stato in grado di trovarne uno. Se ce n’è uno, includi semplicemente un link e chiudi. Grazie.

    Mi sembra inutile scrivere a me … e una ansible causa di confusione. Se non ne hai bisogno, non metterlo!

    No. Se non è necessario eseguire alcun codice sul lato opposto, non è necessaria una clausola else .

    È chiaro dalle risposte qui che nessuno sente un altro inutilizzato è necessario. Non ho mai sentito né letto di una cosa del genere. La questione più importante prima che tu abbia a che fare con colleghi / sviluppatori che in qualche modo credono fermamente che questo è il modo in cui deve essere usato If Then.

    Sembra che tu non sia la persona senior in questo scenario, quindi non puoi semplicemente decretarlo per essere così. Suggerisco di chiedere alle parti “vuote” di mostrare dove un tale processo è suggerito in un libro (i blog non contano) sullo sviluppo. Meglio ancora, in 3 libri sullo sviluppo. Ho letto la mia parte di libri di programmazione sui linguaggi di programmazione dal 1982 e non ho mai visto un simile suggerimento.

    In questo modo non stai dicendo loro che hanno torto che potrebbero prendere personalmente. Invece sei disposto ad accettare una tale posizione ma vorresti vedere qualche documentazione. L’onere è su di loro per trovare la prova. O lo trovano o sono lasciati a sostenere che ogni libro di programmazione scritto è sbagliato mentre solo loro hanno ragione.

    In bocca al lupo.

    La regola d’oro: inseriscila se rende il tuo codice più chiaro e più facile da capire, e lo lasci fuori altrimenti. Un programmatore esperto sarà in grado di esprimere questi giudizi caso per caso.

    Stai parlando di lingue derivate da Algol?

    In Lisp, direi di sì: ogni IF dovrebbe avere una clausola else. Altrimenti, dovresti usare QUANDO.

    Come dici tu, questa potrebbe essere una questione di stile, ma non mi sognerei di inserire altri blocchi vuoti nel mio codice solo perché “ogni if-block dovrebbe averne uno”. A mio parere, non aggiunge altro che alcuni caratteri nel codice e un altro punto (di pochissimo valore) da dedicare al tempo durante le revisioni del codice.

    Richiedere un else puzza. Usalo quando necessario. Tutti i programmatori comprendono il costrutto e le implicazioni di un else mancante. È come un commento inutile che riecheggia il codice. È semplicissimo IMO.

    Tendo ad usare “early if” come mezzo per ridurre il livello di parentesi annidate (o indentazione in Python) in questo modo:

     if (inParam == null) { return; } if (inParam.Value < 0) { throw new ArgumentException(...,...); } // Else ... from here on my if statements are simpler since I got here. 

    Certo, .Net 4.0 ha ora dei contratti di codice, il che è fantastico! Ma la maggior parte delle lingue non lo ha ancora, quindi "early ifs" (per la mancanza di termini migliori) sono grandi proprio perché eliminano un certo numero di altre clausole e if annidate. Non penso che sia vantaggioso avere una clausola else in linguaggi di alto livello ... diamine, anche in assemblea! L'idea è: se hai controllato e non hai saltato, allora la condizione era falsa e possiamo continuare. Ha senso logico per me ...

    EDIT: Guarda anche questo articolo per capire perché le else clausole non sono di grande aiuto: http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html

    “garantisce che i codici abbiano effettivamente affrontato se la condizione richiede una clausola ELSE”

    Questo non è più vero che richiedere una clausola catch in ogni metodo garantisce che tutte le possibili eccezioni siano state gestite correttamente.

    No. Le condizioni di guardia sono un ottimo esempio. È ansible nidificare il resto della logica del metodo nelle clausole else ma potrebbe diventare brutto molto rapidamente.

     if (thereIsSomeThingToDoInTheElse) { putAnElseClause(); } else { // intentionally left blank } 

    SQL Server 2000, 2005 almeno.

     IF 1 = 1 BEGIN PRINT 'doing something productive' END ELSE BEGIN --Just sitting here END Msg 102, Level 15, State 1, Line 8 Incorrect syntax near 'END'. 

    Devi avere una dichiarazione significativa, il che significa assegnare un fittizio o restituire dati al cliente. Suppongo che potrei usare WAITFOR DELAY …

    Haskell’s se è sempre ternario. Quindi altro è obbligatorio.

    Avere un “altro” con solo una riga vuota di un commento di codice può in genere significare che lo sviluppatore ha pensato, attraverso la condizione e ha un’idea migliore di quale percorso di esecuzione è effettivamente preso in un dato momento. Tutti i compilatori recenti rimuoveranno “else” e il commento, quindi non rallenterai l’esecuzione del software.

    A meno che non legga le altre risposte in modo errato, sembra che la maggior parte della gente si opponga al tempo necessario per dichiarare i propri pensieri nel codice e preferirebbe semplicemente farlo.

    Se il tuo codice è abbastanza complesso da rendere questo problema, dovresti probabilmente ripensare al tuo approccio al problema. Rompi ciò che stai facendo in funzioni più semplici e più piccole, dove dovrebbe essere incredibilmente ovvio cosa stanno facendo le dichiarazioni if.

    Se non riesci a scomporlo in funzioni più piccole, o ti trovi ad annidare più di una istruzione if in un’altra, le istruzioni Using if per la tua logica condizionale probabilmente non sono una buona idea. Prendi in considerazione gli switch, le tabelle di ricerca (se l’unica differenza tra le tue condizioni è il valore di alcune costanti) o le tabelle delle decisioni.

    Se hai già fatto tutto questo, allora stai cavillando per qualcosa di così incredibilmente banale che non vale la pena darti il ​​tempo di discuterne.

    Una delle poche possibili situazioni in cui questa potrebbe essere una buona idea è dove si hanno diverse istruzioni nidificate if , ma meno else clausole. La lingua specificherà if l’ else corrisponde, ma questo potrebbe non essere sempre chiaro per il lettore. Ovviamente, dove si inserisce il contenuto tra parentesi graffe, l’annidamento sarà ovvio, quindi non c’è alcuna ambiguità. Questo rende questo un caso un po ‘artificiale, ma forse ancora da menzionare. Inoltre, se il tuo codice è così complicato, probabilmente c’è un modo più chiaro di scriverlo.

    ci sono molte “parole” che ti indicano il modo di programmare come DRY

    in questo caso userò YAGNI .. non ne avrai bisogno ..

    quindi seguendo questo non dovresti scrivere il resto.

    comunque a mio avviso rende più difficile leggere e capire il codice .. più si scrive più difficile capire il codice

    modifica: ecco i link che hai richiesto: http://en.wikipedia.org/wiki/YAGNI http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

    Vi sono situazioni in cui l’utilizzo di un elemento di syntax opzionale quando non richiesto può migliorare la leggibilità o prevenire errori futuri. Un caso tipico sono le parentesi attorno ai condizionali di una frase:

    fare

     if(foo){ bar } 

    invece di

     if(foo) bar 

    potrebbe alla fine impedire

     if(foo) bar dot 

    Non riesco a pensare a nessuna lingua che conosco dove omettere un altro non necessario può portare a potenziali errori: -?