Radzenie sobie z nawiasami klamrowymi

Programowałem zarówno w C #, jak i VB.NET od lat, ale przede wszystkim w VB. Zmieniam karierę w kierunku C # i ogólnie bardziej lubię C #.

Jednym z moich problemów jest zupa z kędzierzawego klamry. W VB każde słowo kluczowe struktury ma pasujące słowo kluczowe close, na przykład:

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

Ten sam kod napisany w C # kończy się bardzo trudny do odczytania:

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

Będąc tak przyzwyczajonym do VB, zastanawiam się, czy programiści w stylu c zastosowali technikę poprawiającą czytelność i zapewniającą, że kod kończy się we właściwym „bloku”. Powyższy przykład jest stosunkowo łatwy do odczytania, ale czasami na końcu fragmentu kodu mam 8 lub więcej poziomów nawiasów klamrowych, co wymaga przewinięcia kilku stron w górę, aby dowiedzieć się, który nawias kończy blok, który mnie interesuje w.

Umieść początkowy nawias klamrowy w tej samej „pozycji” co końcowy, tak jak poniżej:

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

• W zależności od IDE: umieść kursor na nawiasie otwierającym / zamykającym, a podświetli zarówno ten, jak i odpowiedni nawias klamrowy.
• Zwiń blok i pokaże Ci, gdzie się otwiera / zamyka.
• Napisz mniejsze bloki kodu. Poważnie. Sprawdź Clean Codei już nigdy nie napotkasz tego problemu (i masz bardziej czytelny / możliwy do utrzymania kod).

Jedna uwaga, następująca poprawna składnia c # może pomóc w twojej konkretnej sytuacji:

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

Powszechną konwencją jest dodawanie komentarza po nawiasie zamykającym, aby wskazać strukturę, którą zamyka:

if {
   ...
} // end if

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

itp. Nigdy nie rozgrzewałam tej konwencji, ale niektórzy uważają ją za pomocną.

Ogólnie rzecz biorąc, kiedy trudno jest dopasować nawiasy klamrowe w dowolnym stylu - prawdopodobnie oznacza to, że metoda jest za długa i powinna zostać ponownie uwzględniona.

Myślę, że musisz wytrzymać z aparatami ortodontycznymi. W końcu staną się dla ciebie drugą naturą i będziesz się zastanawiać, jak żyłeś bez nich.

Upewnij się jednak, że są one odpowiednio wcięte i że przestrzegana jest pewna konwencja odstępów (nie ma znaczenia, która).

Usuwam 2 poziomy zagnieżdżania, zwijając przestrzeń nazw i zakresy klas w poziomie. Zauważ, że metody są wyrównane do lewej krawędzi ekranu. Nie widzę sensu w utracie 2 poziomów wcięć w każdym pliku.

Po tym rzadko zdarza się, że zagnieżdżasz się na głębokości większej niż 4 poziomy.

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

Niedawno postanowiłem spróbować sformalizować dwie reguły dotyczące konstrukcji kontroli przepływu, które zasadniczo wyglądają tak:

• Nie powinieneś mieć nic oprócz niezbędnych konstrukcji przepływu kodu
• Powinieneś zrobić konstrukcje przepływu kodu tak małe, jak to możliwe

Właśnie z powodów, o których wspomniałeś i których jesteś wyraźnie świadomy, uważam, że są to świetne zasady, których należy przestrzegać. Istnieje kilka prostych technik, które można zastosować do ich osiągnięcia:

• Opuść zakres jak najszybciej (dotyczy to zarówno zakresu pętli, jak i funkcji)
• Uważaj na wady, które można złagodzić, wychodząc z funkcji z poprzedniego if i zastosuj technikę wychodzenia z zakresu, jak wspomniałem
• Odwróć kontrole warunkowe, gdy kod wewnątrz if jest świetny niż ten na zewnątrz
• Współczynnik kodu wewnątrz pętli do innej metody, gdy rozmiar pętli rośnie, aby zasłonić resztę metody
• Uważaj na wszelkie zakresy, które zawierają tylko inny zakres, na przykład funkcję, której cały zakres jest wypełniony przez if bez niczego poza if

Podałem tutaj przykłady tego, jak nieprzestrzeganie tych instrukcji może zakończyć się zrobieniem tego, co powiedziałeś, i wstawieniem kodu do niewłaściwego bloku kodu, co jest złe i jest łatwą przyczyną błędów pojawiających się podczas konserwacji.

Niestety, jest to jedna z najstarszych przyczyn działań wojennych w informatyce. Z obu stron można wysunąć uzasadnione argumenty (lepsza pionowa gospodarka nieruchomościami w porównaniu z łatwiejszą możliwością wizualnego dopasowania klamry otwierającej z klamrą zamykającą), ale w rzeczywistości prosty formatator kodu źródłowego rozwiąże wszystko za Ciebie. MS Visual C # ma wbudowany, który działa dobrze.

Ostrzegamy jednak, że jeśli pracujesz w zespole, będziesz musiał przestrzegać konwencji zastosowanych przez ten zespół, więc opłaca się zapoznać się z oboma stylami i powstrzymać się od religijności zamiast stylów ortodontycznych.

