Dlaczego wujek Bob sugeruje, że nie należy zapisywać standardów kodowania, jeśli można tego uniknąć?

Kiedy czytałem to pytanie , w głosowaniu , który uzyskał najwyższy wynik, był cytowany wujek Bob o standardach kodowania , ale ta wskazówka mnie zaskoczyła:

3. Nie zapisuj ich, jeśli możesz tego uniknąć. Zamiast tego niech kod będzie sposobem na uchwycenie standardów.

To odbiło się w moim umyśle, ale nie mogłem znaleźć miejsca, w którym mógłbym się trzymać. Jeśli do zespołu dołącza nowa osoba lub zmieniają się standardy kodowania, czy nie może być pomyłki w informacjach?

Dlaczego nie powinienem zapisywać standardu kodowania?

Jest kilka powodów.

1. Nikt nie czyta dokumentacji.
2. Nikt nie postępuje zgodnie z dokumentacją, nawet jeśli ją czyta.
3. Nikt nie aktualizuje dokumentacji, nawet jeśli ją czyta i postępuje zgodnie z nią.
4. Napisanie listy praktyk jest znacznie mniej skuteczne niż tworzenie kultury.

Standardy kodowania nie dotyczą tego, co ludzie powinni robić, ale tego, co faktycznie robią. Gdy ludzie odejdą od standardów, należy to odebrać i zmienić poprzez proces przeglądu kodu i / lub zautomatyzowane narzędzia.

Pamiętaj, że cały sens standardów kodowania ma ułatwić nam życie. Są skrótem dla naszego mózgu, abyśmy mogli odfiltrować niezbędne rzeczy z ważnych rzeczy. O wiele lepiej jest stworzyć kulturę recenzji, aby to wymusić, niż sformalizować ją w dokumencie.

Jest inna interpretacja. Nie wierzę, że to właśnie miał na myśli wujek Bob, ale warto to rozważyć.

Nie przechwytuj standardów kodowania w dokumencie. Uchwyć to w kodzie dzięki zautomatyzowanemu procesowi, który sprawdza, czy standardy są przestrzegane .

Nie polegaj na ludziach odwołujących się do dokumentu, ale jednocześnie nie polegaj na ludziach interpretujących kod, który już istnieje i identyfikujących konwencję i przypadek.

Włącz coś takiego jak Checkstyle do swojej wersji zatwierdzania. Może to egzekwować podstawowe zasady, takie jak standardy formatowania i nazewnictwa, a następnie nie marnować wysiłku umysłowego na rozważanie stylu, a wszystko to może zostać odciążone do głupiego procesu, który przynajmniej jest dokładny.

Jeśli ma to znaczenie, to dokładnie określ, czego chcesz, a jeśli nie, to nie powiodło się.

Ludzie przeoczają prawdziwy cel dokumentu standardów kodowania, jakim jest rozstrzyganie sporów .

Większość decyzji w standardzie kodowania będzie miała bardzo niewielki wpływ na czytelność i wydajność. Zwłaszcza jeśli zastosujesz „normalny” styl dla języka, a projektanci języków zaczynają zdawać sobie sprawę, że powinien to być element specyfikacji (np. Go).

Ponieważ są tak trywialne, argumenty mogą się naprawdę rozgrzać i działać bez końca, wyrządzając realne szkody produktywności i spójności zespołu. Lub może przesłonić historię zmian z niekończącym się formatowaniem między dwoma lub więcej preferowanymi stylami.

Posiadanie pisemnego standardu kończy argument. Menedżerowie mogą na to wskazywać i odwracać niezadowolenie od dokumentu. Możesz kłócić się z kawałkiem papieru, ale on cię nie wysłucha.

(Zobacz także Tyrania bez struktury )

Ponieważ komentarze to kłamstwa .

Standard kodowania to świetny duży komentarz na temat tego, jaki powinien być kod. Sam kod jest ostatecznym źródłem prawdy. Prawda w tym przypadku nie jest zachowaniem kodu, jest stylem, w którym jest wyrażona. Jeśli twoje standardy nie są jeszcze odzwierciedlone w kodzie, masz przed sobą dużo pracy.

