Czy konieczne jest napisanie komentarza javadoc do KAŻDEGO parametru w sygnaturze metody?


18

Jeden z deweloperów w moim zespole uważa, że ​​konieczne jest napisanie komentarza javadoc do KAŻDEGO parametru w sygnaturze metody. Nie sądzę, aby było to konieczne, a nawet uważam, że może być szkodliwe.

Po pierwsze, uważam, że nazwy parametrów powinny być opisowe i samodokumentujące. Jeśli nie jest od razu oczywiste, do czego służą twoje parametry, prawdopodobnie robisz to źle. Rozumiem jednak, że czasami nie jest jasne, do czego służy parametr, więc w takich przypadkach tak, powinieneś napisać komentarz javadoc wyjaśniający parametr.

Ale myślę, że nie trzeba tego robić dla KAŻDEGO parametru. Jeśli jest już oczywiste, do czego służy parametr, komentarz javadoc jest zbędny; tworzysz dla siebie dodatkową pracę. Ponadto tworzysz dodatkową pracę dla każdego, kto musi utrzymywać Twój kod. Metody zmieniają się z czasem, a utrzymywanie komentarzy jest prawie tak samo ważne jak utrzymanie kodu. Ile razy widziałeś komentarz typu „X robi Y z powodu Z” tylko po to, aby zobaczyć, że komentarz jest nieaktualny, a w rzeczywistości metoda nie przyjmuje już parametru X? Dzieje się tak przez cały czas, ponieważ ludzie zapominają aktualizować komentarze. Twierdziłbym, że wprowadzający w błąd komentarz jest bardziej szkodliwy niż brak komentarza. A zatem istnieje niebezpieczeństwo przesadnego komentowania: tworząc niepotrzebną dokumentację, „

Szanuję jednak drugiego programistę w moim zespole i akceptuję, że być może ma on rację, a ja się mylę. Właśnie dlatego zadaję wam moje pytanie, koledzy deweloperzy: czy rzeczywiście konieczne jest napisanie komentarza javadoc dla KAŻDEGO parametru? Załóżmy, że kod jest wewnętrzny dla mojej firmy i nie zostanie wykorzystany przez żadną zewnętrzną stronę.


Wiele IDE Java (w szczególności Intellij) oznaczy brakujący parametr Javadoc jako ostrzeżenie w dokumentacji
Gary Rowe

NetBeans i Eclipse też.
Davor Ždralo

Odpowiedzi:


38

Adnotacje Javadoc (i słowem Microsoft XMLDoc) nie są komentarzami , lecz dokumentacją .

Komentarze mogą być tak rzadkie, jak chcesz; zakładając, że Twój kod jest w połowie czytelny, zwykłe komentarze są jedynie drogowskazami, aby pomóc przyszłym programistom w zrozumieniu / utrzymaniu kodu, na który patrzyli już od dwóch godzin.

Dokumentacja stanowi umowę pomiędzy jednostką kodu i jego rozmówców. Jest to część publicznego API. Zawsze zakładaj, że Javadoc / XMLdoc skończy albo w pliku pomocy, albo w wyskakującym oknie autouzupełniania / intellisense / uzupełniania kodu i będzie obserwowany przez osoby, które nie sprawdzają wewnętrznych elementów twojego kodu, ale po prostu chcą go użyć do jakiegoś celu ich własny.

Nazwy argumentów / parametrów nigdy nie są oczywiste. Zawsze myślisz, że są, kiedy spędziłeś ostatni dzień pracując nad kodem, ale spróbuj wrócić do niego po 2 tygodniach wakacji, a zobaczysz, jak bardzo są nieprzydatni.

Nie zrozum mnie źle - ważne jest, aby wybrać znaczące nazwy zmiennych i argumentów. Ale jest to problem dotyczący kodu, a nie dokumentacji. Nie traktuj dosłownie wyrażenia „samo dokumentowanie”; oznacza to w kontekście dokumentacji wewnętrznej (komentarze), a nie dokumentacji zewnętrznej (umowy).


1
+1: Jest tak samo ważny jak sam kod. Po prostu nie ma dobrych automatycznych testów.
S.Lott,

Jeśli parametry metody obejmują np. Trzy pary współrzędnych X i Y, które będą interpretowane jako sąsiednie rogi równoległoboku, czy bardziej użyteczne jest posiadanie sześciu małych kawałków dokumentacji, po jednej dla każdego parametru, lub opisanie celu metoda pod względem równoległoboku (x1, y1), (x2, y2), (x3, y3) i (x1 + x3-x2, y1 + y3-y2) [ten ostatni jest przeciwny (x2, y2)]? Jeśli cel metody jest zdefiniowany w kategoriach nazw parametrów, pomyślałbym, że dodatkowa dokumentacja dotycząca parametrów byłaby w wielu przypadkach zbędna.
supercat

1
@ superupat: Twierdziłbym, że w takim przypadku powinieneś refaktoryzować, tak abyś miał jeden typ danych Point, a funkcja po prostu zajmuje trzy Points(lub jeszcze lepiej ich tablicę / iterowalną). Im więcej parametrów ma metoda, tym trudniej jest ją wywoływać i tym bardziej niestabilna jest jej specyfikacja.
Aaronaught

