Czy styl kodowania w organizacjach jest czymś opcjonalnym?

Ten dokument w stylu programowania ma ogólną zasadę, która mówi:

Reguły mogą zostać naruszone, jeśli istnieją wobec nich poważne osobiste zastrzeżenia.

To koliduje ze sposobem, w jaki myślę, i wiele artykułów mówi, że styl kodowania jest naprawdę ważny. Na przykład mówi to :

Dokument standardów kodowania mówi programistom, jak muszą napisać kod. Zamiast każdego programisty kodującego w swoim preferowanym stylu, zapisują cały kod zgodnie ze standardami opisanymi w dokumencie. Dzięki temu duży projekt jest kodowany w spójnym stylu - części nie są pisane inaczej przez różnych programistów. To rozwiązanie nie tylko ułatwia zrozumienie kodu, ale także zapewnia, że ​​każdy programista, który patrzy na kod, będzie wiedział, czego się spodziewać w całej aplikacji.

Czy zatem źle rozumiem coś z tego dokumentu i cytatu na początku tego pytania? Czy ludzie naprawdę mogą po prostu zignorować styl kodowania?

Może nie byłem wystarczająco jasny, więc z tą edycją zamierzam trochę wyjaśnić.

Piszę dokument dotyczący stylu kodowania dla naszego zespołu i chcę sprawdzić styl za pomocą niektórych analizatorów statycznych. Jeśli to się nie powiedzie, Jenkins wyśle ​​e-maile. I chcę zakończyć przegląd kodu, jeśli styl nie pasuje. To wyraźnie koliduje z pierwszym cytatem.

Ale jeśli cytat ma rację, jaki jest pożytek z dokumentu w stylu kodowania, jeśli ktoś może zrobić, co chce?

O ile mogę stwierdzić, stwierdzenie, które was myliło, jest pragmatycznym kompromisem zawartym po to, aby wytyczne mogły służyć jak najszerszej publiczności. W zależności od konkretnego kontekstu (więcej na ten temat poniżej) możesz mieć możliwość dostosowania go i efektywniejszego korzystania z wytycznych.

Widzisz, wytyczne odnoszą się do „silnych sprzeciwów osobistych” jako sposobu uzasadnienia naruszenia. Takie zastrzeżenia nie należy lekceważyć, zwłaszcza jeśli pochodzą od doświadczonych programistów.

Te zastrzeżenia mogą być błędne, pamiętajcie o tym, ale (i to jest bardzo WIELKIE ALE) mogą również wskazywać, że dana reguła jest błędna - ogólnie lub w kontekście konkretnego projektu (jednym z przykładów niewłaściwej reguły jest wymóg podania szczegółowe logowanie do kodu krytycznego dla wydajności).

Myślę, że każdy rozsądny przewodnik po stylu powinien uwzględniać powyższe i starać się zaspokoić ewentualną potrzebę dostosowania się. Teraz, jeśli przewodnik, który Cię pomylił, był skierowany tylko do dojrzałych zespołów z wydajnymi i płynnymi procesami i środowiskiem, można by powiedzieć o wiele mniej dwuznacznie, na przykład tak:

Zasady powinny być ściśle przestrzegane, chyba że zostanie postawione przeciwko niemu wyzwanie - w takim przypadku zakwestionowana reguła powinna pozostać ignorowana, dopóki nie zostanie rozwiązana - albo przez odrzucenie wyzwania, albo zaakceptowanie go i dostosowanie zasad, aby pasowały.

Może ci się to podobać lepiej i możesz chcieć, aby tak było wszędzie, dla wszystkich, ale przyjrzyj się bliżej części „Wyzwanie zostało podniesione / pozostań ignorowane / dostosuj” i zadaj sobie pytanie, jak można je zrealizować. Zadaj sobie pytanie, jak długo może to potrwać w zależności od projektu i zespołu. Jeśli to zajmuje godzinę, czy jest to do przyjęcia? Co jeśli zajmie to dzień, tydzień lub ... miesiąc?