Wujek Bob uważa komentarz za osobistą porażkę programisty, ponieważ dowodzi on, że nie udało mu się wyrazić celu fragmentu kodu za pomocą samego języka programowania. Podobnie dokument standardowy nie wyraża spójnego stylu w bazie kodu.

Nowi programiści powinni spędzać czas na przeglądaniu kodu, a nie na czytaniu dokumentu ze standardami złożonymi z wielu rozdziałów (musiałem to zrobić, westchnienie).

Dokument standardów nie jest złym pomysłem, ale byłem w sklepach programistycznych, w których utrzymanie dokumentów standardów było czyjąś pracą na pełny etat. Jeśli musisz zachować dokument standardu, zachowaj go na stronie. Ale jeśli masz już kod, czy nikt nie powinien być w stanie złożyć tego samego dokumentu w niecały dzień?

Posiadanie standardów kodu jest ważne. Posiadanie dokumentu, który określa, czym one są, nie jest.

Dlaczego wujek Bob sugeruje, że nie należy zapisywać standardów kodowania, jeśli można tego uniknąć?

Jeśli pytasz o uzasadnienie jego opinii, możesz uzyskać odpowiedź tylko wtedy, gdy opublikuje odpowiedź tutaj ( nasza opinia jest po prostu nieistotna), jednak ...

Dlaczego nie powinienem zapisać standardu kodowania?

Jeśli pytasz, czy ma rację : pozwól mi być jedyną niepopularną (jak dotąd), że nie masz powodu, aby tego unikać.

ZAPISZ GO . Spróbuję jednak wyjaśnić swoje powody ...

David zasugerował w komentarzu, że głównym punktem odpowiedzi Stephena nie jest powód, dla którego nie należy pisać dokumentów, ale w jakiej formie. Jeśli wytyczne są sformalizowane w narzędziach (a nie tylko manualna weryfikacja kodu), mogę się zgodzić (gdy prawo nie wymaga czegoś innego). Pamiętaj, że niestety narzędzia często nie sprawdzają wszystkiego (teoria obliczeń nie jest naszym przyjacielem) często, ponieważ są ograniczone do konkretnej jednostki tłumaczeniowej lub pakietu lub dowolnego ulubionego języka, który określa granicę .

Jednak sformułowanie wuja Boba nie każe mi myśleć, że o tym mówi.

Czy mogę się nie zgodzić z takim starszym ekspertem? Tak, dla prawie każdego punktu w cytowanym poście (szczegółowe informacje można znaleźć w drugiej części tej odpowiedzi). Spróbujmy zrozumieć, dlaczego (zakładając, że już wiesz, że wytyczne dotyczące kodowania nie dotyczą jedynie drobnych problemów z formatowaniem ).

• W niektórych okolicznościach prawo wymaga pisemnych standardów kodowania.
• Czytam dokumentację i jestem pewien, że nie jestem sam. Członkowie zespołu mogą się zmieniać z czasem, wiedza nie może znajdować się w bazie kodu w wieku 5-10 lat lub w głowach członków zespołu. Organizacje powinny zwalniać osoby, które nie przestrzegają wewnętrznych wytycznych.
• Standardy kodowania, po ich zatwierdzeniu , nie będą się często zmieniać, a jeśli tak, to chcesz o tym wiedzieć. Jeśli standardy uległy zmianie, wówczas dokumentacja (w kodzie) jest nieaktualna, ponieważ cały kod nie jest zgodny z nowym standardem. Ponowne formatowanie / refaktoryzacja może być powolna, ale zawsze masz pisemne autorytatywne wytyczne, których należy przestrzegać.
• Lepiej jest przeczytać 5-stronicowy dokument niż sprawdzić LOC 10 / 20K w celu ekstrapolacji reguły (co może być źle zrozumiane, BTW), co do tego nie ma wątpliwości.
• To ironiczne, że ktoś, kto napisał wiele książek o zasadach projektowania i stylu kodowania, sugeruje, że nie powinieneś pisać własnych wytycznych, czy nie jest lepiej, gdyby rzucił nam kilka przykładów kodu? Nie, ponieważ pisemne wytyczne nie tylko mówią, co robić, ale także dwie inne rzeczy, których brakuje w kodzie: czego nie robić i powody, aby to zrobić lub nie.

