na początek
Na początku był kod. Kod, który się rozrastał, żył, ewoluował, a pracę nad nim wykonywało programistów wielu. I kod ten spełniał swoje zadanie. I nigdy nie dotknął go zbędny proces refaktoryzacji, co pozwoliło, że rozmiary jego były naprawdę okazałe, jego możliwości - mnogie, a czytelność - żadna."Na szczęście", w trakcie pracy nad kodem, wielu programistów, którzy mieli z nim do czynienia, otaczali kolejne linijki instrukcji, pokaźną ilością komentarzy, które miały na celu przekazać przyszłym pokoleniom tajemnice zawarte w kodzie i uzmysłowić jego działanie.
co było dalej?
Pewnego dnia, nowy programista, miał za zadanie wprowadzić kolejne modyfikacje w tym kodzie. Jakie było jego zdziwienie, gdy okazało się, że wewnątrz metod klasy było więcej komentarzy niż instrukcji. Były nawet zakomentowane stare fragmenty kodu z dopiskiem: "Może kiedyś się przyda" :)Nim przeczytał wszystko i doszedł do tego, które komentarze i zmiany były wcześniej, a które później, minęło sporo czasu. Niestety jego wiedza na temat funkcjonalności, którą miał modyfikować była nadal żadna, do tego w głowie kotłowało mu się sto tysięcy, niekiedy sprzecznych, informacji, na temat tego co, gdzie, kiedy i dlaczego? I czy te zakomentowane kawałki kodu rzeczywiście mogły się jemu (lub komukolwiek) kiedyś przydać?
A jeszcze nawet nie przebrnął przez właściwy kod!
komentarze poprawiają czytelność?
Nic bardziej mylnego. Dobrze przemyślany kod, o który się dba i w razie potrzeby - refaktoryzuje, klasy z odpowiednimi zależnościami, nie potrzebują komentarzy.I zazwyczaj kiedy się one pojawiają, przeszkadzają zamiast pomagać, odciągają uwagę od rzeczy istotnych.
nie komentuj starego kodu
Po co komentować stary kod? Bo może się przydać? Bo był fajny i szkoda go wyrzucać? Jakikolwiek powód by nie był, pozostawienie starego kodu w postaci komentarza nie ma najmniejszego sensu. Po to są systemy kontroli wersji, aby w każdej chwili można było dotrzeć do kodu, który kiedyś istniał.Pozostawianie tych zbędnych linii, sprawia, że kiedyś Ty bądź koledzy z zespołu będą zmuszeni przedzierać się przez niego i zastanawiać się, jakie były motywy postępowania osoby, która tego czynu się dopuściła. I najgorsze, jeżeli osoba pracująca nad nim (kodem) po Tobie, dojdzie do wniosku, że "ja to na wszelki wypadek zostawię".
komentowanie kroków w metodach
Niekiedy zdarza się, że metoda, z którą mamy do czynienia ma setkę lub, broń Boże, więcej linii kodu! Co wtedy? Komentarz pasuje jak ulał, żeby opisać kolejno wykonywane kroki, czyż nie?Nie. Skoro kroki są na tyle duże i skomplikowane i/lub jest ich tak wiele, że zastanawiasz się nad dodaniem stosownych komentarzy, to pora aby rozbić metodę na mniejsze części. Prywatne metody to naprawdę wspaniała rzecz i dzięki nim Twój kod pozostanie czytelny i prostszy do zrozumienia. Jeżeli uważacie mimo to, że logika stojąca za taką metodą jest warta opisania, to możecie dodać odpowiedni komentarz do metody, a nie w jej ciele.
Czasami zdarzają się sytuacje, że metod jest już tyle, że z przerażeniem decydujecie się na stworzenie kolejnej. W takim wypadku najwyższy czas na refaktoryzację, bo bardzo prawdopodobne, że Wasza klasa została obarczona zbyt wielką odpowiedzialnością.
to po co komuś komentarze?
Aby opisać atrybuty i metody klasy. Aby opisać samą klasę itp.Komentarze nie powinny być wykorzystywane do tłumaczenia kodu metod. Od tego mamy diagramy i dokumentację, dlatego mamy możliwość tworzenia metod prywatnych, dlatego powinniśmy pamiętać o dobrych, opisowych nazwach dla atrybutów, metod, zmiennych itp.
Zdaję sobie sprawę, że pewnie zdarzają się wyjątki od tych reguł lub z różnych powodów decydujemy się na ich złamanie. W takich sytuacjach warto pamiętać o kilku rzeczach: komentarz nie powinien zaciemniać kodu, nie powinien utrudniać jego zrozumienia, nie powinien skupiać na sobie całej uwagi. Powinien być on podpowiedzią, jak najmniej inwazyjną, nie powinien być główną treścią, na której się zatrzymujemy.
A najlepiej to wyjść z założenia, że komentować to można artykuły na blogach, a nie kod:D
// komentarz zbędny ;)
OdpowiedzUsuńMoja zasada jeżeli piszesz komentarze to nie pisz co kod robi tylko dlaczego to robi.
OdpowiedzUsuń// komentarz czy /** komentarz */ ? Bo jest zasadnicza różnica. Komentarz dokumentacji jest wymagany, a dobra dokumentacja zajmuje też sporo, jak masz ok 70k linijek kodu w projekcie i zajrzysz do niego za kilka miesięcy, to pamiętasz każdą z nich?
OdpowiedzUsuńTak jak napisałem we wpisie, komentarze służące do dokumentowania tego, czym się zajmuje klasa, po co jest atrybut, co robi metoda, to są komentarze, bez których sobie dobrego kodu nie wyobrażam.
UsuńMimo to, jeżeli te komentarze są duże, to wydaje mi się, że lepiej je przenieść w całości do dokumentacji, a nie pozostawiać w kodzie, bo sprawią, że kod będzie nieczytelny i przebrnięcie przez niego będzie żmudnym zadaniem.
Jak niby chcesz "przenieść" komentarze do dokumentacji. I jedno i drugie zajmuje miejsce. Poza tym jednym poleceniem można te komentarze/dokumentacje usunąć z pliku, więc wpis IMO bez sensu. Opublikowany tylko żeby nie powstała za duża luka, a tak na prawdę niczego konkretnego z niego nie wynika.
OdpowiedzUsuńPrzenieść powinno się komentarze, które mówią zbyt wiele (spotykam się nieraz z takimi), czyli takie, które informują nie tylko o tym, co dana klasa/metoda/itp. robi i do czego jest wykorzystywana, ale również jej zależności z innymi klasami, a od tego typu rzeczy mamy diagramy i dokumentację.
UsuńOczywiście, i jedno i drugie zajmuje miejsce, ale dzięki logicznemu podziałowi wiemy gdzie znajdziemy to, co nas interesuje.
Wpis, choć dla Ciebie może nie być odkrywczy, nie jest o niczym i nie jest zbędny. Znam dobrych programistów, którym zdarza się "popełnić" zły komentarz (właśnie po jednej takiej sytuacji powstał pomysł na wpis), a tym dopiero zaczynającym, takie rady mogą pozwolić nabrać dobrych nawyków.
Prócz komentarzy przed metodą, przydają się też komentarze w samym kodzie.
OdpowiedzUsuńSam komentarz powinien być zwięzły i jasny.
Komentarze "dokumentacja" mogą być dowolnie wielkie - obecne IDE pozwalają zwinąć komentarz, a "quick help" z pełnym objaśnieniem zawsze się przyda.
Nie wszystko jest sens wydzielać do osobnych funkcji/metod.
Jasne, że komentarze o charakterze dokumentacji (zakładam, że mowa o tych, które znajdują się przed klasą, metodą itp.) mogą być dowolnie wielkie, ale raczej nie zdarzyło mi się, żeby przekroczyły kilka linijek. W końcu pojedyncza klasa, a tym bardziej metoda nie powinna robić zbyt wiele, więc i komentarz nie będzie duży. Do opisu całego procesu (czyli interakcji kilku klas), to już mamy diagramy i dokumentację.
UsuńCo do komentarzy w ciele metod, to od półtora roku nie zdarzyła mi się ani członkom moich zespołów, sytuacja, w której byłby niezbędny.
Jednak nie wykluczam takiej możliwości. Z zasady zakładam, że nie ma reguł, od których nie istnieją odstępstwa. Czym innym jest 'nie powinieneś', a czym innym 'nie możesz':)
Nigdy nie jest "niezbędny", ja wolę mieć jedną linijkę komentarza co się dzieje.
Usuń