Nieporozumienie z liderem projektu w sprawie standardów kodowania [zamknięte]

Pracuję nad nowym projektem wraz z moim kierownikiem projektu przez ostatni rok.

Początkowo mieliśmy własne podprojekty, które rezydowały w oddzielnych repozytoriach git, miałem niewielką interakcję z jego kodem, więc zapach kodu mi nie przeszkadzał. Jakieś 6 miesięcy później zacząłem utrzymywać i dodawać funkcje do jego kodu, ponieważ zacząłem odgrywać większą rolę w projekcie.

Teraz, gdy jestem głównym programistą obu podprojektów (zespół ma się rozwijać; wciąż jest nade mną), te rzeczy mnie niepokoją i chciałem się nimi zająć, ale odmówiono:

1. Bez nawiasów klamrowych, funkcji pisanych wielkimi literami, użycia mieszanych cytatów (logika podwójna i pojedyncza w / ukryta), nieużywanie ===, ogromne klasy z dużymi funkcjami. Podsumowując, mogłoby być lepiej.
2. Polegaj na opcji PHP, aby wyłączyć powiadomienia / ostrzeżenia. Kod jest pełen niesprawdzonych zastosowań zmiennych i kluczy tablicowych. Zmienne są definiowane wewnątrz ifs.

Argumenty dotyczące powyższych 2 problemów:

1. Nie chcę narzucać ludziom stylu kodowania.
2. Uważany za funkcję języka, która nadaje się do krótszego / bardziej wydajnego kodu.

Uważam, że trzeba przestrzegać pewnych zasad, a kod powinien być defensywny. Zaproponowałem użycie domyślnych ustawień PHPStorm do formatowania, użycie nawiasów klamrowych i przyjętej przez społeczność konwencji nazewnictwa.

Chcę dopasować oba projekty, aby korzystały z tych samych wytycznych, ponieważ są one nierozłączne.

Czy się mylę? Czy narzucam swoje osobiste preferencje?

Jeśli potrafisz uzasadnić, dlaczego twój jest lepszy (i jakie główne problemy mogą wyniknąć z jego używania), to chyba nie narzucasz osobistych preferencji, ale próbujesz przygotować projekt na sukces.

Jeśli uda mu się uzasadnić, dlaczego jest lepszy i jakie problemy zapobiegną temu, że twój nie jest w stanie, oznacza to, że masz atuty.

Przyzwoite kierownictwo powinno być w stanie dostrzec w tym wartość, ale są to kwestie, na których będą (i powinny) się przejmować: nie to, czy jest to łatwiejsze dla programistów, czy „nie chce się zmuszać wszystkich do pracy jak robot” (co jest absurdalny, ale nie używaj go jako punktu bólu dla wyższej kadry zarządzającej). Powinni (powinni) dbać o bieżącą stabilność projektu.

Na mój komentarz powyżej:

Jeśli jest liderem projektu, wydaje się to sugerować, że to w zasadzie jego wezwanie.

To była moja myśl. Jeśli chcesz zmienić standard, ale on się na nim nie opiera, albo a) wymyśl, jak się przed nim przebijać, b) idź gdzieś indziej do pracy, lub c) wypróbuj, jakie drobne rzeczy możesz zrobić, nie drażniąc go zbyt wiele.

Przebicie się nad nim będzie działać tylko wtedy, gdy uzasadnisz, dlaczego powinny istnieć lepsze standardy.

Gruntownie:

• ty nie jak jego stylu kodowania. Masz rację.
• on uzna to OK, jak to jest i znaleziska spędzać dni / tygodni / więcej tylko dostosowując styl to strata czasu . To jego racja.

Postaw się w jego butach. Jakie są korzyści z tego przedsięwzięcia, poza kosztowaniem firmy dużych pieniędzy (pensji)? Czy on zawsze jest taki podły? Czy nie widzi, że są teraz ważniejsze rzeczy do zrobienia?

Zasadniczo, to trzeba znaleźć jakiś kompromis można żyć, czy twój związek stanie się kwaśny. Wiele zależy również od tego, jak się z nim komunikujesz. Odłóż na bok swoje ego i staraj się być pomocny ... ponieważ w końcu pytasz go o rzeczy , które chciałbyś, a nie o coś, co go interesuje. Innymi słowy, prosisz go o przysługę .