„Bezpłatne samoorganizujące się programowanie” jest dobre dla 16-letniego faceta ninja, ale organizacje mają inne wymagania :

• Jakość kodu musi być przyznawana (i definiowana) na poziomie firmy - nie jest to coś, o czym może decydować pojedynczy zespół. Mogą nawet nie mieć umiejętności decydowania o tym, co jest lepsze (na przykład, ilu programistów ma wszystkie wymagane umiejętności, aby przejrzeć MISRA lub nawet po prostu zrozumieć każdą regułę?)
• Członkowie mogą być przenoszeni między różnymi zespołami: jeśli wszyscy przestrzegają tych samych standardów kodowania, integracja jest płynna i mniej podatna na błędy.
• Jeśli zespół sam się organizuje, standardy będą ewoluować wraz z upływem czasu, gdy członkowie zespołu się zmienią - wtedy będziesz mieć ogromną bazę kodów, która nie będzie zgodna z obecnie przyjętymi standardami .

Jeśli myślisz o ludziach przed procesem , mogę jedynie zasugerować przeczytanie o TPS: ludzie są centralną częścią Lean, ale procedury są bardzo sformalizowane.

Oczywiście mała organizacja z tylko jednym zespołem może pozwolić zespołowi zdecydować o przyjętych standardach, ale wtedy trzeba to zapisać. Tutaj na Programmers.SE możesz przeczytać posty Erica Lipperta: Przypuszczam, że wszyscy zgadzamy się, że jest doświadczonym programistą, kiedy pracował dla Microsoft, musiał przestrzegać ich pisemnych wytycznych (nawet jeśli niektóre reguły mogą być złe , nie mają zastosowania lub są bezużyteczne do niego.) Co z Jonem Skeetem? Wytyczne Google są dość surowe (i wiele osób się z nimi nie zgadza), ale musi je przestrzegać. Czy to im nie szanuje? Nie, prawdopodobnie pracowali nad zdefiniowaniem i ulepszeniem takich wytycznych, firma nie jest utworzona przez jednego członka (lub jeden zespół), a każdy zespół nie jest wyspą .

Przykłady

• Zdecydowałeś się nie używać wielokrotnego dziedziczenia i klas zagnieżdżonych w C ++, ponieważ członkowie zespołu nie rozumieją tego dobrze . Później ktoś, kto chce użyć wielokrotnego dziedziczenia, musi przejrzeć cały LOC 1M, aby sprawdzić, czy kiedykolwiek był używany. Jest to złe, ponieważ jeśli decyzje projektowe nie są udokumentowane, musisz przestudiować całą bazę kodu, aby je zrozumieć. I nawet wtedy, jeśli nie został użyty, to dlatego, że jest niezgodny ze standardem kodowania, czy też jest dozwolony, ale po prostu nie było wcześniejszych sytuacji, w których wielokrotne dziedziczenie było dobrze dopasowane?
• W języku C # przeciążono metody dostarczania parametrów domyślnych, ponieważ baza kodu została uruchomiona, gdy parametry opcjonalne nie były dostępne w języku C #. Potem zmieniłeś się i zacząłeś ich używać (refaktoryzując stary kod, aby używać ich za każdym razem, gdy musiałeś modyfikować takie funkcje). Nawet później zdecydowałeś, że parametry opcjonalne są złe i zaczynasz unikać ich używania. Jaka jest reguła zawarta w kodzie? Jest źle, ponieważ standard ewoluuje, ale baza kodu ewoluuje wolniej, a jeśli jest to twoja dokumentacja, masz kłopoty.
• Jon przeniósł się z zespołu A do zespołu B. Jon musi nauczyć się nowego standardu; podczas nauki prawdopodobnie wprowadzi bardziej subtelne błędy (lub, jeśli będzie miał szczęście, po prostu zajmie dużo czasu, aby zrozumieć istniejący kod i wydłużyć jego przegląd).
• Zespół A przenosi się do bazy kodu, która była wcześniej własnością zespołu B. Ma on zupełnie inne standardy kodowania. Przepisać? Przystosować się? Mieszać? Wszystkie są równie złe.

