SUCHY sposób pisania Javadoc na metodach przeciążania


Odpowiedzi:


3

Posypuję {@inheritDoc}dyrektywy tu i tam w moich komentarzach Javadoc, gdy zastępuję metody z nadklas lub implementuję metody zdefiniowane w interfejsie.

Działa to przynajmniej dla mnie dobrze, pozwala uniknąć powtórzeń w kodzie źródłowym, a jeśli chcesz, możesz dodać szczegółowe informacje do konkretnego komentarza Javadoc. Nie uważam, że sam komentarz Javadoc nie stanowi prawie żadnego problemu, gdy wystarczy przyzwoitego IDE, aby najechać kursorem myszy na nazwę powiązanego identyfikatora, aby uzyskać renderowany Javadoc z referencjami i wszystkim.


2

Dokumentacja ma na celu oświecenie przyszłych użytkowników przedmiotu. Dzieje się tak częściowo dla wygody autora, aby nie trzeba było się z nim kontaktować, ilekroć ktoś nie może dowiedzieć się, jak to działa. Przeważnie jest to jednak z korzyścią dla osób, które muszą używać lub wspierać rzecz.

W związku z tym chodzi o jasność, a nie o wygodę autora. Nie możesz oczekiwać, że ludzie będą przeszukiwać dokumentację API, ponieważ byłeś zbyt leniwy, aby się powtarzać. Ssij to - Javadoc będzie powtarzalny.

To powiedziawszy, nie ma powodu, jeśli jesteś sprytny, nie możesz napisać programu, który wstawiałby komentarze do kodu na podstawie markerów lub innych kryteriów. Może to być więcej kłopotów niż jest to warte. Albo nie.


4
Nie, nie powtarzaj się; po prostu o wiele więcej narzutów, aby wszystko zsynchronizować. Jeśli pojawią się nowe informacje o przeciążonej implementacji, napisz tylko to. Sądzę, że uzasadnione jest oczekiwanie od użytkowników tego typu spojrzenia na javadoki jego nadtypów, a narzędzia takie jak Eclipse ułatwiają im to.
Dawood ibn Kareem
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.