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

145

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:

  1. 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?

Legalny Leniwy
źródło
47
Hmm Próbuję sobie wyobrazić, jak to by działało w dużej międzynarodowej firmie z setkami programistów i bazą kodu obejmującą dziesięciolecia.
Matthew James Briggs
31
@MatthewJamesBriggs: działa co najmniej tak dobrze, jak zapisany standard, który większość deweloperów ignoruje lub który miał inną treść w momencie, gdy kod został napisany na początku.
Doc Brown
7
@MatthewJamesBriggs: uzgodniono. Przewodnik po stylu powinien zawierać wystarczającą ilość informacji, aby rozpoznać wcześniejsze konwencje, które są obecnie przestarzałe, w przeciwnym razie kultura „kopiowania istniejącego stylu” znajdzie jakieś 10-letnie horrory do wskrzeszenia. Ponadto, gdy przypadkowo powstają kliki, które wykorzystują różne i niezgodne okazy do ustalenia oficjalnego stylu, pisemny przewodnik po stylu mówi, która z nich jest prawidłowa (lub idealnie zapobiega przede wszystkim tworzeniu się kliki). A jeśli niektórzy z twoich setek deweloperów nie czytają dokumentów, w dużej firmie możesz po prostu zwolnić ich za rażące muppetry.
Steve Jessop
14
Chociaż, żeby być uczciwym, Bob powiedział również, że nie powinieneś mieć w ogóle standardu kodowania w całej firmie, pisanego lub niepisanego. Każda drużyna / klika powinna raczej opracować własną.
Steve Jessop
37
Zamiast pisać dokument, którego nikt nie przeczyta, użyj linijki, która wymusza kodowanie w określony sposób. Jeśli jest to część twojego procesu rozwoju, jest to nieuniknione.
Seiyria

Odpowiedzi:

256

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.

Stephen
źródło
11
A jeśli chcesz wymusić pewne rzeczy, powinieneś mieć krok kompilacji, który to wymusza, a nie przewodnik stylu, który to wymusza.
Wayne Werner
31
Czy naprawdę nie masz standardowego dokumentu, ale po prostu krzyczysz na ludzi przez kilka pierwszych tygodni przy każdej recenzji kodu? Wygląda na to, że w zasadzie oczekujesz od początkujących inżynierów odtwarzających przewodniki po stylu kodowania. Czy może jest to bardziej hipotetyczne „Myślę, że o to mu chodziło”? Teraz, jeśli chodzi o automatyczne narzędzia do egzekwowania tych zasad - uzgodnione, to bardzo ważne. Ale nie chcę żmudnie wymyślać zasad.
Voo
13
@Voo, dlaczego uważasz, że musisz krzyczeć podczas sprawdzania kodu, jeśli pojawia się problem?
Jaap
20
@Jaap Myślałem, że hiperbola była oczywista .. najwyraźniej nie. Nie, nie krzyczy na ludzi, ale mówi im, że muszą wrócić i naprawić wszystkie rzeczy, które naruszyli, ponieważ nie mogli wiedzieć lepiej.
Voo,
5
@Voo: nie trzeba „odwracać przewodników po stylu kodowania”. Konwencje powinny być widoczne , patrząc na istniejący kod. Wszystko, co nie od razu rzuca się w oczy, jest albo rzadkie, albo nawet nie naprawione. W przypadku, gdy istnieją naprawdę ważne zasady dotyczące czegoś rzadko występującego, warto omówić to z nowymi programistami, kiedy to oni muszą napisać taki kod. Nie można przecenić komunikacji.
Holger
112

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ę.

