Komentarze „//…” na końcu bloku kodu po} - dobre czy złe? [Zamknięte]

Często widziałem takie komentarze:

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

a czasem nawet o ile

if (condition) {
   ...
} // if (condition)

Nigdy nie zrozumiałem tej praktyki i dlatego nigdy jej nie zastosowałem. Jeśli twój kod jest tak długi, że musisz wiedzieć, co to }jest za zakończenie, być może powinieneś rozważyć podzielenie go na osobne funkcje. Ponadto większość narzędzi dla programistów jest w stanie przeskoczyć do pasującego wspornika. I w końcu ostatnie jest dla mnie wyraźne naruszenie zasady SUCHEJ; jeśli zmienisz warunek, musisz pamiętać również o zmianie komentarza (w przeciwnym razie może to być nieporządne dla opiekuna, a nawet dla ciebie).

Dlaczego ludzie z tego korzystają? Czy powinniśmy go użyć, czy jest to zła praktyka?

Powiedziałbym, że jeśli kod jest tak długi, że nie można łatwo śledzić nawiasów klamrowych, kod wymaga refaktoryzacji w większości języków.

Jednak w językach szablonów (takich jak PHP) może to być poprawne, ponieważ możesz mieć duży blok HTML, który oddziela początek i koniec warunku lub strukturę pętli.

Jest to zapach kodu i zwykle kac ze starego stylu kodu. Przed przyzwoitym refaktoryzacją IDE było trudniejsze i nie tak powszechne jak obecnie, stąd metody były dłuższe i te komentarze były po to, aby pomóc w ich lepszej nawigacji.

To okropna praktyka, która stała się przestarzała z wielu powodów.

• Większość współczesnych IDE podkreśla odpowiedni nawias klamrowy, gdy kursor znajduje się na dowolnym symbolu.
• Jeśli kodujesz czysto, rzadko znajdziesz miejsce, w którym Twoja metoda ma więcej niż 10 linii.

Zauważyłem, że wielu programistów Java ma taki sposób myślenia, co sprawia, że ​​kod Java wygląda naprawdę brudnie i odwraca uwagę od kodu w kierunku komentarzy.

Zdecydowanie odradzam korzystanie z tego.

Kod jest odczytywany 10 razy więcej niż jest napisany.

Jeśli to ułatwia czytanie, zrób to.

Sugeruję również każdemu, kto to robi, że powinien przyjrzeć się innym sposobom ułatwienia czytania. Techniki refaktoryzacji, nawiasy na różnych liniach itp., O których wspominali inni ludzie, są dobre. Podział rzeczy na różne funkcje, metody lub klasy, tak aby kod sam się komentował, jest również dobry. Istnieją również sposoby na wyeliminowanie większości „if” i umieszczenie pętli „for” w oczywistych miejscach, eliminując w ten sposób potrzebę tego.

Ale czasami ludzie się uczą. Jeśli robią to coś, co naprawdę czyni kod bardziej czytelnym, zachęcaj go, a następnie zachęcaj do innych praktyk. Ludzie, którzy się uczą, zasługują na zachętę i bez względu na to, jak zaczną. Powiedzenie „To jest złe” nie jest tak przydatne, jak powiedzenie „Ta inna rzecz jest lepsza”.

Mam dużą bazę kodu (C ++) pełną tego rodzaju rzeczy:

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

W przypadku czegoś tak małego powiedziałbym, że wykracza to poza „zapach kodu” w „smród kodu”. Zwłaszcza w IDE, gdzie mogę dopasować nawias zamykający za pomocą naciśnięcia klawisza, aby znaleźć nawias otwierający. Biorąc pod uwagę dłuższą metodę, nadal biorę dopasowanie nawiasu klamrowego nad komentarzem terminalu. Takie uwagi odwracają moją uwagę i zwykle uważam je za hałas.

W C ++ istnieją dwie blokady, w których jest to nadal przydatne, a porada „podziel swój kod” nie musi wstrzymywać:

1. Dla przestrzeni nazw. Przestrzeń nazw może obejmować cały plik, a ten ostatni nawias może czasem zrzucić ludzi, więc przydatne jest dodanie komentarza wskazującego, że nawias to zamknięcie przestrzeni nazw. Jest to ważne ze względu na szczególny styl kodowania w mojej firmie, ponieważ nie wcinamy przestrzeni nazw, ponieważ zdecydowano, że takie wcięcie po prostu marnuje miejsce w pliku.

2. Dla par #ifdef / #endif. Czasami jest tam dużo kodu do kompilacji warunkowej, może być nieprzyjemnie z zagnieżdżaniem, a edytor, którego używamy często „pomocnie”, eliminuje wcięcia, więc komentarze są przydatne podczas szybkiego przeglądu.

Dla mnie kod musi być mylący, aby dodać komentarz taki jak ten, który podałeś.

Jeśli tylko mówi // instrukcja IF. Potem musisz się zastanowić, dlaczego tak jest.

Alternatywą do zobaczenia, co zamyka twój aparat ortodontyczny, jest otwieranie go w tej samej kolumnie, co kolumna zamykająca. Uważam to za znacznie jaśniejsze i bardziej czytelne.

Komentarz jest przydatny, gdy normalnie trudno byłoby go prześledzić, ponieważ otwarcie miało miejsce dawno temu. Zwykle powinno to się zdarzyć tylko dla przestrzeni nazw (szczególnie anonimowej w C ++, używanej do szczegółów implementacji w jednostce kompilacji). W większości innych przypadków powinno być oczywiste, co zamykasz.

Jest to w dużej mierze pozostałość po dawnych czasach pracy w oknach terminalu znaków 80x24, szczególnie jeśli korzystałeś z edytora okien, takiego jak EVE. Nawet teraz większość pracy wykonuję w sesji terminalowej przy użyciu vima i mogę podzielić sesję na trzy lub cztery okna podrzędne, więc naprawdę mogę wyświetlić tylko kilka linii w tym samym czasie.

To powiedziawszy, nigdy tak naprawdę nie rozgrzałem się do konwencji, chociaż uratowałoby to mój bekon przy więcej niż jednej okazji. Po prostu widzę to jako hałas. Jeśli twoje pętle lub warunki warunkowe stają się tak duże, tak, możesz rozważyć refaktoryzację.

w zasadzie podajesz wszystkie ważne powody, dla których nie chcesz tego używać. Każdy porządny programista powinien je zastosować. Więc dlaczego nie ludzie go używać? Ponieważ robią to źle i nie wiedzą lepiej.