W dyskusji o rozmieszczeniu nawiasów klamrowych pojawiło się już kilka uwag na temat białych znaków.

Sam zwykle posypuję mój kod pustymi liniami, próbując segregować rzeczy, które pasują do siebie w „logicznych” grupach i mam nadzieję, że ułatwią następnej osobie przeczytanie kodu, który właśnie stworzyłem.

W rzeczywistości powiedziałbym, że tworzę swój kod tak, jak piszę: robię akapity nie dłuższe niż kilka wierszy (zdecydowanie krótsze niż 10) i staram się, aby każdy akapit był samowystarczalny.

Na przykład:

• w klasie zgrupuję metody, które idą w parze, oddzielając je pustą linią od następnej grupy.
• jeśli muszę napisać komentarz, zwykle umieszczam przed komentarzem pustą linię
• w metodzie robię jeden akapit na krok procesu

Podsumowując, rzadko mam zgrupowane więcej niż 4/5 linii, co oznacza bardzo rzadki kod.

Nie uważam całej tej białej przestrzeni za marnotrawstwo, ponieważ faktycznie używam jej do struktury kodu (tak jak w rzeczywistości używam wcięcia), i dlatego uważam, że jest warta posiadanego ekranu.

Na przykład:

for (int i = 0; i < 10; ++i)
{
    if (i % 3 == 0) continue;

    array[i] += 2;
}

Uważam, że oba stwierdzenia mają wyraźne odrębne cele i dlatego zasługują na rozdzielenie, aby było to oczywiste.

Jak więc faktycznie używasz (lub nie) pustych wierszy w kodzie?

Zawsze

Białe znaki są niezbędne do czyszczenia czytelnego kodu. Pusta linia (lub dwie) pomagają wizualnie oddzielić logiczne bloki kodu.

Na przykład z Steve'a McConnell'a Code Complete, rozdział drugi wydania na temat układu i stylu:

Badani uzyskali od 20 do 30 procent wyższą ocenę testu zrozumienia, gdy programy miały schemat wcięcia od dwóch do czterech spacji, niż wtedy, gdy programy w ogóle nie miały wcięcia.To samo badanie wykazało, że ważne jest, aby nie podkreślać ani nadmiernie podkreślać logicznej struktury programu. Najniższe wyniki rozumienia uzyskano w programach, które nie były w ogóle wcięte. Drugie najniższe osiągnięto w programach, w których zastosowano wcięcie sześcioprzestrzenne. W badaniu stwierdzono, że wcięcie od dwóch do czterech przestrzeni jest optymalne. Co ciekawe, wielu badanych w eksperymencie uważało, że sześciokątne wcięcie jest łatwiejsze w użyciu niż mniejsze wcięcia, mimo że ich wyniki są niższe. Prawdopodobnie dlatego, że sześć wcięć w przestrzeni wygląda przyjemnie. Ale niezależnie od tego, jak ładnie to wygląda, sześcioprzestrzenne wcięcie okazuje się mniej czytelne. Jest to przykład kolizji między estetyką a czytelnością.

Tak dla jasności.

Tak jak zrobiłem w tej odpowiedzi.

Robię, ale upewniam się, że udokumentowałem to, umieszczając

(This line intentionally left blank.)

na linii

Tak, ale nie nadużywam tego.

Widziałem kod, w którym każda linia kodu w metodzie jest oddzielona pustą linią, a dwie puste linie są używane tam, gdzie występuje separacja logiczna. To sprawia, że ​​moim zdaniem jest to jeszcze mniej czytelne. Widziałem także białe znaki używane do szalonych dopasowań, takich jak to:

//Prot.   Return type                    Name                 Arg1        Arg2
//=====   ============================== ==================== =========== ========

private   int                            AMethodWithALongName(string s,   object o)
{
    ...
}

private   IDictionary<MyLongObject, int> SomethingCrazy      (string s)
{
    ...
}

protected void                           Foo                 (string str, object o)
{
    ...
}

To samo niewłaściwe użycie poziomych białych znaków można zastosować do pionowych białych znaków. Jak każde narzędzie, używaj go mądrze.

Jestem krytykowany za pisanie mojego kodu w ten sposób. Nie rozumiem, dlaczego nikt nie zrobiłby tego w ten sposób.

Czytelność jest bardzo ważna, gdy wracasz do projektu po dłuższym czasie i słyszałem powiedzenie „Zawsze pisz kod, jeśli następnym facetem, który go czyta, jest Psychopata, który zna Twoją lokalizację”.

Nie zawsze piszę oprogramowanie, ale kiedy to robię, używam pustych linii dla zachowania przejrzystości.

Jestem za tym, aby kod był jak najbardziej przejrzysty, a białe znaki są często przydatnym narzędziem w tym przedsięwzięciu. Ale nie zapominajmy o refaktoryzacji:

• w klasie zgrupuję metody, które idą w parze, oddzielając je pustą linią od następnej grupy.

Ponieważ masz kilku powiązanych członków, są oni kandydatami do nowej klasy.

• jeśli muszę napisać komentarz, zwykle umieszczam przed komentarzem pustą linię

Ilekroć kod jest na tyle niejasny, że chce komentarza, pytam, czy mogę dokonać refaktoryzacji, aby kod był wystarczająco jasny, aby nie potrzebować komentarza.

• w metodzie robię jeden akapit na krok procesu

Dlaczego nie stworzyć jednej metody dla każdego „akapitu”?

Jeśli skończysz z wieloma metodami w swojej klasie, zobacz moją notatkę powyżej na temat wyodrębnienia nowej klasy.

Tak. Ułatwia wizualne skanowanie pliku. Między innymi sprawia, że ​​jaśniej jest, z którą linią komentarz się zgadza.

Some code here
// Which line does this comment go with?
More code here

// It's pretty clear which line this comment goes with
More code here

Still more code here

Używam pustych linii oszczędnie i konsekwentnie, a konsekwencja jest ważniejsza niż oszczędnie. Jednak:

• Jeśli każdy wiersz kodu jest oddzielony od następnego pustym wierszem, istnieje zbyt wiele pustych wierszy.
• Jeśli nie ma rymu ani rozsądku, które można by łatwo rozpoznać, gdzie umieszczane są puste linie, to odwracają uwagę i zwykle jest ich zbyt wiele.
• Jeśli funkcja jest tak duża, że ​​potrzebuje wielu pustych linii, jest zbyt duża.
• Jeśli blok kodu wymaga więcej niż jednego pustego wiersza przed nim lub po nim, oznacza to, że coś poważnie się myli.
• Jeśli między funkcjami są więcej niż dwie puste linie, prawdopodobnie masz zbyt wiele pustych linii.

Większość z nich nie jest strasznie kontrowersyjna; co może być. Zauważam, że notacja K&R z otwartymi nawiasami na końcu linii jest przygnębiająco często następująca po pustej linii. Osobiście nie lubię nawiasów klamrowych na końcu linii, a mieszanie ich z pustą linią po nawiasie czyni nonsens notacji (IMNSHO). Umieść otwarty nawias klamrowy w osobnym wierszu, a otrzymasz przeważnie pustą linię (i IMNSHO, bardziej czytelny kod). Jeśli musisz użyć klamry K&R na końcu linii, nie marnuj miejsca w pionie, oszczędzając miejsce za pomocą obcych pustych linii.

// I don't like this
if (something == anotherthing) {
    print ...
    update ...
}

// I much prefer this
if (something == anotherthing)
{
    print ...
    update ...
}

// I loathe this - not least for its inconsistent spacing
if (something == anotherthing) {

    print ...
    update ...
}

// I loathe this too, for its absurd waste of vertical space
if (something == anotherthing) {

    print ...
    update ...

}

Napisz to, co jest najbardziej czytelne i najmniej zaskakujące.

function validEmail($addr) {
    $regex = "/.../";   
    return preg_match($regex, $addr);
}

Ta funkcja nie wymaga 12 wierszy komentarzy do dokumentu.

W rzeczywistości nie potrzebuje żadnych komentarzy.

Lub puste linie.

Utraciliby jego istotę.

Wewnątrz funkcji? Rzadko

Jeśli mam wyraźny inny blok, refaktoryzuje się do nowej funkcji. Jeśli kilka przypadków nie jest tego warte.

Dla mnie puste linie wewnątrz funkcji są jedną z najbardziej złych „najlepszych praktyk”.

Często

Użyj go do logicznych bloków kodu, które są przetwarzane podobnie. Po dodaniu komentarza pokazującego, że robisz inny krok - czas wyodrębnić metodę.

Dobra biała spacja

{
    int x = computeX();
    x += ADJUSTMENT_FACTOR_X;

    int y = computeY();
    y += ADJUSTMENT_FACTORY_Y;

    setPosition(x, y);
}

Zła biała spacja

{
    //Open a connection
    String serverAddress = lookupAddress();
    Connection connection = openConnection(serverAddress);
    connection.login(user, password);


    //Go get stuff from the server
    item1 = connection.get(1);
    item2 = connection.get(2);

    //Close connection
    connection.close();

    //log data
    log(item1);
    log(item2);

    //Update client
    gui.updateView(item1, item2);        
}    

vs

{
    Connection connection = openConnection();
    updateData(connection);
    closeConnection(connection);
    logUpdate();
    updateGui();
}

vs

{
     updateDataFromServer();
     logUpdate();
     updateGui();
}

Używam nie tylko białych znaków, ale i nawiasów klamrowych dla zachowania przejrzystości.

