Czy standard kodowania jest jeszcze potrzebny?

13

Wiem, że udowodniono, że standard kodowania ogromnie pomaga. Istnieje jednak wiele różnych narzędzi i IDE, które będą formatować zgodnie ze standardem preferowanym przez programistę. Dopóki kod jest uporządkowany / skomentowany (a nie bałagan spaghetti), nie widzę potrzeby standardu kodowania.

Czy są jakieś argumenty przemawiające za opracowaniem standardu kodowania (nie mamy takiego, ale chciałem go stworzyć)?

SomeKittens
źródło
Jeśli zdecydujesz się na wdrożenie standardu kodowania, rozważ wdrożenie go podczas ciągłej integracji.
Leif Carlsen
10
Czy wszyscy członkowie zespołu powinni być zobowiązani do korzystania z tego samego IDE?
Keith Thompson,
10
Żadna ilość formatowania kodu nie zastąpi wytycznych takich jak Nie przeciążaj operatorów, z wyjątkiem rzadkich, szczególnych okoliczności. . Jeśli twoje standardy kodowania dotyczą głównie sposobu formatowania kodu, potrzebujesz lepszych standardów.
Caleb
Nie wszyscy też używają IDE, na przykład używam Acme.
dysoco

Odpowiedzi:

33

Istnieje jednak wiele różnych narzędzi i IDE, które będą formatować zgodnie ze standardem preferowanym przez programistę.

Powodzenia z tym. Z mojego doświadczenia wynika, że ​​istnieje niewielka liczba narzędzi (zero!), Które mogą poprawnie sformatować kod z formatu X na format Y. Jest po prostu zbyt wiele rzeczy, które przeszkadzają. Tabulatory a spacje, instrukcje wieloliniowe itp. Wystarczy spojrzeć na implementację plików biblioteki standardowej C ++ w GNU. To, co możesz zrobić, to sprawić, aby IDE zawsze używał spacji zamiast tabulatorów i po prostu nie zawracał sobie głowy formatowaniem obcego kodu. Teraz twój kod wygląda tak, jak lubisz, a kod obcy wygląda tak, jak napisał go oryginalny autor.

Specyficzny styl wcięcia jest ostatnią rzeczą, którą powinien określać standard kodowania. To zbliża się do rozpoczęcia programowania wojny religijnej. IMO, standard kodowania powinien określać rozsądny zestaw akceptowalnych stylów wcięć, ale pozostawić szczegóły autorom pakietu. Styl wcięcia jest lub powinien być niewielką częścią standardu kodowania. Zasada numer zero standardów kodowania: Nie przejmuj się małymi rzeczami. Styl wcięcia to drobiazg.

Większe rzeczy:

  • Jak mam nazywać rzeczy?
  • Czy niektóre części języka są niedostępne?
  • Czy kod wymaga kompilacji w trybie czystym i przy jakich ustawieniach kompilatora?
  • Czy kod musi przekazać określone dane?
  • Jakie testy są potrzebne?
  • Jakiego rodzaju dokumentacja jest potrzebna, zarówno w kodzie (komentarze), jak i gdzie indziej?
  • Co najważniejsze, jak uzyskać zrzeczenie się standardu?

Dodatek
Być może jeszcze ważniejsze jest to, czego nie należy wprowadzać w standardach kodowania. Tematy takie jak pisanie wymagań nie należą do standardów kodowania. Szczegóły dotyczące testowania również nie należą. Projekt nie powinien wykorzystywać standardów kodowania jako standardu dla planu zarządzania projektem, planu zarządzania testami, planu weryfikacji i walidacji itp. Celem standardów kodowania jest poprawa bezpieczeństwa kodu, jakości, zrozumiałości, łatwości konserwacji, i inne „ility”. Istnieje wiele sposobów zapewnienia, że ​​tak się nie stanie. Tylko kilka: uczynienie ze standardów tak złożonej książki, jak przepisy podatkowe danego kraju, zachęcanie do programowania wojen religijnych, stosowanie złych konwencji nazewnictwa.

