Gra pomagająca wizualizować efekty stylu umieszczania nawiasów klamrowych w Javie

Celem jest bycie obiektywnym

Kilka lat temu wymyśliłem kreatywne podejście, aby pomóc ustalić i uzgodnić styl kodowania z nowym zespołem, nad którym pracowałem. Byliśmy na początkowym etapie kodowania nowego projektu z wykorzystaniem języka programowania Java. Poprosiłem, abyśmy zdecydowali i uzgodnili spójne wytyczne dotyczące stylu kodu jako zespół, z góry. Wiedziałem, że muszę wymyślić obiektywny i kreatywny argument, aby odnieść się do jednej z kontrowersyjnych debat dotyczących stylu kodu w Javie — gdzie umieścić nawiasy klamrowe.

Wybór kreatywności zamiast konfliktu

Pływanie pod prąd „ale wszyscy inni tak robią” jest trudne. Jest to jeszcze trudniejsze, gdy szanowana firma zajmująca się wyszukiwaniem przypieczętuje pieczęć aprobaty dla określonego stylu kodowania w Javie.

Aby pomóc mi przedstawić obiektywny argument za konkretnym stylem umieszczania nawiasów klamrowych, stworzyłem grę, którą nazwałem „Połącz nawiasy ortodontyczne”. Wziąłem kod z dwóch stworzonych przeze mnie przykładowych klas i wkleiłem je w talii Powerpoint i dosłownie narysowałem linie na górze kodu, aby połączyć nawiasy klamrowe początkowe i końcowe. Gra została zainspirowana jedną z moich ulubionych gier z dzieciństwa — „Połącz kropki”.

Wspaniałą rzeczą w „Połącz kropki” jest to, że zasady są proste i prawie każdy grał w tę grę w szkole. „Połącz szelki” jest również bardzo proste. Po prostu połącz początkowe i końcowe nawiasy klamrowe każdego zakresu kodu, rysując między nimi linię. Łatwy.

Przedstawiłem grę zespołowi, a kiedy skończyłem, nikt nie odpowiedział „ale wszyscy inni robią to w ten sposób”. Potwierdziło to, że co najmniej jeden zespół dobrze zareagował na kreatywny spór dotyczący stylu umieszczania nawiasów klamrowych.

Automatyzacja gry

Opowiedziałem mojemu przyjacielowi Vladimirowi Zakharovowi (Vlad) o tej grze io tym, jak skutecznie rozbroiła ona to, czego wcześniej doświadczyłem jako podżegającą debatę. Zapytałem Vlada, czy mógłby napisać kod w Javie, aby zwizualizować grę, którą mu opisałem. Vlad jest lepszy w programowaniu wizualnym niż ja, więc wiedziałem, że ułoży kod szybciej niż ja.

Vlad zrobił coś jeszcze lepszego niż tylko połączenie nawiasów klamrowych w pliku źródłowym. Pokolorował także bloki kodu zielonym podświetleniem. Ma to tę dodatkową zaletę, że wizualnie podkreśla białe znaki.

Obrazy w poniższej sekcji zostały wygenerowane przy użyciu zautomatyzowanej wersji Vlada „Connect the Braces” na rzeczywistym kodzie z Eclipse Collections Kata .

Ostrzeżenie! Graj dalej!

Poniższe obrazy są graficzne. Niektórym programistom mogą one przeszkadzać. Rzeczywisty kod źródłowy został użyty do stworzenia następujących elementów wizualnych. Wszelkie obrazy, których nie można odzobaczyć po przewinięciu poza ten tekst, są wyłączną odpowiedzialnością osoby przewijającej, a nie autora. Wszelkie owoce lub zwierzaki, które ucierpiały podczas dwóch rund „Połącz nawiasy klamrowe”, były wynikiem wyboru stylu kodu, a nie autora. Wybierz mądrze. Zostałeś ostrzeżony!

Runda pierwsza: owoce Enum

Runda druga: wyliczenie PetType

Wybieranie przejrzystości zamiast bałaganu

Wiem, że prawdopodobnie właśnie wszedłem do rwącej rzeki pełnej głodnych piranii, mając na sobie kąpielówki zrobione ze steku. Nie chcę przekonywać wszystkich, że określony styl umieszczania aparatu ortodontycznego jest „jedynym prawdziwym stylem”. Zdecydowanie jest jakiś styl, który preferuję, kiedy piszę kod, i muszę go argumentować w każdym projekcie, nad którym pracuję. Uważam, że kiedy przedstawiam swoje argumenty za pomocą tej gry, możemy prowadzić zdrową dyskusję na temat znaczenia estetyki, białej przestrzeni i wizualnego śledzenia dla skanowania kodu i czytelności.

Wybieram przejrzystość zamiast bałaganu. Sygnał ponad szumem. Wybieram styl po prawej stronie.

Cytując mojego przyjaciela Vlada:

Kiedy czytam kod, zwykle chcę zobaczyć albo „co”, np. jakie są obowiązki tej klasy, jaki jest kontrakt tej metody, jaki jest warunek wyzwolenia tej gałęzi — lub „jak”, np. jak ta metoda robi to, co robi, co się stanie, jeśli podążę za tą gałęzią i tak dalej. Wizualne oddzielenie tego, co i jak, pomaga mi zeskanować kod i skupić uwagę na tym, co jest ważne w danym momencie.