Wujek Bob

Niech ewoluują podczas pierwszych kilku iteracji.

To prawda, dopóki nie masz standardu, a Twoja organizacja nie wyznaczyła Ci zadania jego zbudowania .

Niech będą specyficzne dla zespołu, a nie dla firmy.

Nie, z wszystkich powodów wyjaśnionych powyżej. Nawet jeśli myślisz o sformalizowaniu tylko formatowania kodu (najmniej przydatna rzecz, którą możesz chcieć sformalizować), wciąż mam pamięć niekończących się (i bezużytecznych) wojen o formatowaniu. Nie chcę ich przeżywać raz po raz, ustaw to raz na zawsze.

Nie zapisuj ich, jeśli możesz tego uniknąć. Zamiast tego niech kod będzie sposobem na uchwycenie standardów.

Nie, z wszystkich powodów wyjaśnionych powyżej (oczywiście o ile nie zmienisz całego kodu za jednym razem, gdy zmienią się wytyczne). Czy chcesz pozostawić swój kod bez zmian? Jak sprawdzasz bazę kodów, aby zrozumieć aktualne wytyczne? Wyszukiwanie według wieku pliku i dostosowanie stylu kodowania do wieku pliku źródłowego?

Nie ustanawiaj dobrego projektu. (np. nie mów ludziom, żeby nie używali goto)

To prawda, że ​​wytyczne muszą być krótkie, inaczej nikt ich nie przeczyta. Nie powtarzaj tego, co oczywiste.

Upewnij się, że wszyscy wiedzą, że standard dotyczy komunikacji i nic więcej.

Dobry standard dotyczy nie tylko jakości, chyba że chcesz mieć standard tylko w przypadku drobnych szczegółów.

Po kilku pierwszych iteracjach zbierz zespół razem, aby podjąć decyzję.

Zobacz pierwszy punkt i nie zapominaj, że standard kodowania to zwykle proces, który wymagał wielu lat, aby go opracować i udoskonalić: kilka iteracji, może z młodszymi programistami? Naprawdę? Czy chcesz polegać na pamięci jednego członka wyższego (jeśli w ogóle) członka?

Trzy notatki:

• Moim zdaniem wady niektórych języków są poważniejsze niż w innych, na przykład w C ++ standard na poziomie firmy jest nawet bardziej potrzebny niż w Javie.
• Takie rozumowanie może nie mieć pełnego zastosowania (a powody wuja Boba mogą być mniej skrajne ), jeśli pracujesz w bardzo małej firmie, w której masz tylko jeden mały zespół.
• Jesteś zatrudniony (jako zespół) i będziesz pracować sam z jednym nowym projektem, a potem go zapomnisz i przejdziesz dalej. W takim przypadku możesz się nie przejmować (ale twój pracodawca powinien ...)