Więc podczas nauki na pewno skupiaj się na stylu, który ułatwia ci naukę, ale miej oko na drugiego, gdy jesteś przy nim i wszystko będzie dobrze.

Użyj Resharper, który pomoże zalecić sposoby ograniczenia zagnieżdżania. Przeczytaj także książkę Boba Martina Clean Code , która podkreśla, że ​​funkcja powinna robić tylko jedną rzecz, a zatem każda funkcja powinna mieć tylko pół tuzina linii, więc nie będziesz musiał się martwić tyloma poziomami zagnieżdżenia.

W edytorze znajduje się dodatek, który może ci pomóc w: C # Zarys .

Dodatek rozszerza edytor VS20xx dla C #, dodając funkcje zwijania, rozwijania i wyróżniania zagnieżdżonych bloków kodu. Funkcje te pozwalają na łatwiejszą edycję i czytanie zagnieżdżonych treści bloków kodu, takich jak if, while itp.

Jeśli napiszesz swój kod w Visual Studio, istnieje również wtyczka, która pokazuje pionowe kropki między początkiem a końcem każdej budowanej struktury.

Ale ogólnie myślę, że minie trochę czasu, zanim przyzwyczaisz się do „Curly-Braces-Soup”. (Btw, naprawdę podoba mi się to wyrażenie. Brzmi trochę jak nazwa odcinka teorii The Big Bang)

Wcięcie mówi ci, gdzie jesteś, w obu stylach składni. Jeśli napiszesz program VB lub program C # w jednym wierszu, wkrótce nie będziesz w stanie powiedzieć, gdzie jesteś w zagnieżdżonej składni. Maszyna analizuje frazy kończące blok lub nawiasy klamrowe, ale ludzie potrzebują wcięcia.

Zwroty blokowe pochodzą z epoki kart perforowanych i taśmy papierowej, kiedy programowanie było znacznie mniej interaktywne i wizualne. Lub, naprawdę, wcale nie interaktywny. Trudno było wchodzić do programów, dlatego programiści potrzebowali kompilatorów, którzy byli bardzo sprytni w analizie składni i usuwaniu błędów.

W tej minionej epoce cykl edycji i kompilacji mógł polegać na przygotowaniu kart dziurkowanych za pomocą dziurkacza kart, a następnie ustawieniu się w oknie przesyłania zadań, w którym urzędnik wziął karty dziurkowane i przekazał je do maszyny. Później programista zbierał dane wyjściowe (wydrukowane na papierze) z innego okna. Gdyby program zawierał błędy, dane wyjściowe składałyby się tylko z diagnostyki kompilatora. Gdy czasy realizacji są długie, dodatkowy koszt pisania end ifzamiast po prostu )jest uzasadniony, jeśli pomaga to poprawić jakość diagnostyki, ponieważ programista musi poprawić jak najwięcej błędów w jednej iteracji, aby zmniejszyć straty czasu iteracje przez okno przesyłania zadania.

Kiedy brakuje zamykającego nawiasu klamrowego, trudno jest stwierdzić, który otwarty nawias klamrowy jest tym, który nie jest zamknięty. (Kompilator może przeanalizować wcięcie, aby odgadnąć odgadnięcie). Jeśli usuniesz nawias zamykający wewnątrz funkcji, wygląda na to, że cała reszta pliku jest częścią tej funkcji, co powoduje lawinę niepomyślnych komunikatów o błędach. Podczas gdy jeśli masz end functionskładnię, kompilator może wywnioskować, gdzie kończy się błędna funkcja, odzyskać i poprawnie przeanalizować kolejne funkcje, zapewniając dodatkową diagnostykę, jeśli taka ma znaczenie.

Gdy pracujesz w edytorze tekstów z rozpoznawaniem kodu, który automatycznie wcina i koloruje kod, na ekranie o wysokiej rozdzielczości, w którym widać sześćdziesiąt lub więcej wierszy, argumenty dla tego rodzaju niezdarnych języków nie mają już zastosowania. Możesz stopniowo edytować i odbudowywać programy tak szybko, że możesz poradzić sobie z jednym błędem naraz. Ponadto, widząc jednocześnie duże sekcje programu na ekranie i utrzymując odpowiednie wcięcie, możesz w pierwszej kolejności ograniczyć występowanie tego rodzaju błędów zagnieżdżania. Dobry programujący edytor tekstu będzie nawet oznaczał niektóre rodzaje błędów składniowych podczas pisania. Co więcej, istnieją składane edytory, które zwiną bloki programu na podstawie jego składni, dając „zarysowy” widok jego struktury.

Lisp od samego początku używał nawiasów i być może nieprzypadkowo hakerzy Lisp byli pionierami programowania jako interaktywnego doświadczenia, budując systemy przyjmujące programy w małych porcjach (wyrażeniach).

W rzeczywistości wcale nie potrzebujesz symboli końcowych, jak ilustruje język Python. Identyfikacja może być po prostu strukturą. Ludzie już używają wcięć, aby przeglądać strukturę kodu nawet w językach, w których maszyna polega na końcowych symbolach lub frazach.

Jeśli używasz IDE, po prostu naciśnij Crtl+ k+, Da IDE wykona resztę pracy.