Tom Johnson
źródło
6
Podejrzewam, że coś takiego było przynajmniej częścią rozumowania wuja Boba dla tej sugestii. Automatyzacja standardów kodowania towarzyszy automatycznym testom jako przydatny sposób na poprawę jakości i jestem pewien, że Bob wie o tym ...
Jules
10
Warto wspomnieć o regule nr 6: 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).
Shaz
Jeśli przeczytasz elementy, myślę, że przekonasz się, że na pewno nie o to mu chodziło, na przykład ten sam powinien ci coś powiedzieć: 2. Niech będą specyficzne dla zespołu, a nie dla firmy.
Bill K
Zauważ, że odpowiadam na pytanie „Dlaczego nie powinienem zapisywać standardu kodowania” - a nie „Co miał na myśli wujek Bob”. Może to być sprzeczne z tytułem pytania, ale nie z jego duchem.
Tom Johnson
Zauważ, że zautomatyzowany system formatu kodowania, który nie zapewnia klauzuli Escape (w której mogę go wyłączyć dla części kodu), prawie na pewno będzie kiedyś złośliwym oprogramowaniem.
Jak
66

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 )

pjc50
źródło
19
Jest to niezwykle ważne dla zespołów zajmujących się starszym kodem. Zwłaszcza przy przechodzeniu od kodu zgodnego z jednym zestawem standardów (lub nie przestrzegając żadnych standardów) do innego. Bez wytycznych, do których należy się odwoływać, nie można powiedzieć, który styl kodu należy zastosować, gdy w bazie kodu jest już dostępnych wiele stylów. Myślę, że rada, by nie spisywać norm, jest przeznaczona dla bardzo małych zespołów pracujących nad projektami typu greenfield bez rotacji ryzyka - z mojego doświadczenia bardzo rzadki przypadek.
thomij
4
O wiele ważniejsze jest uzgodnienie standardu niż faktyczna zawartość standardu. Możesz przyzwyczaić się do prawie każdego stylu, jeśli pracujesz z nim wystarczająco długo.
Mark Ransom
3
Kłótnie na temat błahości to znak niekompetencji, IMHO. Rozwiązanie konkretnego sporu nie rozwiąże podstawowego problemu.
Jørgen Fogh,
1
Tak, rozwiązywanie sporów i utrzymywanie historii zmian w stanie niezanieczyszczonym są ogromne, szczególnie gdy masz w zespole zespół programistów OCD i nie tak bardzo OCD. Odkryłem jednak, że pisemne standardy są znacznie mniej skutecznymi arbitrem niż zautomatyzowane narzędzia, takie jak StyleCop, które ustanawiają prawo, nie czyniąc go osobistym ani nie marnując czasu menedżerów.
Eric Hirst,
12
„Kłótnie na temat błahości są oznaką niekompetencji” - Szkoda, że tak nie było w inżynierii oprogramowania… Obawiam się, że niektórzy bardzo, bardzo kompetentni (przynajmniej technicznie) deweloperzy są tymi, którzy najbardziej lubią kłócić się o błahe. Do diabła, to ich narodowy sport. „Nieskończeni są argumenty magów” ​​- Ursula Le Guin
Spike0xff
21

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.

