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ć)?

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.

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

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.

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.

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.

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

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.

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.

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.