Jak używasz pustych linii w kodzie?

31

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?

Matthieu M.
źródło
6
if (i % 3 != 0) { <newline here> array[i] += 2; <newline here> }, ale rozumiem twój punkt :)
Merlyn Morgan-Graham
Tego rodzaju pytania niekonstruktywne . Tylko tyle razy możesz sformułować tylko dwie dostępne odpowiedzi: „tak” i „nie”.
1
Lepszym pytaniem byłoby, jak i dlaczego używasz pustych linii? Używam pustych linii dokładnie tak samo jak ty, z tą samą motywacją.
Dominique McDonnell,
1
@Mark, @takeshin: przepraszam, zapomniałem słowa kluczowego „jak”. To oczywiste, że wszyscy z nich korzystamy, starałem się zobaczyć, jak ludzie z nich korzystają (rozdzielanie klas, jeśli / jeszcze itd. Itd.), Ale wydaje się, że otrzymałem bardzo ogólne odpowiedzi: p
Matthieu M.,
3
for (int i = 0; i < 10; i += 3) { <newline here> array[i] += 2; <newline here> }ale rozumiem twój punkt :)
Berin Loritsch

Odpowiedzi:

87

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ą.

Jeff Atwood
źródło
12
Słyszę, jak ktoś mówi „ale wtedy powinieneś wyodrębnić metodę!”. Akapit jest przeznaczony, gdy nie ma wystarczającego powodu do wyodrębnienia metody.
Frank Shearar,
1
Łatwo jest eksperymentować i sprawdzać, czy lepiej mieć pionowe białe znaki, czy nie. Weź nieznany ci plik źródłowy, usuń wszystkie puste wiersze, a następnie spróbuj zastosować się do logiki. Nawet przy właściwym wcięciu będzie to wyczerpujące psychicznie, ponieważ puste linie dają nam szansę zobaczenia rzeczy w kawałkach wielkości kęsa. Muszę zachować trochę kodu, który nie używał dużo pionowej pustej przestrzeni ani wcięć, więc dodanie tego było jednym z moich pierwszych zadań do samozachowawczości.
Tin Man,
2
Zgadzam się w 100%. Biała spacja jest przydatna, gdy jest używana do celowego dzielenia kodu na logiczne fragmenty. Jednak białe znaki ze względu na białe znaki są tak samo złe, jak brak białych znaków. Jeden były kolega lubił wstawiać jedną lub więcej pustych linii po prawie każdym wierszu rzeczywistego kodu. Spędziłem absurdalnie dużo czasu na „refaktoryzacji”, która polegała na uderzeniu w Backspace kilka tysięcy razy, aby usunąć niepotrzebne puste linie.
Mike Spross
Dodałem trochę danych na poparcie twojej pozycji. Zobacz: meta.programmers.stackexchange.com/questions/1109/…
Jeff Atwood
2
Te dane nie mówią nic o pustych liniach, tylko o wcięciach.
Blorgbeard
21

Tak dla jasności.

Tak jak zrobiłem w tej odpowiedzi.

użytkownik2567
źródło
13

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

(This line intentionally left blank.)

na linii

Don
źródło
1
Białe linie z komentarzami mogą zwrócić uwagę na kod
JulioC
1
To wiele komentarzy mówiących „Ta linia celowo pozostawiona pusta” ... Nie możesz założyć, że jeśli linia jest pusta, jest celowa, bo inaczej nie przejdzie przeglądu kodu?
alternatywny
43
Może to tylko ja, ale założyłem, że OP żartuje ...
JSB ձոգչ
7
Jak długo pracujesz dla IBM?
Guillaume,
12

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.

Allon Guralnek
źródło
1
Wygląda na coś, co można wykorzystać na kursie wprowadzającym na poziomie college'u, aby kierować niektórymi koncepcjami. Czy faktycznie wykorzystano to w środowisku profesjonalnym?
rjzii
1
@Rob: Użyto go w kodzie produkcyjnym dużego systemu, ale bez nagłówka komentarza i mając wystarczająco duże ciała metod, że wyrównanie mnie zdziwiło, ponieważ nie widziałem innych sygnatur metody w tym pliku. Kiedy zawaliłem ciała metod, byłem w stanie zobaczyć „przyczynę” spacji.
Allon Guralnek
Może to działać w pliku nagłówka lub pliku interfejsu
Ming-Tang
Więc facet, który napisał ten schemat wcięcia, kiedy dodał nową metodę do klasy, a typ zwracanej metody był dłuższy niż jakikolwiek z istniejących typów zwracanych, ponownie zestawiłby wcięcie białych znaków dla wszystkich innych metod w klasa?
Mike Clark,
@Mike, w szkole średniej użyliśmy książki programistycznej Java (nie pamiętam tytułu), która mądrze odradza stosowanie poziomych odstępów w ten sposób, po prostu dlatego, że kończy się to marnowaniem dużej ilości czasu, gdy trzeba dokonać takich ponownych tabel.
Matthew Flaschen
5

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ę”.