Często zależy to również od tego , jak zapytasz. Przykłady:

Czego chcesz:

czyniąc kod ładniejszym

Czego nie powiedzieć:

twój kod jest do kitu tak, jak jest

Co powiedzieć:

Byłbym bardzo wdzięczny, gdybym mógł uczynić oba projekty spójnymi, tylko podstawy, a to zajmie mi tylko jeden dzień.

Czego chcesz:

nigdy więcej niesprawdzonych ostrzeżeń

Czego nie powiedzieć:

twój kod jest do kitu tak, jak jest

Co powiedzieć:

Wiem, jak szybko pozbyć się tego i tego ostrzeżenia. Następnie, włączając je ponownie, moglibyśmy szybciej wykryć, czy coś może się zepsuć w przyszłości.

I wreszcie:

Wiem, że to nie jest priorytet. Mogę więc z radością to zrobić, gdy rzeczy o wysokim priorytecie nie pojawią się jako pierwsze.

Lub, jeśli to nie zadziała lub masz z nim złe relacje, rozważ odejście. Jeśli nie możesz teraz uporządkować rzeczy, jest mało prawdopodobne, aby w przyszłości było lepiej ... i odłóż swoje ego na bok.

Dygresja

Myślę, że ludzie starsi są bardziej łagodni. Wiedzą, że i tak kod zostanie zarzucony za dekadę lub dwie (ponieważ zmiany technologii, interfejsy API również, zespoły, partnerzy biznesowi, wymagania, globalne decyzje, cokolwiek ...). Mają mniej ego i skupiają się na tym, aby działało, a nie było idealne. Chociaż sam dążę do perfekcji, nie mogę ich winić.

To prawdopodobnie będzie kontrowersyjne, ale ...

Rozmawialiśmy i zgodziliśmy się nie zgodzić i przekazać sprawy wyższemu kierownictwu

Nigdy. Zawsze. Robić. To. ZAWSZE. Za każdym razem, gdy to robisz, cofamy nas o dekadę. Tak to się rozegra:

• Starszy menedżer 1: „Poproszono nas o zajęcie się tym problemem, bla, bla, coś o standardach kodowania i marnowaniu czasu”.

• Starszy menedżer 2: „A oni proszą nas o rozwiązanie ich wojen nerdowych, ponieważ?”

• Starszy menedżer 3: „Ponieważ są to płaczliwe dzieci, które nie potrafią się komunikować i nie dbają / nie rozumieją, jaka jest wartość biznesowa? *”

• Starszy menedżer 2: „To musi być to. Kto jest gotowy na golfa?”

Potem nadchodzi czas przeglądu wyników twojego i twojego szefa:

„[kierownik wyższego szczebla do swojego szefa]: Przykro mi, ale istnieje obawa, że ​​nie jesteś w stanie zarządzać swoimi bezpośrednimi raportami i możesz nie stosować się do najlepszych praktyk (nawet jeśli nie mam pojęcia, co robisz, z wyjątkiem wpisania mumbo jumbo sprawia, że ​​oprogramowanie działa) ”

„[starszy menedżer do ciebie]: Przykro mi, ale istnieje obawa, że ​​nie odnosisz się dobrze do swoich rówieśników i masz problemy ze stosowaniem się do wskazówek bezpośredniego przełożonego”.

I dlatego jesteśmy w większości niedopłacani w porównaniu do wartości, którą tworzymy. **

Musisz albo A) przejść przez to, albo B) przejść do sklepu, w którym standardy są nieco bliższe twoim upodobaniom. FWIW, zrobiłbym B (i mam nadzieję, że przejdę do języka, który nie dopuszcza takich okrucieństw). Ale nigdy nie eskaluj sporu technicznego do pozwów, chyba że wiąże się to z czymś nielegalnym lub potencjalnie katastrofalnym (luka w zabezpieczeniach). Samo irytujące go nie wycina ***.

* Ze względu na ludzi, którzy to przeczytają i źle zrozumieją, nie mówię, że OP i jego szef są tacy (zdaję sobie sprawę, że jakość / czytelność kodu ma bezpośredni wpływ na wynik finansowy firmy), mówię że będą tak postrzegani przez nietechniczne kierownictwo.