Widzisz, takie podejście typu wyzwanie i zignoruj ​​aż do rozwiązania może otworzyć szerokie drzwi do nadużyć, jeśli zostanie przedstawione jako przewodnik dla każdego projektu. „Tak, tak, słyszymy cię, zróbmy to, jak mówi przewodnik. Najpierw wypełnij ten formularz wyzwania i uzyskaj zgodę CEO / CFO / CTO; spodziewaj się, że zajmie to tydzień lub dwa. Następnie poczekaj, aż zaktualizujemy nasze kontrole kodu ; może to potrwać jeszcze tydzień lub dwa. Tymczasem upewnij się, że Twój krytyczny pod względem wydajności kod wymiotuje poprawnie sformatowane instrukcje rejestrowania przy każdym ruchu rejestru. ”

Nie mogę czytać w myślach autorów przewodnika, ale rozsądnie jest założyć, że chcieli uniknąć używania go do uzasadnienia bałaganu, jak opisano powyżej. Z tej perspektywy po prostu bezpieczniej jest jednoznacznie stwierdzić, że przewodnik nie zakłada żadnego egzekwowania - w ten sposób, choć niezgrabny, nadal pozwala na użycie go w dowolnie szerokim zakresie zespołów i projektów. Prawdopodobnie oczekuje się, że tak szeroki limit pozostawia bardziej dojrzałym i wydajnym zespołom możliwość rozsądnego zawężenia go bez szkody dla wydajności programistów.

Stosując się do konkretnego przypadku, pisząc dokument stylu kodowania dla zespołu i nie sprawdzając kodu, jeśli styl nie pasuje - myślę, że musisz dowiedzieć się, ile czasu może zająć programistom zakwestionowanie określonej reguły, zignorowanie jej, rozwiązane, i należy je zmienić lub odzyskać w zależności od rozdzielczości.

Jeśli wymyślisz sposób, aby ten proces działał bez wprowadzania wielu przeszkód do przepływu pracy programistycznej, to warto rozważyć sformalizowane i łatwe do śledzenia podejście wyzwanie / rozwiązanie zamiast chaotycznego „naruszaj, jeśli płaczesz wystarczająco głośno”.

Na marginesie chciałbym odnieść się do tego, co napisałeś w innym komentarzu : „Załóżmy, że styl kodowania jest idealny, a jeśli tak nie jest itd.”

To naprawdę niebezpieczne założenie. Złamałem mu nos (dwa razy! W jednym projekcie! Miałem ogromne doświadczenie i wyobrażałem sobie, że wiem o tym wszystko, idź na rysunek) i gorąco polecam, żebyś to rzucił. Bezpieczniej jest założyć, że przewodnik po stylu może zawierać błędy i podjąć wysiłek, aby zastanowić się, co zrobić w przypadku wykrycia takich błędów.

Umożliwienie ludziom ignorowania stylów kodowania z powodu osobistych preferencji jest złym pomysłem.

Cytat w twoim pytaniu wydaje się pozwalać programistom po prostu powiedzieć: „Nie zamierzam używać tego stylu, ponieważ go nie lubię”.

Jest to sprzeczne z całym celem, który polega na tym, że wszyscy członkowie zespołu robią to samo, aby zachować spójność i czytelność.

Zgadzam się, że stylowy dokument z takim stwierdzeniem jest prawdopodobnie bezcelowy.

Niemniej jednak wskazana jest pewna elastyczność w przestrzeganiu wytycznych dotyczących stylu:

