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:
- 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?
development-process
coding-standards
Legalny Leniwy
źródło
źródło
Odpowiedzi:
Jest kilka powodów.
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.
źródło
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ę.
źródło
After the first few iterations, get the team together to decide.
z samą regułą nr 3 wydaje się, że opowiada się za brakiem standardu kodowania, ale biorąc pod uwagę wszystkie reguły razem, a przede wszystkim nr 6, wydaje się, że naprawdę mówi: „Nie na początku wymuś standard kodowania. Pozwól, by rozwijał się organicznie, a po chwili usiądź ze swoim zespołem, aby dopracować szczegóły. Co bardzo różni się od „Nie formalizuj swojego standardu kodowania” (co wydaje się być esencją wielu odpowiedzi).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 )
źródło
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.
źródło
Jeśli pytasz o uzasadnienie jego opinii, możesz uzyskać odpowiedź tylko wtedy, gdy opublikuje odpowiedź tutaj ( nasza opinia jest po prostu nieistotna), jednak ...
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 ).
„Bezpłatne samoorganizujące się programowanie” jest dobre dla 16-letniego faceta ninja, ale organizacje mają inne wymagania :
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
Wujek Bob
To prawda, dopóki nie masz standardu, a Twoja organizacja nie wyznaczyła Ci zadania jego zbudowania .
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, 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?
To prawda, że wytyczne muszą być krótkie, inaczej nikt ich nie przeczyta. Nie powtarzaj tego, co oczywiste.
Dobry standard dotyczy nie tylko jakości, chyba że chcesz mieć standard tylko w przypadku drobnych szczegółów.
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:
źródło
źródło
Jest wiele powodów. Oto kilka uwag:
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?
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.
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:
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ł.
źródło
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ć.
źródło
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
Kompilator nie da błędu, a to jest trudne do wykrycia podczas czytania dużej ilości kodu. Jeśli jednak napiszesz:
Kompilator daje błąd i łatwo zmienić kod na
3 == a
. Podobnie, jeśli standard kodowania nie pozwala=
na użycie w ramachif
warunku lub „pustejif
instrukcji”, 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.
źródło
Posiadanie źródła jako samodokumentującego standardu kodowania implikuje dwie rzeczy.
źródło
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.
źródło
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.
źródło
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.
źródło
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
new
w 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
__Ugly
nazw 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.
źródło