@Aaronaught: To zależy w dużej mierze od sposobu użycia tej metody. Przeciążenie, które odbiera trzy Point, a jedno, które odbiera Parallelogram, może być pomocne, jeśli wielu dzwoniących może przekazać takie rzeczy. Jeśli jednak powstanie wiele Pointinstancji bez żadnego celu, ale zostaną przekazane do metody tylko raz , wówczas zbudowanie obiektów spowoduje, że kod będzie wolniejszy i trudniejszy do odczytania. Gdyby język obsługiwał agregacje, które byłyby i zachowują się jak wiązka wartości sklejonych razem z taśmą klejącą, a parametr typu agregującego można przekazać tylko przez ...
supercat

... zawarcie wartości w nawiasach klamrowych, to może być dobre zarówno z punktu widzenia wydajności, jak i czytelności. Java nie ma takiej koncepcji; język oparty na JVM mógłby wydajnie obsługiwać coś takiego dla parametrów (parametr Point p1może być przetłumaczony na int p1_x, int p1_y), ale JVM nie ma wydajnego mechanizmu dla funkcji zwracającej taką rzecz.
supercat

12

Skomentuj wszystko lub nic nie komentuj (oczywiście komentowanie wszystkiego jest znacznie lepszym wyborem). Pomyśl o kimś, kto używa twojego kodu, albo przeglądając API bezpośrednio w pliku źródłowym lub w wygenerowanym pliku doc ​​(tj. Wyjściu doxygen). Niespójności zwykle prowadzą do zamieszania, co prowadzi do czasu spędzonego na przeszukiwaniu źródła, aby dowiedzieć się, dlaczego coś nie zostało skomentowane, co prowadzi do zmarnowanego czasu, którego można by uniknąć, gdyby parametr został skomentowany w pierwszej kolejności.

Pamiętaj: coś, co ma dla ciebie sens, może być interpretowane zupełnie inaczej przez kogoś innego, bez względu na to, jak przyziemna jest twoja opinia (pomyśl o kimś, kto nie jest tak silny w języku angielskim, czytając i próbując zrozumieć Twój kod).

Powiedziawszy to wszystko, jeśli drugi programista podkreśla znaczenie dokumentowania wszystkiego, to równie duży nacisk (jeśli nie więcej) należy na aktualizację dokumentacji. Jak już wspomniałeś, nie ma nic gorszego niż przestarzałe komentarze (tak samo złe, jeśli nie gorsze niż pominięte dokumenty).


10

Zacznijmy od założenia, że ​​cykle programistów są zasobem, który staramy się zachować.

Oznacza to, że deweloperzy nie powinni tracić czasu na dokumentowanie oczywistych parametrów i zwracanych wartości, prawda?

Rozbijmy to.

Jeśli wszystko udokumentujemy, zakładając, że komentarze krańcowe są naprawdę trywialne i nie wymagają żadnych przemyśleń ani badań, kosztem jest dodatkowy czas na wpisanie komentarza i poprawienie literówek.

Jeśli wybieramy i wybieramy, koszty są następujące:

  • Posiadanie i wygranie kłótni z innymi programistami w zespole, którzy uważają, że wszystko należy udokumentować.
  • Dla każdego parametru określanie, czy należy to udokumentować, czy nie.
  • Więcej argumentów ze swoim zespołem, gdy ktoś ma inne zdanie na temat tego, czy parametr powinien zostać udokumentowany.
  • Czas spędzony na szukaniu kodu i badaniu, kiedy okazuje się, że parametr, który został uznany za oczywisty, nie jest taki.

Byłbym skłonny po prostu dokumentować wszystko. Minusem jest wyraźny, ale jest zawarty.


9

Jeśli i tak piszesz Javadoc, równie dobrze możesz napisać go całkowicie, nawet uwzględniając „oczywiste” parametry. Mogą być oczywiste dla ciebie lub innego programisty, ale każdy, kto na to patrzy, skorzystałby na znajomości intencji każdego parametru.

Jeśli chodzi o prawidłowe utrzymanie Javadoc, musisz użyć narzędzi do rozwoju, które ci w tym pomogą. Przychodzi mi na myśl Eclipse . Oczywiście, jeśli jest to ważne, musisz upewnić się, że wszyscy członkowie zespołu robią wszystko, aby zachować kod, w tym komentarze.


3

Nie zapominaj, że javadoc może być widoczny bez oddzielnego kodu, czego najlepszym przykładem jest sam interfejs API Java . Nie włączając javadoc do każdego parametru w metodzie, wprowadzasz w błąd metodę i sposób jej użycia.


Czy „a - argument, którego wartość bezwzględna ma zostać ustalona” naprawdę dodaje coś do dokumentacji Math.abs?
kevin cline

@Kevin cline może być przydatny w przypadku trudnych do myślenia ;-)
Gary Rowe

1

„konieczne” jest całkowicie subiektywne. Myślę, że pytasz: „w swojej sytuacji powinieneś dodać komentarz javadoc”. Nie znając zakresu ani kontekstu Twojej aplikacji, skąd mamy wiedzieć, co jest dla Ciebie odpowiednie?

Jeśli ten publiczny kod (tj. Kod przeznaczony dla innych, taki jak interfejs API), to tak, udokumentuj każdy parametr. Nie zakładaj, że czytelnik wie o projekcie tak samo jak ty. Ale w przeciwnym razie to od Ciebie i Twojego zespołu zależy podejmowanie własnych decyzji.


6
Uważam, że nawet jeśli nie jest publicznie dostępny, pomaga mi zrozumieć własny kod, gdy patrzę na niego lata później: P
Demian Brecht

1
Takie podejście jest również znane jako „Heck, sprawimy, że nowy facet będzie musiał przeczytać ten cholerny kod w 4 lata po naszym odejściu”. podejście.
Tim Williscroft
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.