Standardy kodowania mogą mieć niezamierzone konsekwencje. Przykład: Niektóre głupiec inżynier projektowy ma zamiar interpretować „nie wyklucza magia liczb” oznacza, że if (index == 0) {...}i for (ii = 0; ii < 3; ++ii) {...}muszą zostać zmienione, aby if (ZERO == index) {}i for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}nie śmiej. Widziałem jak to się dzieje. W dzisiejszych czasach, kiedy piszę standard kodowania, jest to „wytyczna braku magicznych liczb”, a nie zasada przeciwdziałania tego rodzaju głupstwu.

Standard kodowania nie jest najlepszą obroną przed złym stylem programowania / niebezpiecznymi praktykami kodowania. Przegląd kodu to. Pomimo wielu lat automatyzacji, nie ma nic lepszego niż posiadanie nieco subiektywnego zestawu ludzkich oczu, które patrzą i oceniają fragment kodu.

David Hammen
źródło
+1 za świetną listę - to moja ulubiona odpowiedź. Szczególnie niedostępny kod, ostrzeżenia kompilatora, testy i dokumentacja. Ale nadal uważam, że tabulatory vs. spacje i wcięcia są ważne. Ktoś inny wspomniał o koszmarze, jaki wywołuje to przy różnicach w kontroli źródła.
GlenPeterson
Łatwym sposobem radzenia sobie z tabulatorami a spacjami jest wyłączenie tabulatorów w standardzie kodowania. Łatwym sposobem na wymuszenie tego jest posiadanie haka rejestrującego, który albo odrzuca rejestrację, albo przekształca tabulatory używane jako białe znaki w spacje. Automatyczna weryfikacja niektórych standardów kodowania, takich jak podczas nocnej kompilacji lub podczas meldowania się (najlepiej ze względu na niemal natychmiastową informację zwrotną) jest bardzo miłą funkcją. Co się stanie, jeśli rejestracja będzie dozwolona (lub wymuszona), a konwersja spowoduje bałagan? Na to też jest łatwa odpowiedź: przegląd kodu. Brzydki POS nie powinien przejść obok; nie powinien nawet być recenzowany.
David Hammen
Pamiętaj, że zasada „bez kart” (czego unikałam na mojej liście, ponieważ opinie są różne) nie oznacza, że ​​nie możesz używać kart podczas pisania kodu. Przyzwoity edytor może konwertować zakładki, w których pisze programista, na białe znaki. Jeśli twój edytor nie może tego zrobić, może pomyśl o przejściu na lepszy edytor.
David Hammen
Brak argumentów. Wystarczy powiedzieć, że wcięcie / formatowanie należy do listy. Karty mogą być odpowiednie dla plików HTML lub plików, które są pobierane lub analizowane w czasie wykonywania.
GlenPeterson
@GlenPeterson - Wcięcie / formatowanie znajduje się na mojej liście lub tuż przed moją listą: „IMO, standard kodowania powinien określać rozsądny zestaw akceptowalnych stylów wcięć, ale pozostawić to autorom pakietu.” I tak, są wyjątki od zasady „bez kart”. Na przykład pliki makefile.
David Hammen,
60

Standardy kodowania to nie tylko uprzywilejowane parametry indent- obejmują również konwencje nazewnictwa, konwencje komentowania oraz dużą liczbę możliwych zaleceń dotyczących idiomów, używania funkcji językowych itp.

Co więcej, nadal musisz gdzieś to wszystko udokumentować. I wreszcie, nie wszyscy będą chcieli używać IDE, które formatuje kod w ten sposób ...