• Niewolnicze przestrzeganie wytycznych może uniemożliwić najlepszy sposób napisania określonego fragmentu kodu . Programiści powinni być w stanie zignorować wytyczne i udowodnić, że to, co zrobili, jest najlepszym, najbardziej czytelnym sposobem na osiągnięcie czegoś w tym przypadku.
• Praca ze starszym kodem może wymagać elastyczności. Prawdopodobnie nie jest dobrym wykorzystaniem twojego czasu na zmianę stylu dużej istniejącej bazy kodu. Jeśli znacznie przepiszesz konkretną sekcję, możesz sformatować ją w preferowanym stylu. Jeśli jednak dokonasz niewielkiej zmiany, może być lepiej użyć istniejącego stylu kodu.
• Oszukiwanie drobnych naruszeń przewodnika po stylu nie jest dobrym wykorzystaniem czasu. Przegląd kodu to dobry moment na podkreślenie każdego kodu, który jest znacznie niezgodny ze stylem zespołu. Jednak łapanie i naprawianie „błędów” w małym stylu może stać się zajęty pracą, która koncentruje się na złych rzeczach. Oczywiście, przegląd kodu nie powiedzie się, jeśli styl został rażąco zignorowany. Ale nie podoba mi się pomysł prowadzenia analizatora i wskazywania każdego źle umieszczonego nawiasu lub wcięcia, nie wspominając o tym, że ktoś zawiedzie kogoś na tej podstawie.

Podsumowując: zapewnij elastyczność w przestrzeganiu wytycznych dotyczących stylu, aby jak najlepiej spełnić potrzeby Twojego zespołu - ale nie z arbitralnych powodów, takich jak osobiste preferencje.

Istnieją style stylu i przewodniki po stylach, które pomagają zwiększyć czytelność kodu. I istnieje czytelność, aby pomóc w złożoności.

Dlatego ostatecznie to, czy naruszyć (nazwałbym to adaptacją) styl kodowania dopasowany do twoich potrzeb organizacyjnych, sprowadza się do tego, jak bardzo pomaga to w zrozumieniu.

Pamiętajcie, wszystko i podkreślam, WSZYSTKO, od programowania OO, poprzez paradygmaty funkcjonalne, po różne modele współbieżności, istnieje wyłącznie po to, by pomagać ludziom radzić sobie ze złożonością.

Każdy głupiec może napisać kod zrozumiały dla komputera. Dobrzy programiści piszą kod, który ludzie mogą zrozumieć. - Martin Fowler, 2008

Czy styl kodowania w organizacjach jest czymś opcjonalnym?

Organizacje decydują się na style kodowania - nie ma wymogu posiadania tego na pierwszym miejscu.

Więc cytat, który czytasz, odnosi się do największego problemu, jaki widzę, dotyczącego kodowania „stylu” i prawdziwych „hakerów” supergwiazd - dołączasz nowego faceta, a on pisze kod, który zrzuci zombie i sprawi, że twoje stare serwery będą krzyczeć szybko. .. ale jego styl kodowania różni się od „akceptowanego stylu organizacyjnego”. Odmawia zmiany, a proces dostosowania się do jego konkretnego stylu będzie czasochłonny i kosztowny. Co teraz?

Większość super hakerów, których znam, ma ego tak duże, jak ich umiejętności, i chcą, aby organizacja się do nich dostosowała , a nie na odwrót. Może więc twój standard stylu kodowania powinien przypominać wytyczne dotyczące stylu kodowania , abyś mógł pozwolić temu zabójczemu hakerowi pisać płonący, szybki i niesamowity kod z pewną dewiacją stylu, ale upewnij się, że wszyscy inni to rozumieją, dopóki nie osiągną jego epickiego hakera status, muszą przestrzegać zasad (a nawet pomóc posprzątać po nim).

Oczywiście jest to koszmar zarządzania, ale zarządzanie ludźmi z branży technologicznej w ogóle przypomina trochę hodowanie kotów. Dlatego większość firm ma „wytyczne dotyczące stylu”, a nie „standardy stylu”. Kompilacje nie kończą się niepowodzeniem, a przeglądy kodu nie kończą się automatycznie z powodu naruszenia stylu we wszystkich firmach. Możesz zdecydować, jaki problem z zarządzaniem chcesz mieć - zezwalaj hakerom na supergwiazdę i miej „wytyczne” lub stracisz supergwiazdy i bardziej spójny styl kodu.