Bryan Harrington
źródło
Zakładasz, że dekompresja kodu pomaga w czytelności i nie sądzę, że to zawsze jest pewne.
Jason Baker,
Co powiedział Jason. Kiedy wracam do bazy kodu, lubię mieć jak najwięcej LOCów na ekran, jak to możliwe, aby szybko go przetrawić. Jeśli ktoś umieści pół strony białej spacji (albo niech Bóg zabroni jednego z tych okropnych komentarzy w stylu xml), bardzo mnie pokusi, aby tymczasowo sformatować go tylko po to, aby go przeczytać, a następnie undokilka razy, aby wykonać pracę nie prowadzą do produktywności, więc nie usunęłbym wprost komentarzy i spacji, ale wolę je w większości).
Inaimathi,
Ściana tekstu jest prawie niemożliwa do odczytania, nie mówiąc już o psychologii człowieka, która się jej opiera. Myślę, że poświęcenie czasu na zgrupowanie podobnych instrukcji razem, dobre jest również grupowanie linii kodu, które manipulują tą samą zmienną. Wydaje mi się, że to wszystko jest preferencją, ale myślę, że cokolwiek zrobionego w tym biznesie nigdy nie powinno być zrobione szybko.
Bryan Harrington
5

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

Trynidad
źródło
4
Często też piszę sprzęt, a następnie go drukuję. Jest o wiele tańszy.
Tim Post
5
Żart Dos Equis?
Paperjam
@ Tim W rzeczywistości nie jest to takie zabawne: drukowanie 3D ;) (I… bądź miły, nie wszyscy jesteśmy rodzimymi użytkownikami języka angielskiego :).
bierze
1
@takeshin Nie naśmiewałam się z nikogo i nawiązywałam do drukowania 3D. Chociaż tak, komentarz miał na celu żart, myślę, że mógłbyś źle interpretować zamiar :) Ponadto fakt, że @Paperjam skomentował żart o drukowaniu jest ... no cóż ... bezcenny :)
Tim Post
Ja nie piszę oprogramowania, ale go podłączam.
mlvljr
5

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.

Jay Bazuzi
źródło
5

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
Nathan Long
źródło
4

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 ...

}
Jonathan Leffler
źródło
3

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ę.

KevBurnsJr
źródło
1
Przydałby się komentarz na górze opisujący, jakie adresy są akceptowane. Czy naprawdę można użyć wyrażenia regularnego do sprawdzenia poprawności adresu e-mail?
kevin cline
3

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”.

Maniero
źródło
2

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();
}
Steve Jackson
źródło
4
Zakładam, że twój przykład Bad Whitespace jest skróconą wersją tego, co należy uznać za złe. Przy obecnej długości nie jest konieczne dzielenie go.
Allon Guralnek
1
nie rozumiem, dlaczego zło jest złe, ani dlaczego napisałeś VS
5
Żadna z tych uwag są potrzebne byle jak, i dlaczego na świecie nie jeden wyciąg connection.close()docloseConnection(connection)
alternatywa
Blok kodu z komentarzem jest lepszy niż wyodrębniona metoda, o ile bloki są krótkie i mało. Wyodrębnianie metod nie jest darmowe; ma koszt lokalizacji kodu.
Craig Gidney
I po prostu zrobić item1i item2zmienne globalne że metody komunikowania się poprzez? Ick!
TMN
2

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()
}
użytkownik2528
źródło
2

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.

Jason Baker
źródło
2

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ę.
Wonko przy zdrowych zmysłach
źródło
1

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

filozofodad
źródło
1

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.

Rei Miyasaka
źródło
1

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 :(

Karun AB
źródło
1

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ę.

szaleńca
źródło
Wygląda to na C, mój standard kodowania C ++ NIE zaleca deklarowania obiektu bez jego inicjalizacji, co wyklucza takie użycie: /
Matthieu M.
@ Matthieu M: OK, a następnie zastąp DEKLARACJE przez INICJALIZATORÓW. Ale nigdy nie chcę widzieć INICJALIZATORÓW na środku bloku. Jeśli tak musi być, jest to coś, co wymaga mniejszego zakresu, więc potrzebuje prywatnej metody / funkcji.
haylem
0

Biała przestrzeń jest niezwykle cenna.

Oto oferta ... frajerzy, którzy piszą skomplikowany kod, taki jak E = MC 2 ś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 2 . 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.

Cape Cod Gunny
źródło
1
Erm ... żaden z tych przykładów nie popiera jednak twojej tezy. Osobiście uważam, że E = MC2 jest bardziej czytelny niż E = MC 2 (dolna linia miała używać białych znaków, prawda?). Aha, i chyba że jesteś jeszcze w szkole średniej, jestem pewien, że możesz wymyślić lepszy sposób na odniesienie się do ludzi, z którymi się nie zgadzasz, niż „kujony”.
Jason Baker
@Jason - Dobry punkt zły wybór słów. E = MC2 jest znacznie bardziej czytelny, nie o to mi chodziło. To bardziej, jak mówiłeś na swojej stronie YAGNI i SYNDI. jasonmbaker.com/tag/programming
Michael Riley - AKA Gunny
0

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.

Skudd
źródło
0

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żytkownik7187
źródło
0

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.

kirk.burleson
źródło
0

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.

Piotr
źródło
0

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).

użytkownik7195
źródło
2
TAK. Chcę zobaczyć całą twoją funkcję na jednym ekranie. Nie umieszczaj otwierającego nawiasu klamrowego na własnej linii. Do tego właśnie służy wcięcie.
KevBurnsJr
Cały nawias klamrowy na własnej linii polega na wyraźnym zdefiniowaniu bloków kodu. Dodanie wiersza kodu po klamrze rujnuje jedyny powód, dla którego ta religia jest utrzymywana! Równie dobrze możesz umieścić go w tym samym wierszu, co „for”.
Gary Willoughby
0

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ć”.

javacruiser
źródło
0

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żytkownik7242
źródło
0

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.

FinnNk
źródło
0

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.

znak
źródło