nadchodząca burza
źródło
1
Dobra odpowiedź, poszerzyła moją wiedzę o dobre wyjaśnienie obejmujące rzeczy, o których nie myślałem. +1
SomeKittens
Mogą również obejmować takie kwestie, jak radzić sobie z kompatybilnością między platformami, co jest niezwykle ważne, jeśli nowy programista nie ma doświadczenia w pisaniu kodu między platformami.
Velociraptors
3
Jeśli uważasz, że ta odpowiedź jest dobra i odpowiada na twoje pytanie, po prostu zaznacz ją jako taką.
marktani
3
Nie wspominając już o tym, że masowe formatowanie może powodować bóle głowy, gdy rzucisz w to kolejny dobry standard: kontrolę źródła.
Matthew Scharley,
1
@MatthewScharley generalnie przepychasz zmieniony kod przez formatyzator, a następnie zatwierdzasz (po być może ostatnim uruchomieniu testowym, aby upewnić się, że formatyzator niczego nie zepsuł), więc tylko sformatowany kod trafia do maniaka repo
ratchet
13

Jeśli zastosujesz spójny styl w zespole, twój kod będzie łatwiejszy do odczytania. Kiedy Twój kod będzie łatwiejszy do odczytania, Twój zespół będzie bardziej produktywny. Będą bardziej produktywni, ponieważ nie muszą parsować mentalnie kodu i mogą się skupić na logice, a nie na składni podczas przeglądania i utrzymywania kodu.

Jeśli każda osoba pozwala IDE sformatować kod według własnego wyboru, masz jeden z dwóch problemów: albo musisz upewnić się, że zawsze konwertujesz go z powrotem do oryginalnego formatu podczas zapisywania, albo cierpisz z powodu tego, że twój diff będzie generował dużo hałasu, przez co trudniej jest zobaczyć, co zmieniło się w logice kodu.

Bryan Oakley
źródło
4
Różnice! Nie myślałem o tym.
SomeKittens
1
Tak, zdecydowanie nie pozwól wszystkim formatować kodu tak , jak mu się podoba, za każdym razem, gdy nad nim pracuje. To tylko pandemonium. Nawet zły standard jest lepszy. Biorąc pod uwagę wybór, staram się robić to, co jest najbardziej popularne w języku, aby nowi programiści mogli szybko przyspieszyć. Skorzystaj z Internetu, aby znaleźć standard w swoim języku.
GlenPeterson
5

Krótka odpowiedź: Tak, odzwierciedla jakość .

Co to jest i dlaczego tego potrzebujemy?

Standardy kodowania są bardzo ważnym elementem wysokiej jakości oprogramowania. Robią zwiększyć wydajność w procesie rozwoju, kod ułatwić, aby utrzymać i zachować kod jest przywiązany do jednej osoby lub zespołu. Spójność standardu kodowania odróżnia również przedwcześnie utworzony kod od dobrze wykonanej sztuki.

wprowadź opis zdjęcia tutaj

OK, każdy programista wie, że konwencje kodowania są dobre. Ale skąd powinny pochodzić standardy?

Jest to głównie podyktowane przez sprzedawcę, który jest właścicielem produktu. Każdy programista może wybierać spośród wielu branżowych standardów kodowania. Niektóre firmy Microsoft, Oracle i Sun Microsystems oferują wytyczne.

Czy są jakieś argumenty przemawiające za opracowaniem standardu kodowania (nie mamy takiego, ale chciałem go stworzyć)?

Tak, zaleca się stosowanie standardów branżowych. Jednak każdy standard kodowania jest specyficzny dla platformy programistycznej. Zatem standardy kodowania są głównie specyficzne dla języka. Na przykład Java ma inny standard niż .NET. Na przykład C # .NET używa tych standardów w tym dokumencie .

Wspólne standardy

Wspólne standardy nie są zależne od żadnego języka programowania. Oprócz standardów oferowanych przez dostawcę, zwanych także wspomnianymi standardami kodowania branżowego, istnieją różne notacje programowe, takie jak notacja węgierska lub CamelCase . Myślę, że standardy kodowania Microsoft .NET były początkowo oparte na notacjach CamelCase.

Standardy i wytyczne kodowania zespołu