Czy zatem źle rozumiem coś z tego dokumentu i cytatu na początku tego pytania? Czy ludzie naprawdę mogą po prostu zignorować styl kodowania?

To zależy.

Miejsce, w którym aktualnie jestem, nie ma przewodnika po stylu i nie jest to wielka sprawa. Istnieją pewne niewielkie różnice między programistami, ale nie na tyle, aby wpłynąć na czytelność, wykrywalność lub spójność w jakikolwiek znaczący sposób. I mamy wystarczająco dużą grupę i wystarczająco silną kulturę, aby wymusić, że każdy nowy członek zespołu będzie zgodny (lub inaczej).

W poprzednich firmach szybko się rozwijaliśmy i mieliśmy ludzi, którzy nie znali języka i jego idiomów. W tej firmie napływ ludzi oznaczał, że nie było kultury, która wymuszałaby dobre pisanie. A ludzie, którzy nie znają języka, musieli dostosować wiele rzeczy. Tam zautomatyzowane warcaby stylu były najbardziej efektywny sposób dokonywania korekt i rzeczywiste napisany przewodnik był najlepszy sposób na przeszkolenie nowych ludzi w naszych oczekiwań.

Osobiście nie dbam o przewodniki po stylach, a tym bardziej o zautomatyzowane wymuszanie stylu. Jeśli dana osoba nie jest w stanie nawet przyswoić podstawowych idiomów, dlaczego zatrudniasz je jako programista? A jeśli są tak kiepskim graczem zespołowym, że ciągle będą pisać kod, z którym inni mają trudności w pracy, dlaczego w ogóle je zatrudniasz?

To bardziej psychologiczna sztuczka zamiast dosłownej interpretacji tego, jak najlepiej zarządzać stylami kodowania. To sprawia, że ​​zespół / firma / menedżer / lider jest mniej autorytarny. Skoncentrowałbym się bardziej na wyjątkach sytuacyjnych niż osobistych. Niezależnie od dokumentu kodowego celem jest ułatwienie czytania. Mylący kod powinien zostać rozwiązany i zmieniony, jeśli zostanie to uznane za konieczne. Jest mnóstwo narzędzi do załatwiania drobnych, żmudnych rzeczy, więc używaj ich.

Istnieją wyjątki od każdej reguły. Daj ludziom „trochę” miejsca do poruszania się. Im mniej wszyscy są zaangażowani w akceptowanie zasad stylu kodowania (Witamy nowego faceta.), Tym bardziej są skłonni do walki. Wiele rzeczy jest czarno-białych, ale niektóre są otwarte na interpretację.

Celem powinno być zaangażowanie wszystkich w ducha wytycznych kodowania zamiast walki o każdy najmniejszy szczegół i interpretację.

Tak, nadejdzie czas, kiedy dokument w stylu kodowania nie ma sensu, a profesjonalni i dorośli programiści powinni znać różnicę.

Na podstawie wprowadzonych przez Ciebie zmian dążysz do właściwego celu.

Korzystanie z przewodnika po stylach ma wiele zalet, ale dwie najważniejsze, moim zdaniem, to czytelność kodu między członkami zespołu oraz brak „głupich” zatwierdzeń (jak tylko biała spacja lub dodatkowe linie i tym podobne).

Aby osiągnąć cel, wybrany (lub stworzony) przewodnik po stylu powinien być prosty i łatwy do przestrzegania. Spróbuj naprawdę skoncentrować się na tym, czego potrzebujesz. Nikt nie lubi wracać i przepisywać dużej próbki kodu, aby uszczęśliwić linijkę. Ale wciąż może być jakaś korzyść.

Upewnij się, że członkowie zespołu zatwierdzą przewodnik po stylu. Trzymając ich przy tym, upewnijcie się, że się zgodzą, bo inaczej będzie to wieczna walka.