Nawiasy klamrowe używam, aby powiedzieć, że mogą to być funkcje.

code
{
    code
    code
    code
    code
}
{
    code
    code=code
    code
    code

    code()
    code()
}

Pewnego razu swobodnie posypywałem puste wiersze całym kodem. Obecnie jestem bardziej oszczędny. Myślę, że jest to część tego, o czym mówił tutaj Steve Yegge :

Mam nadzieję, że scena, którą do tej pory namalowałem, pomaga zrozumieć, dlaczego czasami patrzysz na kod i po prostu go nienawidzisz. Jeśli jesteś n00b, spojrzysz na doświadczony kod i powiesz, że jest to nieprzeniknione, niezdyscyplinowane badziewie napisane przez kogoś, kto nigdy nie nauczył się podstaw współczesnej inżynierii oprogramowania. Jeśli jesteś weteranem, przyjrzyj się kodowi n00b i powiedz, że to przesadzone, ozdobne puchaty, które stażysta mógł napisać podczas jednej nocy intensywnego picia.

Punktem zaczepienia jest tolerancja na ściskanie. Gdy piszesz kod przez całą swoją karierę, szczególnie jeśli kod obejmuje wiele różnych języków i domen problemowych, twoja tolerancja na kompresję kodu wzrasta. Nie różni się niczym od czytania książek dla dzieci z ogromnym tekstem do coraz bardziej złożonych powieści z mniejszym tekstem i większymi słowami.

...

Programiście o wysokiej tolerancji na kompresję przeszkadza ekran opowiadania historii. Czemu? Ponieważ aby zrozumieć bazę kodu, musisz umieć spakować jak najwięcej jej do głowy. Jeśli jest to skomplikowany algorytm, doświadczony programista chce zobaczyć całą rzecz na ekranie, co oznacza zmniejszenie liczby pustych linii i wstawianie komentarzy - szczególnie komentarzy, które po prostu powtarzają to, co robi kod. Jest to dokładnie odwrotność tego, czego chce programista n00b. n00bs chce skupić się na jednym wyrażeniu lub wyrażeniu na raz, przesuwając cały kod poza pole widzenia, aby mogli się skoncentrować i wypłakać głośno.

Zasadniczo się z nim zgadzam. Znacznie lepiej jest skompresować kod, aby uzyskać jak najwięcej na jednym ekranie, niż zbyt dużo miejsca. Nie oznacza to, że nigdy nie powinieneś używać pustych linii. Po prostu myślę, że jeśli grupa, którą próbujesz utworzyć, nie zwiększy czytelności w ogromnym stopniu, wyrządzi więcej szkody niż pożytku.

Emerytowany profesor udzielił dwóch wielkich rad

1. Biała spacja jest bezpłatna
2. Nie używaj zszywek, które wbijają się w przód papieru, inaczej cię zawiodę.

Moje podstawowe zasady są następujące:

1. Jeśli mam problem z odczytaniem kodu, który napisałem wczoraj, prawdopodobnie muszę wyodrębnić metodę lub trzy.

2. Jeśli definicja mojej klasy jest zbyt długa, aby ją łatwo odczytać, prawdopodobnie potrzebuję wyodrębnić moduł / interfejs / obiekt.

3. Definicje metod: dodaj linię

4. Definicje modułów / klas: dodaj dwa wiersze

Lubię myśleć o białych znakach w taki sam sposób jak akapity. Grupujesz razem linie, które przyczyniają się do jednego pomysłu.

Jeśli zaczynasz nowy pomysł lub nowy aspekt tego samego pomysłu, zaczynasz nowy akapit - taki jak ten.

W kodzie rozkazującym grupuję zadania, które wykonują jedno spójne zadanie; w kodzie deklaratywnym grupuję razem kod opisujący jedno spójne zdanie pomysłu.

Najwyraźniej nie masz problemów z robieniem tego po angielsku (niektórzy są okropni z akapitami), więc przy odrobinie praktyki stosowanie tej samej umiejętności do kodu nie powinno być wcale trudne.

Puste linie są moim zdaniem koniecznością. Używam ich do oddzielania różnych logicznych bloków kodu. Sprawia, że ​​kod jest czytelny. Czytelny kod to dobry kod;)

Moim idealnym fragmentem kodu byłoby oddzielenie każdego bloku logicznego pustą linią i komentarzem na górze każdego bloku, który ma większą logikę.