** Dla osób, które uważają mój portret wyższej kadry kierowniczej za nieświadomy a-dziur, jest nierealny, należy zrozumieć, że menedżerowie dbają (najlepiej) o zarządzanie ludźmi w sposób, w jaki dbamy o zarządzanie kodem. Być może nie mają pojęcia o kwestiach technicznych, ale znają ludzi, i to tym bardziej dlatego, że postawienie im sporu o to, że A) prawdopodobnie nie mają kwalifikacji do rozstrzygnięcia i B) wasza dwójka prawdopodobnie powinna była być w stanie rozwiązać bez pomocy sprawia, że ​​źle wyglądasz.

*** Tak, zdaję sobie sprawę, że dług techniczny może narastać do tego stopnia, że ​​zapadnie się firmy. Po prostu nie sądzę, że nawiasy klamrowe cię uratują (co powiedziawszy, nigdy nie omijam nawiasów klamrowych i zdecydowanie wolę, żeby inni też nie).

IMHO, masz do czynienia z „działającym” programistą, a nie takim, który będzie dbał o kolejne. Jego argumenty są po prostu bezwartościowe.

Wszystko, co mówisz o jego kodzie, to po prostu lenistwo z jego strony. Posiadanie projektów zgodnych z tym samym standardem kodowania dotyczy rygorystyczności. Nie jesteś robotami; jesteście inżynierami; powinieneś być rygorystyczny.

Możesz wskazać na kilku przykładach, że masz trudności z przeczytaniem jego kodu, co jest dla ciebie ogromną stratą wydajności, ale nie mam pojęcia, jak mu to przynieść.

Ale prawdopodobnie odpowiem ci coś, co brzmi:

Działa, nie ma sensu się zmieniać

Moja rada: jeśli jest naprawdę tępy i nie chce niczego przewodzić, puść to. Poczekaj na wystąpienie błędów / błędów / ewolucji w jego projekcie. Kiedy to nastąpi, po prostu napraw i przepisz część kodu zmodyfikowaną / dodaną we właściwy sposób; nie idź do niego, żeby coś o tym powiedzieć. Nie narzuci ci swojego stylu kodowania, ponieważ i tak nie jesteś robotem ...

Podczas pracy nad projektem musisz ustalić priorytety.

Priorytetem nr 1 jest dogadywanie się ze współpracownikami. Po priorytecie nr 1 następuje ogromna luka. Potem są priorytety dla takich rzeczy, jak kod, który działa, jest testowalny, testowany, dokumentowany, konserwowany itp. Potem pojawia się kolejna ogromna luka, a potem przychodzą standardy kodowania.

A zmiana istniejącego kodu w celu dostosowania do nowych standardów kodowania jest naprawdę niska na liście priorytetów.

PS. „Mikrooptymalizacja” a „superszybkie komputery”: Całkowicie błędny argument. Argumentem przeciwko mikrooptymalizacji nie jest to, że komputery są szybkie, argumentem jest to, że czas zmarnowany na mikrooptymalizacje oznacza, że ​​nie masz czasu na realne oszczędności.

PS. Jeśli tylko jeden dzień zajmuje Ci wprowadzenie zmian, które sprawią, że kod będzie dla ciebie lepszy, ale zdenerwuje współpracownika i uczyni cię wrogiem, to zmarnujesz jeden dzień na coś, co jest po prostu nieproduktywne.

PHP nie jest najbardziej elitarną grupą w naszym zawodzie. W rzeczywistości krytykujesz jego prawdopodobnie trudny do zdobycia system oprogramowania. Twój standard zawodowy jest wyższy niż jego.

Jeśli więc nie masz swobody w ulepszaniu kodu w ramach swoich obowiązków, istnieje tylko jedno rozwiązanie: przejdź dalej .

Nie wiem o obecnym rynku PHP u ciebie, ale najpierw możesz się nieco zdywersyfikować. Naucz się również jakiegoś języka hype lub niszy, takiej jak C #.

Możesz nie mieć tak dobrej pracy, ale pójdziesz dalej, profesjonalnie. Miej więc cierpliwość i samokształć się. Bezpieczne pieniądze. Następnie poproś o swobodę w swoich projektach lub skorzystaj z oferty pracy.