Upewnij się, że naruszenia stylu są „ostrzeżeniem”, a nie „niepowodzeniem”, pozwól człowiekowi zdecydować, czy naruszenie spełnia się z niepowodzeniem. Powód tego jest prosty. Wierzę w prosty przepływ pracy. Jeśli gdzieś w fazie „testowania” dojdzie do „niepowodzenia”, nie można przejść do produkcji. Używam jest dla bezpieczeństwa. Nawet poprawki muszą przejść przez fazę testowania (choć krótszą). Czy naprawdę możesz powiedzieć, że nie popchniesz tej krytycznej poprawki do produkcji, ponieważ ktoś użył „zamiast”? Co powiesz na użycie pętli for zamiast każdej? Co, jeśli pętla for ma jakieś ulepszenia w stosunku do każdego? są decyzje, których maszyna (linter) nie może podjąć, więc upewnij się, że masz człowieka, oceniaj ostrzeżenie, a nie maszyna rzuci awarię.

Jeśli chodzi o ignorowanie przewodnika po stylach, będziesz musiał to oceniać indywidualnie dla każdego przypadku. Upewnij się, że „odchylenie” ma prawdziwy powód. Oni przyjdą. Zadaniem recenzentów jest upewnienie się, że istnieje dobry powód odchylenia, a nie trywialny.

Myślę, że nastrojowa muzyka polega na tym, że jeśli przyjęta jest mądrość, że standardy kodowania są nieprawidłowe lub niekompletne, to mniejszym złem jest naciskanie, jeśli deweloperzy są zgodni, a nie przejść przez żmudny proces uzyskania dokument zmieniony i ponownie sprawdzony.

Należy również zauważyć, że standardowe zasady egzekwowania kodu z przeszłości nie są zwykle takie, jak się teraz robi.

W dawnych czasach po prostu trzymałeś książkę na końcu biurka programisty i cytowałeś rozdział i werset, dlaczego jego kod narusza sekcję 34.5.5767.

Mamy teraz narzędzia do analizy kodu statycznego i auto dokumentacji, które zabierają wiele kłopotów ze standardami kodu.

Jeśli to wszystko nie powiedzie się, nadal możesz przekazać go z powrotem programistom, podnieść w recenzji kodu lub po prostu zmienić samodzielnie, jeśli masz na to ochotę.

Twoje pytanie dotyczy pogodzenia dwóch cytatów. Myślę, że to, co napisał treecoder, ogólnie odpowiada na twoje pytanie. Jest to twoja naczelna zasada przy pisaniu wytycznych dotyczących stylu.

Mówiąc dokładniej, ponieważ jesteś odpowiedzialny za ustalenie wytycznych dotyczących stylu kodowania (to moje założenie, ponieważ jesteś pisarzem dokumentów), możesz zdecydować, co jest opcjonalne, czy nie, i do jakiego stopnia pozwolisz na elastyczność w swoim osobistym stylu zespół. W razie potrzeby otrzymasz informację zwrotną. Ale kiedy wytyczne zostaną wprowadzone, trzymaj się ich.

Możesz więc pogodzić dwie pozorne sprzeczności w ten sposób:

Pomyśl o pierwszym cytacie skierowanym do ciebie jako decydenta stylu, zanim dokument z wytycznymi będzie kompletny. Jeśli określony standard stylu nie działa w Twoim zespole, liczy się to jako „silny osobisty sprzeciw”, a twoje wytyczne to odzwierciedlą.

Pomyśl o drugim cytacie zaadresowanym do twojego zespołu po zakończeniu dokumentu. Po ustaleniu wytycznych dla zespołu i napisaniu dokumentu ważne jest, aby wszyscy programiści w zespole przestrzegali wytycznych dotyczących stylu.

