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?
źródło
if (i % 3 != 0) { <newline here> array[i] += 2; <newline here> }
, ale rozumiem twój punkt :)for (int i = 0; i < 10; i += 3) { <newline here> array[i] += 2; <newline here> }
ale rozumiem twój punkt :)Odpowiedzi:
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:
źródło
Tak dla jasności.
Tak jak zrobiłem w tej odpowiedzi.
źródło
Robię, ale upewniam się, że udokumentowałem to, umieszczając
(This line intentionally left blank.)
na linii
źródło
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:
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.
źródło
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ę”.
źródło
undo
kilka 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).Nie zawsze piszę oprogramowanie, ale kiedy to robię, używam pustych linii dla zachowania przejrzystości.
źródło
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:
Ponieważ masz kilku powiązanych członków, są oni kandydatami do nowej klasy.
Ilekroć kod jest na tyle niejasny, że chce komentarza, pytam, czy mogę dokonać refaktoryzacji, aby kod był wystarczająco jasny, aby nie potrzebować komentarza.
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.
źródło
Tak. Ułatwia wizualne skanowanie pliku. Między innymi sprawia, że jaśniej jest, z którą linią komentarz się zgadza.
źródło
Używam pustych linii oszczędnie i konsekwentnie, a konsekwencja jest ważniejsza niż oszczędnie. Jednak:
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.
źródło
Napisz to, co jest najbardziej czytelne i najmniej zaskakujące.
Ta funkcja nie wymaga 12 wierszy komentarzy do dokumentu.
W rzeczywistości nie potrzebuje żadnych komentarzy.
Lub puste linie.
Utraciliby jego istotę.
źródło
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”.
źródło
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
Zła biała spacja
vs
vs
źródło
connection.close()
docloseConnection(connection)
item1
iitem2
zmienne globalne że metody komunikowania się poprzez? Ick!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.
źródło
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 :
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.
źródło
Emerytowany profesor udzielił dwóch wielkich rad
źródło
Moje podstawowe zasady są następujące:
Jeśli mam problem z odczytaniem kodu, który napisałem wczoraj, prawdopodobnie muszę wyodrębnić metodę lub trzy.
Jeśli definicja mojej klasy jest zbyt długa, aby ją łatwo odczytać, prawdopodobnie potrzebuję wyodrębnić moduł / interfejs / obiekt.
Definicje metod: dodaj linię
Definicje modułów / klas: dodaj dwa wiersze
źródło
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.
źródło
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 :(
źródło
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:
Jeśli widzę bezużyteczne białe znaki, zwykle kulę się.
źródło
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 ...
Jeśli jest druga w nocy, a kod jest uszkodzony. Szybki rzut oka pokaże, że trzecia linia powinna być
Problem rozwiązany.
Dolna linia ... użyj białych znaków.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło
Ważne są puste linie. Jednak marnowanie całej pustej linii na nawiasie otwierającym zmniejsza ilość kodu widocznego na ekranie. Powinno być:
(Nie zaczynaj mnie od umieszczania klamry „{” w tej samej linii co „for” ... to jest meshuggah).
źródło
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ć”.
źródło
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ć;)
źródło
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.
źródło
Nigdy nie pusta linia, nie w całym pliku. Nie oznacza to, że w kodzie nie ma przerw:
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.
źródło