Sprzeczne style Java w zespole

Należę do zespołu programistów Java z terminem 6 tygodni. Wymaga to bardzo szybkiego napisania dużej części kodu. Jednak nasz zespół programistów ma różne style kodowania. Wszystko, od konwencji nazw po metody abstrakcji, różni się w naszym zespole. Czy ktoś wie o dokumentach, które określają „standardy” java?

Aby to wyjaśnić, zastanawiałem się, czy istnieje organizacja, która dyktuje na przykład odpowiednią konwencję nazewnictwa dla zmiennych i funkcji. Jest to nadrzędne, ponieważ przy tak krótkim terminie nie możemy sobie pozwolić na poświęcenie czasu na wzajemne zrozumienie kodu.

Istnieje taka organizacja: samo Sun / Oracle. Dokument nazywa się Konwencje kodu dla języka programowania Java i opisuje większość potrzebnych konwencji. Poproś wszystkich, aby zgodzili się go przeczytać i postępować zgodnie z jego zaleceniami.

Naprawdę traktuję odpowiedź Andresa i skupiam się na aspekcie jednolitego formatowania kodu Java.

Jeśli korzystasz z Eclipse, możesz ustawić jego formater Java na automatyczne formatowanie do standardu Java. Formatyzator Eclipse ma również inne pomocne ustawienia, takie jak znaki w wierszu (tj. Ile znaków w wierszu przed podziałem do nowego wiersza) i wiele innych. Standaryzacja znaków w wierszu ułatwia różnicowanie kodu napisanego przez różnych programistów bez dużych różnic tylko z odstępów i podziałów wierszy.

Wreszcie w Eclipse, po ustawieniu wszystkich wymaganych ustawień, wyeksportuj swój formatyzator jako plik, który może zostać zaimportowany przez każdego członka zespołu. Więc jeśli używasz Eclipse, zdecydowanie polecam pełne zbadanie wszystkich opcji, które automatycznie sformatuje i edytuje kod, a następnie udostępniam ustawienia całemu zespołowi.

Zakładam, że inne główne środowiska IDE Java (IntelliJ i Netbeans) mają podobną funkcję do eksportowania ustawień formatu.

Ten [inny styl kodowania] jest najważniejszy, ponieważ w tak krótkim terminie nie możemy sobie pozwolić na poświęcenie czasu na wzajemne zrozumienie kodu.

Tak właściwie. To nie jest najważniejsze.

Po 30 latach pracy jako konsultant przeczytałem dużo kodu od wielu klientów. Ważne jest, aby pamiętać, że każdy klient (i często w organizacji klienta) ma różne style.

Po przeczytaniu tak wielu stylów nauczyłem się tego.

Styl nie ma znaczenia

Skoncentruj się na pisaniu kodu, który zawsze działa, i pisaniu testów jednostkowych, które dowodzą, że zawsze działa.

Po wysłaniu działającego kodu możesz go ubrać, jeśli zabraknie błędów do naprawy i ulepszeń do zainstalowania.

Nie martw się o wybór idealnego uniwersalnego standardu. Wszystko, czego potrzebujesz, to aby Twój zespół zgodził się na jeden standard i trzymał się go. Stwórz własny, jeśli chcesz, ale bądź konsekwentny.

Spójność poprawia współpracę, współpraca poprawia kod.

Nawet jeśli faktyczna spójność nie pomaga, fakt, że Twój zespół pracował razem, aby dojść do porozumienia, jest dobrą rzeczą. Ich niezdolność do zgodzenia się na coś tak prostego jak konwencje kodowania mówi, że pod powierzchnią mogą kryć się większe problemy w pracy zespołowej.

Wspomniane powyżej oprogramowanie Sun Java CC ma nie tylko 13 lat, a niektóre z jego zasad są nieaktualne (np. 80 znaków w wierszu), ale także nie definiuje konwencji nazewnictwa, z wyjątkiem najbardziej ogólnych (obudowa wielbłąda dla klas, wielkie litery bloków) dla statycznych zmiennych końcowych i tym podobnych).

Musisz zdefiniować własne standardy dla różnych typów klas, takich jak DAO, EJB, podmioty, cokolwiek użyjesz. Sun Java CC jest jak abstrakcyjna klasa podstawowa przeznaczona do rozszerzania :)

Jak wspomnieli inni tutaj, możesz wyszukać w Internecie jeden z niewielu popularnych „przewodników po stylach” dla Javy i przekonać wszystkich członków zespołu, aby trzymali się ich. Niektóre narzędzia do sprawdzania kodu w twoim ulubionym IDE mogą pomóc ci przypomnieć, kiedy tego nie robisz.

Jednak czasami w grę wchodzi polityka. Kiedyś znajdowałem się w sytuacji, w której najbardziej zaawansowany programista w zespole nadal robi to po swojemu, nawet gdy ktoś wspomniał o potrzebie standaryzacji. W takiej sytuacji być może lepiej będzie obserwować jego styl kodu i podążać za nim, ponieważ prawdopodobnie ma on największą wiedzę na temat bazy kodu i wymagań i możesz nie chcieć tracić czasu na nadepnięcie na palce, nawet jeśli jest on trudny. Tak zrobiła reszta z nas w tej konkretnej sytuacji, a ja niechętnie podążam za nią.

Dlatego ważne jest, aby wziąć pod uwagę również swoją sytuację.

Wujek Bob pokazuje bardziej nowoczesny i aktualny styl kodowania w swojej książce „Clean Code”. Niestety nie zawiera żadnej listy przedmiotów. Musisz to przeczytać. Sam mówi, że aby zobaczyć jego konwencje, musisz przeczytać jego kodeks. Wujek Bob jest bez wątpienia rodzajem instytucji. Książka i tak jest świetną lekturą, więc nawet jeśli jest już za późno, by ją teraz przeczytać, przeczytaj ją jak najszybciej.

W kodzie naprawdę liczy się niska cykliczność, mały zakres, wysoka spójność i wybór ekspresyjnych identyfikatorów. Biorąc to pod uwagę, kod staje się łatwy do zrozumienia i taki kod jest dobry.

Proponuję zajrzeć do programowania Spartan .

Większość standardów kodowania mówi, jak sprawić, by źle napisany kod wyglądał ładnie, a większość dyskusji na temat „stylu kodowania” dotyczy w rzeczywistości formatowania. Formatowanie kodu polega na wizualnym przedstawieniu struktury kodu. Jest trywialny i automatyczny i nie ma prawie nic wspólnego ze stylem kodowania, ponieważ styl kodowania nie polega na tym, jak reprezentujesz strukturę kodu, ale na tym, jak tworzysz kod.
Istnieje również wiele wojen religijnych na temat konwencji nazewnictwa, chociaż tak naprawdę to tylko hack do obejścia złego projektu. Nazwa jest dobra, jeśli mówi, co to znaczy. Im mniejsze i wyraźniejsze lunety, tym łatwiej wybrać taką nazwę.