Trattare con zuppa di parentesi graffe ricci

Ho programmato in C # e VB.NET per anni, ma principalmente in VB. Sto facendo uno spostamento verso C # e, nel complesso, mi piace C # meglio.

Un problema che sto riscontrando, tuttavia, è la zuppa di parentesi graffe. In VB, ogni parola chiave della struttura ha una parola chiave di chiusura corrispondente, ad esempio:

Namespace ...
    Class ...
        Function ...
            For ...
                Using ...
                    If ...
                        ...
                    End If
                    If ...
                        ...
                    End If
                End Using
            Next
        End Function
    End Class
End Namespace

Lo stesso codice scritto in C # finisce per essere molto difficile da leggere:

namespace ... {
    class ... {
        function ... {
            for ... {
                using ... {
                    if ... {
                        ...
                    }
                    if ... {
                        ...
                    }
                }
            }
            // wait... what level is this?
        }
    }
}

Essendo così abituato a VB, mi chiedo se esiste una tecnica impiegata dai programmatori c-style per migliorare la leggibilità e per garantire che il codice finisca nel "blocco" corretto. L'esempio sopra è relativamente facile da leggere, ma a volte alla fine di un pezzo di codice avrò 8 o più livelli di parentesi graffe, che richiedono di scorrere diverse pagine per capire quale parentesi finisce il blocco che mi interessa in.

Metti la parentesi graffa iniziale nello stesso "rango" di quella finale, in questo modo:

namespace ... 
{
    class ... 
    {
        function ... 
        {
            for ... 
            {
                using ... 
                {
                    if ... 
                    {
                        ...
                    }
                    if ... 
                    {
                        ...
                    }
                }
            }
            // It's the `function` level!
        }
    }
}

• A seconda dell'IDE: posiziona il cursore sulla parentesi aperta / chiusa per evidenziare sia la parentesi che la corrispondente.
• Comprimi il blocco e ti mostra dove si apre / chiude.
• Scrivi blocchi di codice più piccoli. Sul serio. Dai un'occhiata Clean Codee non incontrare mai più questo problema (e avere un codice più leggibile / gestibile).

Una nota, la seguente è una sintassi c # valida che potrebbe aiutare la tua situazione particolare:

using (var type = new MyDisposable1())
using (var type2 = new MyDisposable2())
{
    /* do what you will with type2 and type2 */
}

Una convenzione comune è aggiungere un commento dopo la parentesi graffa di chiusura per indicare la struttura che sta chiudendo:

if {
   ...
} // end if

while (condition) {
   ...
} // end while

ecc. Non mi sono mai riscaldato a questa convenzione da solo, ma alcune persone lo trovano utile.

In generale, quando diventa difficile abbinare le parentesi graffe in qualsiasi stile, probabilmente significa che il metodo è troppo lungo e dovrebbe essere riconsiderato.

Penso che devi rinforzarlo con le parentesi graffe. Alla fine diventeranno una seconda natura per te e ti starai chiedendo come hai mai vissuto senza di loro.

Assicurati però che siano rientrati in modo appropriato e che venga seguita una convenzione di spaziatura (non importa quale).

Rimuovo 2 livelli di annidamento comprimendo lo spazio dei nomi e gli ambiti delle classi in senso orizzontale. Si noti che i metodi sono allineati con il bordo sinistro dello schermo. Non vedo il punto di perdere 2 livelli di rientro in ogni file.

Dopodiché è raro che tu abbia mai annidato più di 4 livelli di profondità.

namespace FooNameSpace {
class Foo {

public void bar()
{
    while(true)
    {
        while(true)
        {
            break;
        }
    }
}

public void fooBar()
{
    foreach(var item in FooList)
    {
        foreach(var b in item.Bars)
        {
            if(b.IsReady)
            {
                bar();
            }
            bar();
        }
        bar();
    }
}

}}//end class, namespace

Di recente ho deciso di provare a formalizzare due regole sui costrutti di controllo del flusso che sostanzialmente vanno così:

• Non dovresti avere altro che costrutti di flusso di codice necessari
• Dovresti rendere i costrutti del flusso di codice il più piccoli possibile

Proprio per i motivi che hai citato e di cui sei chiaramente consapevole, penso che queste siano ottime regole da seguire. Ci sono un paio di semplici tecniche che puoi utilizzare per realizzarle:

• Esci dall'ambito appena possibile (questo include l'ambito dei loop e le funzioni)
• Fai attenzione agli altri che potrebbero essere mitigati uscendo dalla funzione dal precedente if e applica la tecnica di uscire dall'ambito come ho già detto
• Invertire i controlli condizionali quando il codice all'interno di un if è eccezionale rispetto a quello esterno
• Codice fattore all'interno di un loop verso un altro metodo quando la dimensione del loop aumenta per oscurare il resto del metodo
• Controlla eventuali ambiti che contengono solo un altro ambito, ad esempio una funzione il cui intero ambito è riempito da un if con niente al di fuori dell'if

Ho dettagliato qui esempi di come non seguirli può finire con te facendo come hai detto e mettendo il codice nel blocco di codice errato, il che è male e una facile causa di bug che si presentano durante la manutenzione.

Questa è purtroppo una delle più antiche cause di guerra nell'informatica. Argomenti ragionevoli possono essere fatti da entrambe le parti (migliore economia immobiliare verticale rispetto a una più facile capacità di abbinare visivamente parentesi aperta con parentesi chiusa), ma in realtà un semplice formattatore di codice sorgente risolverà tutto per te. MS Visual C # ne ha uno integrato che funziona bene.