Trudno mi uwierzyć, że # 1 jest jego prawdziwym powodem, dla którego nie chce zmieniać standardów kodowania. Jeśli posiadasz bazę kodową, powinieneś być w stanie egzekwować wszelkie standardy kodowania, na które zgadzasz się (i inni programiści). Jeśli osiągniesz konsensus z innymi programistami (zakładając, że lider nie wykonuje już żadnych prac programistycznych), nie ma powodu, aby naprawdę go to obchodziło, z wyjątkiem tego:

Czy poprawianie stylu bazy kodu jest teraz najlepszym wykorzystaniem twojego czasu?

Jestem pewien, że masz wyniki. Ile czasu zajmie przejście i poprawienie stylu wszędzie w innej bazie kodu? Co się stanie, jeśli wprowadzisz błędy poprzez nieprawidłowe ustawienie stylu? Od wuja Boba:

Oczywiście zły kod można usunąć. Ale to jest bardzo drogie. Gdy kod się psuje, moduły wtapiają się w siebie, tworząc wiele ukrytych i splątanych zależności. Znalezienie i zerwanie starych zależności jest długim i żmudnym zadaniem.

Poprawa stylu kodu prawie nigdy nie jest dobrym wykorzystaniem czasu jako samodzielnego elementu sprintu . Sposób, w jaki lubię wprowadzać takie ulepszenia, nazywam „polityką dobrego sąsiedztwa”: nie przestawaj naprawiać całego stylu i struktury logicznej, jaką możesz znaleźć, ponieważ prawdopodobnie inwestujesz tyle czasu, ile chcesz i nadal będziesz nie skończone Zamiast tego: za każdym razem, gdy wprowadzasz zmiany w jednej części kodu, napraw styl, gdy tam jesteś, i pozostaw go lepiej, niż go znalazłeś. Jeśli próbujesz zaimplementować funkcję, ponieważ kod jest źle zaprojektowany, napraw styl, aby się odblokować, zamiast uderzać w niego głową.

W ten sposób każda zmiana:

1. Oprócz motywacji perfekcjonizmu technicznego ma motywację biznesową
2. Nie będzie postrzegana jako inwestycja czasowa (ponieważ tak nie jest!)
3. Ustanowi dobre nawyki stylistyczne właśnie dlatego, że Ty i Twój zespół robicie to z czasem
4. Nie będzie stanowić dużego ryzyka dla bazy kodu, ponieważ nie zmieniasz zbyt wiele na raz

Za kilka miesięcy spojrzysz w górę i zauważysz, że „straszna paczka” nie jest już taka zła, a twój szef zobaczy, że jego zespół jest szczęśliwszy. Ale ponieważ nie była to bezpośrednia konfrontacja, już się to zakończy, a on nie będzie miał na co narzekać, ponieważ nie zmarnowałeś czasu (w jego umyśle), dodając duży projekt refaktoryzacji do listy rzeczy do zrobienia. Prawdopodobnie nigdy nie powie ci, że miałeś rację, ale to i tak nie jest celem (prawda?).

Zadaj te pytania dotyczące swojej szansy.

• Czy są przyzwyczajeni do pracy w pojedynkę czy z bardzo małym zespołem?
• Czy najczęściej kodowali w tym jednym sklepie?
• Czy są przyzwyczajeni do podejmowania decyzji?
• Czy są przyzwyczajeni do „po prostu robienia tego”?
• Czy napisali większość kodu?

Jeśli odpowiedzi brzmią „tak”, to pomaluję obraz konkretnego typu głównego programisty. Jeśli zgadza się z tym, czego doświadczyłeś, być może pomoże ci to zrozumieć. Jeśli nie, zignoruj ​​tę odpowiedź .

Jest to ktoś, kto był tam od pierwszego dnia, spędził lata na tej samej pracy, pracując na tej samej podstawie kodu, jest przyzwyczajony do swojej drogi i nie ma dużego doświadczenia z innymi sposobami.

Podczas pisania kodu nie biorą pod uwagę innych ludzi, ponieważ ma to dla nich sens. Oczywiście, że tak, napisali to lub spędzili lata na zrozumieniu.

Uważają, że styl kodowania jest osobistą preferencją, a nie narzędziem ograniczania konserwacji i błędów. Kłócąc się o styl kodowania, z trudem wysłuchają twoich argumentów, ponieważ prawdopodobnie nigdy nie zastanawiali się zbyt wiele, dlaczego robią to po swojemu. Usłyszą: „Chcę to zrobić po swojemu” lub „Chcę to zrobić w nowy, fantazyjny, modny sposób”.