candied_orange
źródło
22
Właściwie doświadczyłem liczącej wiele dekad bazy kodu z zasadą „bez komentarzy”; chociaż zachęca do bardzo długich nazw opisowych metod, jest absolutnie okropny w uchwyceniu zamiarów, powodów, dla których nie należy robić rzeczy, i uciekamy od tego tylko wtedy, gdy mamy przy sobie jednego z oryginalnych autorów.
pjc50
7
+1 „Posiadanie standardów kodowych jest ważne. Posiadanie dokumentu, który określa, czym one są, nie jest.” Cóż i zwięźle mówiąc.
David
4
@ pjc50 Nigdy nie słyszałem, żeby wujek Bob zachęcał do polityki bez komentarzy. On nie uczy, że nigdy nie powinieneś komentować. Uczy, że powinieneś czuć się źle, kiedy odkryjesz, że musisz to zrobić, aby zostać zrozumianym. Niekomentowany nieczytelny <skomentowany nieczytelny <czytelny kod, który nie wymaga komentarzy. Zauważ, że wspomniane komentarze są całkowicie oddzielone od JAK działa kod. Dokumenty normalizacyjne mogą zmienić się w listę kontrolną „martwego mózgu”, która zostaje zaznaczona podczas przeglądu kodu. Ważne jest to, że nie dostaniesz wszystkich tyknięć. Ludzie przy stole rozumieją twój kod.
candied_orange
3
„Nowi programiści powinni spędzać czas na przeglądaniu kodu, a nie na czytaniu dokumentu zawierającego wiele rozdziałów standardów”. Nie mam pojęcia, jakie przewodniki kodowania podążasz, ale przewodnik po stylu C ++ firmy Google można łatwo odczytać w mniej niż godzinę i jest o wiele łatwiej zrozumieć, niż konieczność inżynierii wstecznej preferowanego stylu na podstawie istniejącego kodu (co dla mnie brzmi okropnie). To samo dotyczy każdego innego przewodnika po stylu, jaki kiedykolwiek przeczytałem.
Voo
5
@CandiedOrange: Często najbardziej przydatne komentarze to te, które opisują powód, dla którego niektóre rzeczy nie zostały zrobione [ponieważ w przypadku braku takich komentarzy przyszli programiści mogą tracić czas na próby wdrożenia, a później wycofania pozornie oczywistych „usprawnień”, które się w tym momencie zmieniają być niewykonalnym]. O ile nie zaszaleje się na punkcie nazw zmiennych, nie ma możliwości, aby nawet najlepiej czytelny kod mógł przechwycić te informacje.
supercat
16

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 ...)
Adriano Repetti
źródło
5
Głosowałem za tym, ponieważ uważam, że odpowiedź na to pytanie jest nie na temat, dlatego właśnie dlatego (a zwłaszcza wujek Bob) nie napisałbyś standardu kodowania , a nie dlaczego. Myślę, że wszyscy rozumieją plusy posiadania pisemnego standardu, ale trudniejsze do ustalenia są wady, a kiedy szanowany starszy przemysł wychodzi z pozycji przeciwnej zwykłej praktyce w branży, badając, dlaczego z pewnością warto to zrobić.
Jules
5
@gnat dziękuję, nie potrzebuję aprobaty dla postów nie na temat, czyż nie „Dlaczego Pan X zrobił Y?” nie na temat w tym przypadku? Nie znamy jego powodów, a on ich nie wyjaśnił, czy nie powinno być zatem pytanie zamknięte jako nie na temat? Jak Ci odpowiedzieć na to pytanie? Wymyślać przypadkowe przyczyny lub mówić, że przesłanka jest błędna?
Adriano Repetti
1
@AdrianoRepetti - Wuj Bob przez lata wiele wyjaśniał, więc rozsądne jest rozważenie, że ktoś może mieć wgląd w jego sposób myślenia, ale masz rację, jeśli wymagana jest bezpośrednia interpretacja wuja Boba.
JeffO
3
@ jeff tak, jeśli pytanie dotyczy „dlaczego on tak myśli”, to odpowiedź jest tylko przypuszczeniem. Jeśli pytanie brzmi „czy to prawda?” wtedy moja osobista odpowiedź to d *** absolutnie nie.
Adriano Repetti
1
„kiedy pracował dla Microsoftu, musiał przestrzegać ich pisemnych wytycznych” - założę się, że tak. I oczywiście korzystaliśmy z FXCop i StyleCop, aby zapobiec pojawianiu się złych wzorów.
Eric Lippert
12
  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.