Oczywiście, jeśli ludzie to robią, dodając wszędzie wiele pustych linii, uważam to za bardzo irytujące :(

Używam białych znaków w funkcji / metodzie do oddzielania deklaracji i kodu.

Jeśli odczuwasz potrzebę posiadania kilku linii do oddzielenia podbloków kodu implementujących pewną logikę, powinny one być w innej funkcji / metodzie prywatnej. Od kompilatora zależy, czy nie spowoduje to zbyt dużego obciążenia.

zazwyczaj w kodzie peusdo:

def function(arg1, argn, ...)
    INITIALIZERS

    CODE
    BLOCK_START
        INITIALIZERS

        CODE
    BLOCK_END
    CODE
end

Jeśli widzę bezużyteczne białe znaki, zwykle kulę się.

Biała przestrzeń jest niezwykle cenna.

Oto oferta ... frajerzy, którzy piszą skomplikowany kod, taki jak E = MC ² świetnie pokazują swoje umiejętności programowania.

Teraz przeskoczmy o sześć miesięcy, a jest druga w nocy, a system, który nie był obserwowany przez sześć miesięcy, zepsuł się na samej linii E = MC ² . To jest prawie niemożliwe do debugowania ... wszyscy wariują.

Załóżmy, że kod wyglądał mniej więcej tak ...

See Dick
See Jane
See Dick and Jan

Jeśli jest druga w nocy, a kod jest uszkodzony. Szybki rzut oka pokaże, że trzecia linia powinna być

See Dick and Jane

Problem rozwiązany.

Dolna linia ... użyj białych znaków.

Jak wielu innych stwierdziło, puste wiersze ułatwiają czytanie kodu. Istnieje jednak kilka języków, które egzekwują ten standard. Jednym z nich, który mogę wymyślić z czubka głowy (nie tyle o pustych liniach, ale o prawidłowym wcięciu) jest Python.

Zgadzam się, używam białych znaków w ten sam sposób. Jeśli jednak używam białych znaków do dzielenia metody na zbyt wiele części, jest to znak, że może być konieczne przeformułowanie tego kodu na wiele metod. Zbyt wiele logicznych sekcji w metodzie może sygnalizować, że metoda będzie trudniejsza do przetestowania.

Używam ich do dzielenia kodu na jednostki logiczne. Widziałem bardzo niewiele próbek kodu, które nie używały pustych wierszy, oczywiście oczywiście zaciemnianie.

Odpowiedź Psychopaty jest najlepsza, ale zastąpiłbym to założeniem, że następna osoba jest idiotą i że założy, że jesteś, i będziesz chciał udowodnić, że się mylą.

Równie ważne dla czytelności jest stosowanie komentarzy. Każdą funkcję lub podprogram otwieram za pomocą bloku komentarza, wyjaśniając czystym tekstem, co to jest, co robi, jakie są argumenty i jakie są oczekiwane wyniki (w tym lista warunków błędów). Wtedy nie ma wątpliwości co do tego, co jest przeznaczone i / lub zaprojektowane do zrobienia. To, co osiąga, może się różnić, ale jest to bardziej skomplikowane.

Myślę, że zbyt wielu programistów albo zakłada, że ​​to oni sami będą przeprowadzać „naprawy” kodu, albo po prostu ich to nie obchodzi.

Ważne są puste linie. Jednak marnowanie całej pustej linii na nawiasie otwierającym zmniejsza ilość kodu widocznego na ekranie. Powinno być:

for (int i; i < 10; ++i)
{  if (i % 3 == 0) continue;

   array[i] += 2;
}

(Nie zaczynaj mnie od umieszczania klamry „{” w tej samej linii co „for” ... to jest meshuggah).

Tak. Dla czytelności. Czasami wstawiam nawet puste wiersze w kodzie, których nie napisałem. Łatwiej jest mi zrozumieć kod, gdy mają logiczne grupowanie za pomocą pustych linii - na przykład, że można go „szybko odczytać”.

Powinniśmy używać pustych linii między blokami kodu, jak w przypadku pisania listu.

Na przykład między funkcjami lub wewnątrz funkcji po zakończeniu pętli ...

Ludzie podziękują ci za czysty kod, jeśli będą musieli go konserwować;)

Używamy białych znaków zalecanych przez Microsoft StyleCop. Oprócz czytelności i spójności odkryłem, że (wraz z małymi rozmiarami klas) odpowiednio rozmieszczony kod znacznie ułatwia zarządzanie połączeniami, gdy różne osoby w zespole pracują w tych samych obszarach.

Nie jestem pewien, czy to tylko moja wyobraźnia, ale różne narzędzia wydają się lepiej rozpoznawać, gdzie równoważny kod zaczyna się i kończy po scaleniu, gdy jest starannie ułożony. Ładnie ułożony kod jest przyjemnością. Ok, to było kłamstwo - ale przynajmniej ból utrzymuje się na możliwym do opanowania poziomie.

Nigdy nie pusta linia, nie w całym pliku. Nie oznacza to, że w kodzie nie ma przerw:

 code;
 //
 morecode;

Puste wiersze służą do otwierania sekcji kodu, na których można pracować, w edytorze znajduje się kilka klawiszy skrótu, które prowadzą do pustej poprzedniej / następnej linii.