1. Aby być użytecznym, standard kodowania nie może mówić o kwestiach merytorycznych; tylko kwestie stylu. Powinien określać tylko te rzeczy, które są arbitralne i niejednoznaczne. np. umiejscowienie nawiasu klamrowego, głębokość wcięcia, spacje vs tabulatory, konwencje nazewnictwa itp.
2. Kwestie stylu mają charakter lokalny, a nie globalny. Każda drużyna powinna przyjąć swój własny styl, dopasowany do zadania i osobowości. Dzięki temu standardy są proste i lekkie. Standardy korporacyjne są przeciążone wszystkimi możliwymi względami, konfiguracjami i wyjątkami.
3. W zespole jedynym powodem, aby napisać osobny dokument w stylu kodowania jest to, że kod wytworzony przez zespół nie spełnia normy. W takim przypadku nie masz standardu. Aby być skutecznym, standard powinien być wyrażony przez sam kod. A jeśli tak, to nie ma potrzeby oddzielnego dokumentu.
4. W starszych systemach zespoły i style zmieniają się z czasem. Nie ma w tym nic złego. Stary kod będzie miał starszy styl. Nowszy kod będzie miał nowszy styl. Zespół powinien być świadomy stylów i ich wieku. Za każdym razem, gdy zapisywany jest nowy kod, powinien on być w nowym stylu, bez względu na to, gdzie znajduje się kod.

Dlaczego nie powinienem zapisać standardu kodowania?

Jest wiele powodów. Oto kilka uwag:

1. Ile czasu ludzie spędzają na „uczeniu się” norm kodowych, aby poświęcić dużo czasu całemu zespołowi na przeglądanie, dyskutowanie, dokumentowanie, weryfikację ... itd. Norm kodowych. To jak ciągłe omawianie „Podręcznika pracownika” - jak często wpisuje się to w harmonogram spotkania zespołu?

2. Kiedy projekt zostaje spłacony / odłożony na półkę itp. wtedy niewielu ludzi, którzy pozostali, zwykle nie może nadal przestrzegać (a może nawet nie czytać) standardów. Następną rzeczą, którą wiesz, cały ten wysiłek „utrzymania kodu w czystości” został zmarnowany.

3. Jeśli projekt utknie w martwym punkcie lub zostanie wprowadzony nowy trop, jest bardzo prawdopodobne, że osoba całkowicie zignoruje poprzednie zasady i zechce to zrobić w nowy sposób. Znowu, co uzyskano dzięki kodyfikacji standardów

Powinieneś koniecznie przeczytać # 6:

Po kilku pierwszych iteracjach zbierz zespół razem, aby podjąć decyzję.

Innymi słowy, kiedy nadszedł czas, aby rozpocząć projekt, po prostu idź z prądem przez chwilę. Następnie omów ogólne zasady kodowania standardów używanych przez obecny zespół - i zasadniczo ich przestrzegaj. W ten sposób maksymalizujesz wysiłek włożony w ulepszanie produktu, jednocześnie minimalizując wysiłek potrzebny do napisania, przeglądu i udokumentowania „cukru syntaktycznego”, który został wykorzystany do uzyskania kodu wykonywalnego.

Bardzo niewiele zespołów czerpie ogromne korzyści ze standardów kodowania. Zwykle „czytelność” jest zbyt niejasna - i większość programistów nie korzysta z dokładnych reguł dotyczących odstępów, nowych wierszy itp., Ale można uniknąć ciągłego denerwowania programistów, mając co najmniej kilka reguł.

Inną odpowiedzią, która moim zdaniem nie została wystarczająco jasno określona, ​​jest to, że oznacza to również, że ludzie nie przestrzegają reguł na ślepo. Oznacza to, że ludzie muszą wymyślić rzeczywiste uzasadnienia swoich decyzji projektowych i konwencji kodowania, a nie tylko w zależności od tego, że zostało to spisane, aby to uzasadnić.

Po pierwsze, o ile wiem, wujek Bob jest osobą Java, jest to bardzo ważne dla zrozumienia tego, co mówi.

Podczas pracy w zespole Java lub C #, jeśli obecny kod został napisany przez doświadczonych programistów, łatwo jest mi wybrać styl kodowania i nadążyć za nim. Jeśli nie chcę tego robić, być może nie jestem odpowiednią osobą do pracy ... Jeśli nie ma recenzji kodu ani programowania w parach, które mogłyby mnie odebrać, gdy nie trzymam się tego stylu, to firma ma większy problem niż sposób, w jaki nazywam pola członków!