Tuttavia, tieni presente che se stai lavorando come parte di una squadra, ti dovrai aspettare di conformarti alle convenzioni utilizzate da quella squadra, quindi vale la pena acquisire familiarità con entrambi gli stili e astenersi dal diventare religiosi rispetto agli stili di parentesi.

Quindi, mentre stai imparando con tutti i mezzi, concentrati sullo stile che ti rende più facile da imparare, ma tieni d'occhio l'altro mentre ci sei e farai bene.

Usa Resharper, che ti aiuterà a raccomandare modi per ridurre l'annidamento. Inoltre, leggi il libro Clean Code di Bob Martin , che sottolinea che una funzione dovrebbe fare solo una cosa, e quindi ogni funzione dovrebbe essere lunga solo una mezza dozzina di righe, quindi non avrai molti livelli di annidamento di cui preoccuparti.

C'è un componente aggiuntivo nell'editor che può aiutarti in: C # Outline .

Il componente aggiuntivo estende l'editor VS20xx per C # aggiungendo funzionalità per comprimere, espandere ed evidenziare blocchi di codice nidificati. Queste funzionalità consentono di modificare e leggere più facilmente i contenuti nidificati di blocchi di codice come if, while, ecc.

Se scrivi il tuo codice in Visual Studio, c'è anche un plugin che mostra punti verticali tra l'inizio e la fine di ogni struttura che costruisci.

Ma nel complesso penso che ci vorrà solo un po 'di tempo prima che tu sia abituato al "Curly-Braces-Soup". (A proposito, mi piace molto quell'espressione. Sembra un po 'un episodio-nome per The Big Bang Theory)

Il rientro ti dice dove sei, in entrambi gli stili di sintassi. Se scrivi un programma VB o un programma C # su una sola riga, presto non sarai in grado di dire dove ti trovi nella sintassi nidificata. La macchina analizza le frasi finali del blocco o le parentesi graffe, ma gli umani hanno bisogno di rientranze.

Le frasi di fine blocco provengono da un'era di schede perforate e nastro di carta, quando la programmazione era molto meno interattiva e visiva. O, davvero, per nulla interattivo. È stato difficile accedere ai programmi, quindi i programmatori avevano bisogno di compilatori per essere molto intelligenti nell'analisi della sintassi e nel recupero degli errori.

In quell'epoca passata, il ciclo di esecuzione della compilazione-compilazione potrebbe aver comportato la preparazione di schede perforate con un perforatore di carte, e quindi l'allineamento a una finestra di presentazione del lavoro in cui un impiegato prendeva le schede perforate e le inviava alla macchina. Più tardi, il programmatore avrebbe raccolto l'output (stampato su carta) da un'altra finestra. Se il programma avesse errori, l'output consisterebbe solo nella diagnostica del compilatore. Quando i tempi di risposta sono lunghi, il costo aggiuntivo della digitazione end ifanziché solo )è giustificato se aiuta a migliorare la qualità della diagnostica, poiché il programmatore deve correggere il maggior numero possibile di errori in un'unica iterazione per ridurre il numero di perdite di tempo iterazioni attraverso la finestra di invio del lavoro.

Quando manca una parentesi graffa di chiusura, è difficile dire quale parentesi aperta è quella che non è chiusa. (Il compilatore potrebbe dover analizzare il rientro per fare un'ipotesi istruita.) Se si elimina una parentesi graffa di chiusura all'interno di una funzione, sembra che l'intero resto del file faccia parte di quella funzione, risultando in una raffica di messaggi di errore inutili. Considerando che se si dispone di una end functionsintassi, il compilatore può dedurre dove termina la funzione errata, ripristinare e analizzare correttamente le funzioni successive, fornendo eventuali diagnosi aggiuntive che sono significative.

Quando lavori in un editor di testo sensibile al codice che rientra e colora automaticamente il tuo codice, su uno schermo ad alta risoluzione in cui puoi vedere sessanta o più righe, gli argomenti per quei tipi di linguaggi goffi non si applicano più. Puoi modificare e ricostruire in modo incrementale i programmi così velocemente da poter gestire solo un errore alla volta. Inoltre, vedendo grandi sezioni del programma contemporaneamente sullo schermo e mantenendo il rientro corretto, è possibile ridurre in primo luogo il verificarsi di questi tipi di errori di annidamento. E un buon editor di testi di programmazione segnalerà anche alcuni tipi di errori di sintassi durante la digitazione. Inoltre, ci sono editor pieghevoli che faranno crollare i blocchi di un programma in base alla sua sintassi, dando una visione "simile a uno schema" della sua struttura.

Lisp ha usato le parentesi sin dall'inizio e forse, non a caso, gli hacker di Lisp sono stati i pionieri della programmazione come esperienza interattiva costruendo sistemi che accettavano programmi in piccoli pezzi (espressioni).

In effetti, non hai bisogno di simboli finali, come dimostra il linguaggio Python. L'identificazione può essere solo la struttura. Gli umani usano già il rientro per individuare la struttura del codice anche nelle lingue in cui la macchina si basa sulla fine di simboli o frasi.

Se stai usando un IDE, premi Crtl+ k+ De l'IDE farà il resto del lavoro.