Są na swój sposób. Ponieważ tak długo robią to w ten sam sposób, wszystkie swoje narzędzia i edytory oraz mikrokonfiguracja mózgu odpowiadają dokładnie ich stylowi. Wszelkie odchylenia od tego stylu będą kolidować z tym starannie ułożonym, ale bardzo kruchym sposobem pracy. Próby zmiany będą powodować skargi na ich redaktora, narzędzia, sposób, w jaki lubią pracować, lub „trudność z czytaniem”. Odrzucają zmiany, ponieważ tak mocno otoczyli się obecnym stanem rzeczy, że nie mogą się zmienić.

To ktoś, kto nigdy nie nauczył się właściwie inżynierii oprogramowania i architektury oprogramowania. Po prostu uderzają razem w coś, co działa.

Masz problem z ludźmi, a nie technologiczny.

Będziesz musiał przekwalifikować się na prowadzeniu lub zrezygnować.

Zarządzanie jest ostatecznością . Zarówno z powodów, które @JaredSmith wskazał, jak i dlatego, że przegrasz. Ten facet spędził lata na nich zarabiając. Napisał ich towarzystwo. Ulegał licznym pożarom. Dla ciebie jest kowbojskim szefem kuchni, który robi spaghetti. Dla nich jest bohaterem, który zbudował i uratował firmę.

Aby przekwalifikować się, musisz ...

• Zdobądź jego zaufanie.
• Dowiedz się, jak on myśli.
• Odnieś się do jego obaw przed zmianą.
• Ułatwiaj zmianę.
• Pokaż, jak mu to lepiej .

Potraktuj jego styl poważnie i wejdź mu do głowy. Zapytaj go o to. Dlaczego robi rzeczy tak jak on? Co widzi, kiedy to czyta? Jak współdziała z jego narzędziami? Jak porusza się po kodzie? Znajomość wszystkich tych rzeczy pozwoli ci zrozumieć i odpowiedzieć na jego zastrzeżenia.

Znajdź obiektywny rdzeń jego subiektywnych obiekcji i spraw, by były one wykonalne. „Trudno przeczytać” jest subiektywne i nie daje żadnych informacji. Nic na to nie poradzisz. „Jestem ślepy na kolory, a podświetlanie składni nie działa” jest obiektywne, daje informacje i możesz coś z tym zrobić. Poleciłbym książkę zatytułowaną Getting To Yes, aby uzyskać więcej informacji na ten temat.

Gdy dojdziesz do głównego problemu, którego on naprawdę doświadcza, sprawdź, czy możesz go naprawić lub złagodzić. To nie jest problem. Prawdopodobnie nadal będą mieć problemy emocjonalne ze zmianą, ale przynajmniej nie mogą dłużej argumentować, że to prawdziwy problem.

Zrób to po trochu. To ktoś, kto robi to w ten sam sposób od lat. Jest przyzwyczajony do dostrzegania pewnych wzorców w kodzie i używania ich do zrozumienia. Nagła zmiana wszystkich tych wzorów będzie myląca. Jakkolwiek frustrujące będzie powolne przyspieszanie ich za pomocą znanych dobrych praktyk, musisz go przez to przejść.

Zwolennik standardowego stylu społeczności. Eliminuje to argument, że chodzi o osobiste preferencje i wywiera na nich presję, aby uzasadnić, dlaczego ich odmienny styl jest o wiele lepszy. Jeśli planujesz zatrudnić, ułatwia to integrację nowych pracowników.

Zwolennik zautomatyzowanego stylu kodu. Naciskaj przycisk, postępując zgodnie z właściwym stylem. Użyj narzędzia, które zaczyna się od standardowego stylu, pozwala skonfigurować go według własnych upodobań i może zmienić styl kodu za naciśnięciem jednego przycisku. Ułatwienie podążania za tym stylem usuwa wiele argumentów na temat tego, jak trudno będzie podążać za tym stylem. Potrafią kodować w dowolny sposób, a kiedy skończą, naciskają przycisk i postępują zgodnie ze stylem, który inni mogą przeczytać.