Zarówno Java, jak i C #, wraz z większością współczesnych języków, zostały zdefiniowane tak, że istnieje kilka „prostych” pułapek dla programistów.

Jednak kiedy zacząłem programować, używałem C (a później C ++). W C możesz pisać jak kod

if (a = 3);
{
   /* spend a long time debugging this */
}

Kompilator nie da błędu, a to jest trudne do wykrycia podczas czytania dużej ilości kodu. Jeśli jednak napiszesz:

if (3 = a)
{
   /* looks odd, but makes sense */
}

Kompilator daje błąd i łatwo zmienić kod na 3 == a. Podobnie, jeśli standard kodowania nie pozwala =na użycie w ramach ifwarunku lub „pustej ifinstrukcji”, wówczas można użyć kontrolera kodu jako części systemu kompilacji do śledzenia tego błędu.

Moje poglądy na standardy kodowania bardzo się zmieniły, kiedy odszedłem z C / C ++: lubiłem standardy kodowania, które były ściśle egzekwowane i wiele stron. Myślę, że teraz wystarczy wymienić listę używanych narzędzi i uzyskać nieformalne porozumienie między oryginalnymi członkami zespołu w sprawie kilku konwencji nazewnictwa. Nie żyjemy już w świecie zespołów ponad 30 programistów piszących aplikacje w C / C ++ ...

Jest powód, dla którego nigdy nie lubiłem JScript i uważam, że TypeScript to najlepsza rzecz, jaka przydarzyła się programistom internetowym od lat. Oczekuję, że programiści Web UI nadal potrzebują standardów kodowania z powodu wad w projektowaniu HTML / CSS / JScript itp.

Posiadanie źródła jako samodokumentującego standardu kodowania implikuje dwie rzeczy.

1. Ludzie muszą zapoznać się z bazą kodu i przejrzeć go, aby stać się sprawnymi współpracownikami. To jest niezwykle ważne. Czytanie wskazówek dotyczących kodowania jest stratą czasu w porównaniu do nurkowania w bazie kodu.
2. Przyznaje, że niewielkie różnice są nieistotne. Ważne jest, aby uzgodnić i zrozumieć podstawowe zasady. Utrzymanie spójnego stylu nie jest realizowane jako l'art pour l'art. Nie pozwala niewiernym nikczemnikom denerwować i rozpraszać innych ludzi. Chodzi o ułatwienie komunikacji za pomocą kodu w zespole.

Często aktualizowany i dobrze napisany dokument standardów kodowych może być bardzo przydatny, ale zwykle tak nie jest. Dokument standardów nie odzwierciedla faktycznych standardów kodowania stosowanych przez firmę, ponieważ bardzo trudno jest stworzyć dobry dokument standardów, a jeszcze trudniej jest go aktualizować.

Zamiast mieć kiepski i wprowadzający w błąd dokument standardów kodowania, lepiej go nie mieć i pozwolić, aby sam kod reprezentował te standardy. Tak czy inaczej, najważniejszą częścią jest zastosowanie standardów w kodzie, a to wymaga znacznie więcej niż tylko dokumentu. Motywacja, procesy, szkolenia, narzędzia itp. Są znacznie ważniejsze.

Bardzo ważną rzeczą, która nie została wystarczająco jasno określona, ​​jest to, że standardy kodowania są jak język: ewoluują. Pisemny standard kodowania stoi temu na przeszkodzie, a jeśli nie jest, jest stale nieaktualny i bezużyteczny.

Brak ustalonego standardu kodowania nie jest taki zły. Jeśli dokonujesz recenzji podczas odprawy, za każdym razem, gdy coś niezgodnego ze standardem kodowania wejdzie do repozytorium, oznacza to, że 2 osoby pomyślały o tym * i zdecydowały, że korzyść z tego wariantu przeważa nad niespójnością z resztą kodu.

Brak spisanego standardu usuwa również biurokrację, która uniemożliwiłaby zespołowi firmy wypróbowanie nowej odmiany standardu kodowania dla nowego projektu, albo dlatego, że chce czegoś wypróbować, albo może dlatego, że inny standard ma praktyczne zastosowania na niektóre z zautomatyzowanych narzędzi, których używają.