Styl formatowania nawiasów pionowych ma naturalny efekt czystego oddzielenia „co” od „jak” poprzez wprowadzenie spacji między sygnaturą (definicje klasy i metody) a implementacją (zmienne i kod). Nawiasy klamrowe początkowe i końcowe są zawsze w tym samym położeniu poziomym, a zmienność jest konsekwentnie oparta na głębokości zagnieżdżonych zakresów (np. instrukcje sterujące, takie jak if, for i while). Spodziewasz się zobaczyć podstawę piramidy z nawiasami klamrowymi, więc możesz bezpiecznie zignorować ich położenie, ponieważ wiesz, gdzie się znajdują. Ten styl jest łatwy do zaimplementowania automatycznego formatowania w twoim IDE i egzekwowania w kompilacji CheckStyle.

Od ponad 20 lat pływam pod prąd, używając tego stylu formatowania nawiasów klamrowych w Javie. Mam coś do powiedzenia programistom, którzy z mojego powodu muszą czytać lub pracować z bazami kodu sformatowanymi przy użyciu stylu umieszczania nawiasów pionowych.

Proszę bardzo!

Wyjątek od reguły

Wybieram inny styl umieszczania nawiasów klamrowych podczas tworzenia slajdów Powerpoint lub tekstu do książki z kodem Java. Tylko w tych dwóch mediach drukowanych prawie zawsze wybieram styl, który faworyzuje mniej linii kodu. Łamanie kodu na stronach jest niepożądane. Jest to kompromis wynikający z ograniczeń dostępnej przestrzeni w pionie. To narzucone ograniczenie nie istnieje w kodzie, który czytasz w swoim IDE lub w przeglądarce czytającej źródło z VCS, takiego jak GitHub lub GitLab, gdzie przewijanie w pionie działa dobrze.

Siedem nieskutecznych nawyków kodowania wielu programistów

Kilka miesięcy po stworzeniu gry „Połącz nawiasy klamrowe” natknąłem się na niesamowitą prelekcję Kevlina Henneya , który przedstawia świetne argumenty przemawiające za określonym stylem umieszczania nawiasów klamrowych, a także wiele innych świetnych uwag, które porusza w rozmowie na temat stylu kodowania.

Tak więc, to, co właśnie ci powiedziałem, na wypadek gdybyś się zastanawiał, tak, istnieje sposób na określenie prawidłowego sposobu wyrównania aparatu ortodontycznego… obiektywnie.

Bez spoilerów. Gorąco polecam obejrzenie tej rozmowy. Ostrzeżenie, ta rozmowa może być konstruktywnym zakłóceniem twojego obecnego stylu kodowania.

Wezwanie do działania w stylu kodu Java

Pozostawiamy miliardy linii kodu źródłowego Javy w systemach kontroli wersji, które mają być utrzymywane przez nas samych i przyszłe pokolenia programistów. Styl kodu ma bezpośredni i subtelny wpływ na przejrzystość i czytelność. Nie każdy czyta kod z taką samą szybkością. Mogą istnieć wyzwania związane z ułatwieniami dostępu, które należy przedyskutować i rozważyć jako zespół. Każdy powinien być w stanie ostatecznie przeanalizować kod, czytając go, niezależnie od stylu kodu. Gdybyśmy mogli poświęcić mniej cykli na oddzielenie „co” od „jak” i znalezienie kodu, którego szukamy, byłoby dobrze.

Oto moje zasady budowania akceptowalnego stylu kodowania w zespole.

1. Omów ze swoim zespołem wytyczne dotyczące stylu kodu.
2. Zastosuj spójne wytyczne dotyczące stylu kodu w swoim projekcie, korzystając z reguł automatycznego formatowania zakodowanych i dostosowanych w Twoim ulubionym IDE.
3. Uruchom zautomatyzowaną ciągłą kompilację, która będzie się psuć w przypadku niespójnych zatwierdzeń stylu kodu (np. CheckStyle).
4. Opublikuj wytyczne dotyczące stylu kodu w swoim projekcie VCS.
5. Miej odwagę i poświęć czas na rozwijanie wytycznych dotyczących stylu kodu, gdy odkryjesz lub nauczysz się czegoś nowego.

Zachęcamy do korzystania z gry Połącz nawiasy klamrowe, aby ułatwić racjonalne i obiektywne dyskusje na temat stylu kodu, zwłaszcza w odniesieniu do dyskusji na temat stylu umieszczania nawiasów klamrowych w Javie. Jeśli podoba Ci się ten styl i chcesz zobaczyć ustawienia stylu kodu, których używaliśmy w IntelliJ IDEA dla Eclipse Collections przez ostatnie siedem lat, są one sprawdzane w GitHub tutaj .

Cieszyć się!

Jestem twórcą i Committerem projektu Eclipse Collections OSS, który jest zarządzany przez Fundację Eclipse . Kolekcje Eclipse są otwarte na wkłady .