Ludzie nie mają większego znaczenia, o ile mają styl kodowania. Jeśli firma nalega na styl kodowania, mocno naciska na palce około 49% swoich programistów.

Problem polega na tym, że wielu programistów nie ma nic przeciwko dostosowywaniu swojego stylu kodowania do jakiegoś powszechnego standardu w firmie, ale bardzo im przeszkadzają ci, którzy są lepsi (lub po prostu bardziej dbają o) politykę firmy.

Oznacza to, że stworzenie standardu stylu kodowania może być ogromną stratą czasu, źródłem niekończących się kłótni, przyczyną nieskończonej niechęci i ogólnie ogromnym marnotrawstwem czasu i energii.

Od lat zmagam się ze wskazówkami dotyczącymi stylu kodu, podobnie jak wielu innych na tym forum. Obejmuje to zarówno przewodniki stylu walki, które uważam za wstrętne, jak i próby zachęcania innych do korzystania z przewodników stylu, aby ograniczyć ich styl, aby był bardziej czytelny jako całość.

Korporacja korzysta ze wspólnego standardu kodowania. Przy opracowywaniu oprogramowania dla firmy należy wziąć pod uwagę wiele ważnych rzeczy, takich jak szkolenie nowych programistów w zakresie pobierania kodu poprzedniej generacji. Pisząc kod, nie zawsze o tym myślisz. W rzeczywistości wielu programistów decyduje się nawet nie brać pod uwagę, w jaki sposób inni mogą chcieć podejść do kodu 5 lub 10 lat po ich odejściu. Przewodnik po stylu kodowania jest sposobem, w jaki korporacja może skoncentrować się na tych 5 i 10-letnich celach, ułatwiając programistom pracę w większym zakresie.

Z drugiej strony przewodniki stylu kodowania są notorycznie niedoskonałe, ponieważ nie jest możliwe opracowanie idealnego stylu kodowania i zapisanie go. Właściwie zaczynasz spotykać się z zabawnymi narożnymi przypadkami, w których matematyczne dowody zaczynają zawodzić, jeśli próbujesz je doskonalić. Wiemy więc, że przewodniki po stylu kodowania są niedoskonałe. Mogą nie koncentrować się idealnie na tym, czego potrzebujemy od 5 do 10 lat.

Gdybyśmy „wymusili” styl kodowania, poświęcilibyśmy wartość teraz dla wartości później. Można by to nazwać „inwestycją”, gdybyśmy byli pewni, że uzyskamy zwrot z naszych wysiłków, ale każdy programista, który pracował ze źle napisanym przewodnikiem po stylu kodowania, może zaświadczyć, że te zyski z „czytelności” są drogo opłacane przez rozpraszających programistów z dala od ich kodu. Z mojego doświadczenia wynika, że ​​istnieje bardzo niewielka liczba przypadków, w których wymuszone style kodowania mają wartość, zwykle w oprogramowaniu dla wyjątkowych lodowców, gdzie oprogramowanie może być używane przez 30 lub 40 lat!

Zamiast tego uważam, że najskuteczniejsze jest potraktowanie przewodnika po stylu kodowania jako manifestu: „Uważamy, że jest to najlepszy styl kodowania dla naszej grupy”. To kilka płynnych myśli udokumentowanych słowami. Słowo „uwierz” jest ważne: jeśli zmieniają się przekonania, przewodniki stylu kodowania powinny się z nim zmieniać.

Właśnie tutaj pojawia się cytat z „silnego osobistego sprzeciwu”. W świecie, który nazwałbym „doskonałym”, piszesz kod, który uważasz za najlepszy, i żyjesz z konsekwencjami. Często lubimy przeoczyć „miękkie” konsekwencje podczas programowania, ale w tym przypadku są one ważne. Nie mam problemu z tym, że piszesz we własnym stylu, jeśli nie masz nic przeciwko, żebym nigdy nie dawał ci niczego ważnego i długotrwałego w rozwoju.