Ponieważ ta osoba nie jest nastawiona na myślenie o innych, będziesz musiał pokazać, w jaki sposób te zmiany przynoszą im korzyści. Może to być tak proste, jak „ponieważ jest to teraz standard, nie będziesz musiał ponownie przechodzić tej walki z następną zatrudnioną osobą”. Lub może to być „jeśli mamy testy, możesz być bardziej agresywny w kwestii zmiany kodu i mniej martwić się zmianami”. Lub „jeśli są dobre dokumenty, ludzie nie będą musieli niepokoić cię pytaniami na temat działania kodu”. Aby to było skuteczne, musisz wiedzieć, czego chcą - niektórzy ludzie lubią się martwić, to sprawia, że ​​czują się ważni.

To długa, długa droga. Będziesz musiał zdecydować, czy masz cierpliwość, aby zarządzać i przekwalifikować swojego szefa. Pomyśl o sobie bardziej jako o nauczycielu niż o ich sfrustrowanym podwładnym i możesz poczuć się lepiej.

Czy się mylę?

Nie znam PHP, więc nie mogę dokonać bezpośredniego osądu, ale dla uproszczenia założę, że preferowany przez ciebie styl kodowania jest „lepszy” niż napotkany kod, ponieważ twój jest bardziej zgodny z istniejącymi automatycznymi narzędziami.

Zatem nie mylisz się, sugerując ulepszenia stylu kodowania.

Podsumowując, nie kod, z którym chcę pracować

Możesz się mylić, odmawiając pracy z kodem, który nie spełnia twoich preferowanych standardów, ale tylko w takim zakresie, w jakim pracując dla firmy, zgodziłeś się na pracę z jego kodem w pierwszej kolejności. Ostatecznie nie jest „złe” odejście z pracy, jeśli stawia przed tobą wymagania, które ci się nie podobają, ponieważ masz rację i w rezultacie możesz znaleźć lepszą pracę.

Czy narzucam swoje osobiste preferencje?

Nie. On jest szefem projektu, a ty nie. To jego wezwanie, chociaż w tym przypadku jest „delegowany w górę”.

Równie dobrze mógł zdecydować o oddelegowaniu do ciebie, jako głównego programisty podprojektów, i dać ci swobodę w ustalaniu standardów kodowania dla tych podprojektów i współpracowników, którzy nad nimi pracują w przyszłości. Ale z jakichkolwiek powodów uważa, że ​​nie należy standaryzować. Nawet jeśli myli się co do stylu kodowania, nie możesz spodziewać się autorytetu, na który ci nie pozwolił.

Ponieważ jednak mówi „Nie lubię wymuszać stylów kodowania”, możesz przynajmniej napisać nowy kod w swoim preferowanym stylu (i już to zrobiłeś). Ostatecznie może to dać okazję do wykazania obiektywnych korzyści twojego stylu. To byłby dobry moment, aby zastanowić się.

Można również (myślę) rozsądnie poprosić osoby, które edytują pliki, aby zrobiły to w stylu, w którym plik jest już zapisany. To pozwala zachować standardy w zapisywanych plikach. Niestety drugą stroną tego jest to, że będziesz musiał edytować pliki, które napisał w podobny sposób do swojego stylu.

Nawet zakładając, że masz naprawdę dobry zestaw testów, a zatem możesz refaktoryzować względnie bezpiecznie, wciąż istnieją (co prawda dość marginalne) powody, aby nie przeszukiwać i nie zmieniać stylu całych plików. Najważniejsze jest to, że to koszmar próbujący scalić, zmienić kolejność lub cofnąć zmiany dokonane przed i po dużej zmianie strukturalnej. Ale może się zdarzyć, że w tym konkretnym projekcie rzadko się zdarza.

[Mój kierownik mówi, że nie lubi] wymuszać stylów kodowania wobec ludzi [ponieważ] nie jesteśmy robotami.

Czy zastanawiałeś się kiedyś, dlaczego po prostu nie wyrzucamy kodu źródłowego po jego skompilowaniu i przejściu wszystkich testów? Kod źródłowy jest przeznaczony dla ludzi i nie tylko ludzie mogą pisać, ale także czytać .

Wcześniej czy później ktoś będzie miał powód, aby wrócić i przeczytać kod. Może będą musieli to zmienić, może udokumentować, a może użyć ponownie. Cokolwiek. Stanie się tak, a kod będzie o wiele łatwiejszy do odczytania i obsługi, jeśli wszystko będzie w spójnym stylu.

Nawet zły styl jest lepszy niż żaden styl.