Zapisanie standardu ma tendencję do usuwania większej elastyczności niż pierwotnie zakładano, a jednocześnie zajmuje sporo czasu, który można by poświęcić na inne rzeczy. Nie twierdzę, że nigdy nie powinieneś zapisywać standardów kodowania, pisane standardy z pewnością mają swoje zalety, zwłaszcza jeśli zespoły pracujące w różnych lokalizacjach pracują na tej samej podstawie kodu.

Silnie powiązane: ewolucja standardów kodowania, jak sobie z nimi radzić?

* Jeśli ludzie nie myślą podczas przeglądania kodu podczas odprawy, twoje problemy są znacznie większe niż tylko standardy kodowania.

Ich zmiana staje się poważną przeszkodą, a ludzie będą bezpiecznie stosować się do litery prawa, zamiast angażować mózgi i postępować właściwie.

Nadejdzie dzień, w którym część standardu będzie nieprzydatna i pogorszy kod. Niektóre osoby będą stosować się do normy, ponieważ jest ona spisana i są bezpieczni, a także dlatego, że należy przestrzegać zasad. Ludzie, którzy chcą pisać dobry kod zamiast kodu zgodnego ze standardami, będą sfrustrowani i źli. Będą kłótnie i spory, podczas gdy gdyby norma nie została spisana, byłyby badania i dyskusja.

Myślę, że wiele postów tutaj myli standard kodowania z przewodnikiem po stylu .

Upewnienie się, że moduły opracowane przez różne zespoły mają te same opcje kompilatora, a ABI jest czymś innym niż liczba wcięć.

Rzeczy, takie jak właściwy sposób struktury #include plików i niezanieczyszczanie globalnej przestrzeni nazw w pliku nagłówkowym, powinny być udokumentowane, aby można je było wykorzystać jako listę kontrolną podczas wstępnego kodowania i przeglądów kodu.

W szczególności „nie używaj XXX, ponieważ powoduje to problemy ze zgodnością z YYY”, nie jest czymś, co można zobaczyć na przykładzie innego kodu, ponieważ go nie ma. Niech więc kod będzie zgodny ze sposobem przechwytywania standardów, może być niejasny lub całkowicie brakujący dla niektórych rodzajów standardów, a zatem nie może to być plan uniwersalny.

Coś poważnie wszechobecnego i ważnego, jak niestosowanie wyjątków lub niestosowanie neww niektórych systemach wbudowanych, nie może być po prostu pozostawione powszechnej wiedzy o kulturze, ponieważ ta „informacja jest kulturowa (tylko)” jest sprzeczna z podstawowymi zasadami standardów produkcji, takich jak ISO-9000, że twórca tych systemów wbudowanych używa (np. do zastosowań motoryzacyjnych). Te ważne rzeczy muszą zostać udokumentowane, podpisane i złożone w oficjalny sposób.

Ale dotyczy to kodowania , a nie stylu .

Twórcy C i C ++ pokazują, na przykład, użycie małych liter, a nie CaMelCaSe. Dlaczego więc tak wielu programistów nie podąża za niejawnym przykładem z fontanny? Czy styl standardowej biblioteki i kanonicznych materiałów dydaktycznych nie powinien być bezpośrednim stylem, którego należy przestrzegać?

Tymczasem ludzie zrobić za przykładem standardowych nagłówków Biblioteka dla rzeczy, które nie powinny być kopiowane, takie jak wykorzystanie __Uglynazw dla parametrów makro i include file zakaz powtarzania wzorca.

Tak więc posiadanie rzeczy często nie jest postrzegane jako ważny styl, lub odwrotnie posiadanie przykładów może nie być jasne, co nie powinno być przestrzegane w kodzie projektu. Oba są kontrprzykładami dla tezy, że „styl” (lub konwencje kodowania) najlepiej pozostawić w domniemaniu.