Pomyśl, każdy zespół programistów powinien uzgodnić standardy kodowania, jak tylko projekt zostanie rozpoczęty. Wytyczne kodowania są zwykle tworzone przez kierownika zespołu lub głównego architekta firmy. Zwykle jest to otwarty dokument, który należy śledzić i ulepszać w razie potrzeby. Na przykład w naszej firmie mamy strony Wiki, na których ten dokument jest przesyłany i dostępny dla programistów firmy.

Jusubow
źródło
Myślę, że pytanie brzmi, dlaczego te rzeczy są ważne. Opisujesz, co obejmuje standard kodowania, ale pytanie brzmi, dlaczego jest potrzebne.
Bryan Oakley,
jeszcze nie skończyłem odpowiedzi
Yusubov
To While Notpowinno być całkowicie Do Until.
Ry-
2

Przyjmuję kontrowersyjną opinię i mówię „ nie”, że nie potrzebujesz standardu kodowania . Albo, jak mówisz, reguły są wytycznymi możliwymi do wyegzekwowania przez IDE, ogólnymi najlepszymi praktykami, których powinna przestrzegać każda firma w każdej firmie, lub są to indywidualne wezwania do oceny poszczególnych zespołów, które powinny być wykonywane przez więcej niż jedną osobę w zdolnym zespole poprzez programowanie par lub recenzje kodów.

Rzeczy takie jak Jak nazwać tę zmienną? Z jakich funkcji językowych powinniśmy korzystać? Czy powinniśmy unikać? Jakie testy są najlepsze? Najlepiej pozostawić je bez odpowiedzi, dopóki nie napotkamy wąsko zdefiniowanego problemu, nad którym teraz pracujemy .

Krystalizując się z tych drobnych decyzji, mogą powstać nieformalne standardy / wzorce w zespołach, oparte na skrzyżowaniu z bieżącą dziedziną problemów i wykorzystywanymi technologiami. Kodyfikacja tych oznacza, że ​​uważamy, że takie rzeczy jak standard nazewnictwa, odpowiedni podzbiór języka itp. Stosowane w tych projektach, oparte na setkach mikro decyzji i nieformalnie przyjęte przez te zespoły, powinny kierować każdym projektem do przodu.

Zasadniczo brzmi to jak świetna rzecz, ale w rzeczywistości staje się magnesem dla polityki. Z jakich narzędzi możemy zmusić wszystkich do korzystania? Czego chcę zmusić innych ludzi do unikania? Gdyby wszyscy zgodzili się na te pytania, nie potrzebowalibyśmy standardu. Zrobilibyśmy to. Z mojego doświadczenia wynika, że ​​standardy wynikają z chęci, aby jeden podzbiór programistów sprawował kontrolę nad innym podzbiorem. Zazwyczaj tego rodzaju polityka i technologiczne działania policyjne po prostu tłumią innowacje, a nie dostarczają wskazówek.

Jeśli chcesz prawdziwych wskazówek , zamiast czytać standardy z wieloma nieprzydatnymi zasadami, znajdź zdolnych członków swojego zespołu i zapytaj ich, co myślą. Czym zostali spaleni? Jak sugerują pisanie kodu? Otrzymasz wiele przydatnych odpowiedzi z dużą ilością cennego doświadczenia, aby je poprzeć. Zobaczysz wiele skrzyżowań opartych na wspólnych doświadczeniach. Zamiast monokultury wymuszonej przez standard, zobaczysz również wiele różnorodności, które mogą pomóc ci zobaczyć wiele prawidłowych sposobów rozwiązywania problemów.

A kiedy ktoś mówi ci, abyś nie robił czegoś z powodu reguły w „standardzie”, ale nie ma doświadczenia ani uzasadnionego uzasadnienia swojego roszczenia, zignoruj ​​je. Tutaj standard nikomu nie służył ani nie uczynił nikogo lepszym programistą.