Robert Martin
źródło
Mam kilka problemów: 1) aby być użytecznym, standard kodowania nie powinien mówić tylko o formatowaniu (kwestia świętych wojen, ale łatwym do zrozumienia czytaniu kodu), ale konstruktach, których należy unikać, wzorcach kodowania (aby uniknąć typowych błędów, niezrozumiałego języka funkcje) i problemy z bezpieczeństwem. Są to wskazówki dotyczące kodowania (bardziej przydatne niż problemy z formatowaniem). 2) Biorąc pod uwagę założenie punktu 1, nie chodzi tu o osobowość (ale może dotyczyć zadań ), możesz mieć lekki korporacyjny standard, Twoim obowiązkiem jest uczynienie go lekkim.
Adriano Repetti
3) Kod może powiedzieć ci, co masz robić, ale nie może przekazać tego, czego nie powinieneś robić (chyba że chcesz przestudiować całą bazę kodu, a nawet w takim przypadku ... po prostu nie musiałem używać konstruktora X lub jest to nie-nie?) Kolejną ważną rzeczą jest uzasadnienie: dlaczego nie? i dlaczego tak? Z czasem może się to zmienić, ale skąd wiesz, czy początkowe założenia są nadal ważne? 4) a kiedy jesteś nowym członkiem zespołu i piszesz nowy kod ... czy studiujesz bazę kodu w tym samym wieku, aby zachować ten styl kodowania? Dzień po przejściu na inny nowszy komponent i ponownym przestudiowaniu bazy kodu (filtrowanie według daty utworzenia?)
Adriano Repetti
BTW, jeśli zamiast tego sugerują, aby nie zapisywać tylko kod style formatowania potem może zgodzić się (a właściwie nie, ale z nie tak silnych powodów oprócz wspomnienia niekończących się i niepotrzebnych dyskusji, które nieuchronnie powstają za każdym razem - i którego korporacyjnych wytyczna unikniesz tego raz na zawsze), ale powinieneś to wyjaśnić, inaczej ludzie będą interpretować twoje słowa zbyt dosłownie (zobacz większość odpowiedzi + komentarzy tutaj). Również ten punkt dotyczący „goto” jest nieco mylący w tym sensie (IMO)
Adriano Repetti
4

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ł.

Jim
źródło
4

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ć.

Finn O'leary
źródło
4

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.

Ian
źródło
4
„Kompilator nie spowoduje błędu” większość współczesnych kompilatorów C i C ++ obsługuje zgłaszanie takich zachowań za pomocą ostrzeżeń lub, w razie potrzeby, pełnych błędów. gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
JAB
2
„Po pierwsze, o ile wiem, wujek Bob jest osobą Java, jest to bardzo ważne w zrozumieniu tego, co mówi”, to nie prawda, wujek Bob napisał fantastyczne artykuły na temat C ++ i zdecydowanie pracował również kilka lat z C.
Alessandro Teruzzi
@JAB, na szczęście C / C ++ już dawno przestał być używany do nowych „aplikacji biznesowych” (np. Przed modemowymi kompilatorami C / C ++) i obecnie jest używany głównie przez ekspertów C / C ++, a nie ludzi, którzy są ekspertami od interfejsu użytkownika (MFC) na przykład.
Ian
1
@AlessandroTeruzzi Test jednostkowy pokaże, że metoda nie działa. Dlaczego zawodzi, to inna sprawa - nawet gdybyś miał testy jednostkowe dla metody z tego rodzaju kodem, ciężko byłoby ci się dowiedzieć, co się dzieje. C ++ jest jednym z najbardziej karnych języków do debugowania.
T. Sar
2
Myślę, że istnieje tu nieporozumienie, nie można wziąć ani jednego zdania wujka i analizować go w oderwaniu. Jeśli masz oprogramowanie SOLID z małymi klasami, krótkimi metodami i testami jednostkowymi kuloodpornymi, standard kodowania jest zbędny. Jeśli masz słaby kod, ogromny interfejs, duże funkcje i niewielki zasięg, standard kodowania może przynieść pewne korzyści. Ale UncleBob nie sugeruje, aby go nie mieć, ale aby rozpowszechnić go werbalnie dzięki współpracy i refaktoryzacji (usuń słaby kod z bazy źródłowej). Ustaw kod w żywy standard kodowania.
Alessandro Teruzzi
3

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.
Peter A. Schneider
źródło
2

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.

DesignerAnalyst
źródło
2

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.

Piotr
źródło
1

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.

Moschops
źródło
0

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.

JDługosz
źródło