Pomyśl o całym systemie jak o polu golfowym. Styl kodowania toruje łatwą ścieżkę na torze wodnym. Jeśli utrzymasz standard kodowania, upewnimy się, że życie jest tak łatwe, jak to tylko możliwe. Im bardziej popadniesz w zera, stosując własne standardy kodowania, tym bardziej będziesz musiał udowodnić swoją wartość zespołowi.

Jeśli przyjdę w poniedziałek rano i stwierdzę, że spędziłeś cały weekend na rozwiązywaniu problemu, nad którym martwimy się od roku, i zrobiłeś to we własnym „specjalnym” standardzie kodowania, nie powiem ci napraw to. Powiem ci, żebyś wziął prysznic. Jeśli Twój „specjalny” standard kodowania jest wyjątkowo „specjalny”, mógłbym nawet zasugerować programistom poziomu podstawowego „przejrzenie” kodu w celu rozpowszechnienia wiedzy o tym, jak działa Twój kod i od razu wspomnieć, że jeśli coś wydaje się trudne do odczytania, powinien on / ona Posprzątaj to. Dostarczyłeś firmie wystarczającą wartość w ten weekend, że nie warto nawet wspominać o rażących naruszeniach standardów kodowania, które popełniłeś.

Oczywiście ta metafora golfa nie ma sobie równych. Jeśli poproszę cię o wykonanie zadania rangi i pliku, być może dodając nowe pola do jakiejś formy, a ty zdecydujesz się skorzystać z okazji, aby zmienić cały kod wypełniający formularz, aby pasował do twojego określonego stylu, używając kilku podejrzanych znaków, takich jak makra definiujące i jakąś okropną technikę meta-programowania szablonów, której właśnie nauczyłeś się podczas wymiany stosów, zostaniesz poproszony o powrót i naprawienie tego. Zdecydowałeś się działać, to są konsekwencje.

( Oświadczenie: całkowicie napisałem tę implementację is_base_ofrozwiązania trudnego zadania i zarabiałem na każde piekło, które dostałem za to od starszych programistów. Mówię, że było warto. Nadal dostaję radosny bąbel śmiechu za każdym razem spojrzenie na sposób, że kliny wzorzec jak 7 niepowiązanych części C ++ specyfikacji razem zrobić coś niezwykłego. Weź, ty starszych programistów! to jest to, co masz do zabrania boostna tego konkretnego projektu! )

Najlepiej wydaje się korzystać ze zautomatyzowanego formatera kodu, który jest wbudowaną funkcją prawie każdego środowiska IDE pochodzenia i powinien istnieć dla prawie każdego mniej lub bardziej rozpowszechnionego języka programowania. To po cichu eliminuje wiele niepotrzebnej pracy i tarcia podczas przeglądów kodu.

W pełni uzasadnione jest wymaganie od wszystkich programistów opracowania nawyku stosowania formatera do nowo utworzonej sekcji kodu.

Najgorsze, co możesz zrobić, to zażądać niestandardowego stylu kodowania, którego nie obsługuje istniejący formater kodu.

W stosunkowo rzadkich przypadkach niektóre sekcje mogą być sformatowane inaczej, jeśli formatyzator robi to naprawdę okropnie, ale zwykle lepiej jest dopasować formatyzator, aby wszyscy lepiej formatowali.

Może to być kilka użytecznych reguł, których formater nie może obsłużyć (na przykład jak nazwać zmienne), ale jeśli tylko te pozostaną, można je stosunkowo łatwo zastosować.

Rzeczywiste rozwiązanie (nie tylko filozofia)

Zezwalaj na komentarze kodu, aby zastąpiły podszywanie się i kompiluj listy tych komentarzy, jeśli chcesz (jak to często bywa z komentarzami do zrobienia)

Daj swoim programistom możliwość pracy poza konwencją w sposób wyraźny i uzasadniony - a podczas przeglądów kodu przez ludzi może być sprawdzany w razie potrzeby.