Doug T.
źródło
Świetnie przeze mnie - jedna rzecz mniej do stracenia czasu, szczególnie jeśli wszyscy deweloperzy mają licencję Resharper i fxcop / stylecop działa na serwerze kompilacji.
StuartLC,
1
Normy powinny być i zwykle są kulminacją i konsolidacją doświadczeń ludzi. Ci „zdolni ludzie”, o których mówisz. Jeśli się mylą, rozwijaj je, ale odejście z ręki jest przepisem na anarchię.
Andrew
@Andrew Te doświadczenia mogą nie mieć zastosowania i mogą cię po prostu wiązać z wieloma pomysłami, które nie
Doug T.,
1
+1 za tłumienie innowacji, kontrolowanie podzbiorów, ogólne najlepsze praktyki i politykę. Edukuj, nie reguluj!
kirk.burleson
„Brak pisemnego standardu kodowania, poleganie na konwencji i proszenie o wskazówki” działa dość dobrze w małych zespołach (mniej niż, nie wiem, 50? 100?). Gdy masz tysiące ludzi, migrujących tam iz powrotem między projektami w bazie kodu, naprawdę pomaga mieć pisemny zestaw wytycznych dla kodu.
Vatine
1

Teraz, gdy samoloty komercyjne są przelotowo, masz nadzieję, że programy latające samolotem w oparciu o dane pilotów zadziałają. Kiedy programiści piszą taki kod, masz nadzieję, że będą przestrzegać ścisłego zestawu zasad, aby uniknąć często popełnianych błędów programistycznych. Jednym ze sposobów na to jest zastosowanie standardu kodowania.

Patrz: Proponowane standardy kodowania C i C ++ dla lotnictwa federalnego

Muszę powiedzieć więcej.

Uwaga: nie mogłem znaleźć rzeczywistego standardu z FAA online, ale go widziałem.

Guy Coder
źródło
To prototypowy zły kodowanie. Jest za długi, podnosi kwestie religijne, a co najważniejsze, działa wbrew współczesnemu programowaniu w C ++. Na przykład wyklucza POD (zwykłe stare dane), a jego zasady dotyczące wyjątków wahają się od złych do archaicznych. Źle: próba złapania std :: bad_alloc okazuje się bardzo złym pomysłem. Archaiczny: Idea Javy polegająca na określaniu wszystkich wyjątków, które mogą być zgłaszane i przechwytywaniu wszystkich wyjątków zgłaszanych przez wywoływane funkcje, po prostu nie działa w C ++. Znacznie lepiej jest napisać kod bezpieczny dla wyjątków w oparciu o koncepcje gwarancji wyjątków Davida Abrahamsa.
David Hammen
1

Dla mnie jest to kwestia dyscypliny, a dyscyplina zawsze pomaga, jest odzwierciedleniem jakości wykonywanej pracy.

Powiedziawszy to, stworzyłbym standard kodowania z uwzględnieniem IDE i / lub używanych narzędzi. Ponadto IDE powinno być skonfigurowane identycznie (np. IDE każdego programisty powinno używać wszystkich tabulatorów lub wszystkich białych znaków do wcięcia, a IDE każdego powinno mieć tę samą długość tabulatora) dla każdego programisty, aby każdy mógł łatwo przestrzegać standardu ...

Można również opracować i zastosować skrypty rejestrujące, które mogą w pewnym stopniu pomóc w przestrzeganiu standardów kodowania, np. Mogą naprawić wcięcie przed faktycznym zatwierdzeniem wpisanego pliku do systemu kontroli wersji.

Ciekawy
źródło
1

Standardy kodowania NIE mogą być ważniejsze! Jestem zapalonym użytkownikiem CakePHP i lubię przeglądać zestawy zmian z wersji na wersję, a programiści nie przestrzegają tam standardów.

Tak naprawdę byłem tak zdenerwowany różnicami w stylu, że musiałem napisać Krótkie zdanie na temat konwencji kodowania . Zaangażowanie nowych programistów w istniejący zespół już kosztuje dużo czasu i pieniędzy - wyobraź sobie, że możesz wprowadzić nowego programistę bez żadnych standardów ... nauka kodu byłaby zbyt niemożliwa.

endyourif
źródło