Czy mój zespół powinien używać jakiegoś powszechnie uznanego standardu kodowania jako podstawy własnego?

Zespół R&D, w którym pracuję, postanowił przyjąć standard kodowania. Dopiero niedawno utworzyliśmy i mamy za mało własnego kodu i wspólnego czasu kodowania, aby oprzeć nasz dokument standardów / konwencji na tym, co opracowaliśmy organicznie w naszym zespole, i na dobrych przykładach z własnego kodu itp.

Teraz każdy z nas ma pewne doświadczenie z przeszłych miejsc pracy - chociaż nikt z nas nie jest w stanie powiedzieć: „przyjmijmy tutaj ten obszerny dokument, który moim zdaniem jest odpowiedni do rodzaju pracy, którą tutaj wykonujemy” (*). Ponadto niektórzy z nas (w tym ja) mają doświadczenie tylko z miejsc, w których nie ma oficjalnego standardu kodowania, lub piszą w różnych językach w innym otoczeniu (wysokociśnieniowe środowisko produkcyjne wydawane co tydzień, w przeciwieństwie do prac rozwojowych zorientowanych na badania)

Tak więc jedną z opcji, o których myślałem, jest zabranie stosunkowo znanego i cenionego dokumentu, wycinanie tego, na czym nam nie zależy / dbanie, oraz wprowadzanie modyfikacji w oparciu o nasze preferencje.

Czy to powszechna praktyka? Czy uważasz, że to dobry pomysł? Jeśli tak, to jaki byłby rozsądny „podstawowy” standard kodowania (nie mów mi, co jest najlepsze, nie chcę tutaj rozpoczynać konfliktu religijnego; po prostu wskaż to, co byłoby kompleksowe lub „neutralne”, aby na nim oprzeć .)

Uwagi:

• Oczekujemy współpracy z C, C ++, OpenCL, CUDA, Python.
• Jesteśmy zespołem 4 osób + menedżer, który ma wzrosnąć do około 5-6 w ciągu roku.
• W naszej firmie zespoły są prawie całkowicie autonomiczne i zwykle w ogóle nie wchodzą w interakcje (nawet przy użyciu kodów innych użytkowników - praca dotyczy zupełnie innych projektów); więc - nie trzeba brać pod uwagę całej firmy.
• Jeśli chodzi o narzędzia, w tej chwili wiemy, że będziemy używać Eclipse , więc jego formatator kodu będzie co najmniej jednym narzędziem. Ctrl + Shift + F od dawna jest moim przyjacielem
• Pisząc Javę, przyjąłem praktykę możliwie ścisłego przestrzegania Skutecznej Javy Blocha . Nie jest to do końca standard kodowania, ale można by nazwać go cegiełkami, cementem i zaprawą. Myślałem o włączeniu czegoś takiego do „miksu” (pamiętając, że nie robimy Java).
• Mam na myśli standardy kodowania w szerszym znaczeniu tego słowa, na przykład przyjęcie propozycji przedstawionych w odpowiedzi na to pytanie P.SE .
• Znalazłem dużą listę dokumentów standardów kodowania C ++ ; może powinienem wydobyć tę naszą linię bazową.
• (*) To nie do końca prawda, ale nie chcę komplikować tego pytania zbyt wieloma szczegółami.

Innymi słowy, pytasz, czy powinieneś szybko uruchomić standardy kodowania swojego zespołu, pożyczając znalezione standardy zewnętrzne. Nie brzmi to tak, jakby ktoś w zespole (jeszcze) miał bardzo mocne opinie na temat tego, jakie powinny być te standardy.

Odpowiedź jest jednoznaczna: tak.

Zewnętrzny standard nie ma nic lepszego. Spójrz na odpowiedzi w „ https://softwareengineering.stackexchange.com/q/84203/53019 ”, aby zobaczyć niektóre zalety posiadania standardu. Spójność i podstawa do zmiany są kluczowe z twojego punktu widzenia.

Zobacz także „ Postępowanie ze standardami kodowania w pracy (nie jestem szefem) ”, ponieważ dotyczy to dynamiki zespołu, którą Twój zespół musi wziąć pod uwagę przy wyborze standardów. Zespół musi posiadać własne standardy kodowania, aby każdy chętnie przestrzegał ograniczeń, jakie nakłada na sposób kodowania każdej osoby.

Powiązałeś z tym pytaniem, ale warto wskazać najważniejszą odpowiedź i skoncentrować się na zrozumieniu, dlaczego wymagania są spełnione. Jeśli użyjesz zewnętrznego standardu, Twojemu zespołowi trudno będzie zrozumieć podstawę wszystkich tych wymagań. Ale jeśli zaakceptujesz, że są tam po prostu dlatego, że Twój zespół potrzebował czegoś na początek, łatwo jest przejść do zmiany tego standardu zewnętrznego na coś, co działa lepiej dla Twojego zespołu.

Posiadanie dowolnego standardu pozwala wypełnić reguły formatowania, których będziesz używać z IDE (w twoim przypadku Eclipse). „ Zalety i wady wymuszonego formatowania kodu ” odnoszą korzyści dla wszystkich członków zespołu, ponieważ zapewniają spójność z kodem, nad którym pracują, i dają możliwość ponownego sformatowania fragmentów, które możesz pożyczyć z innych projektów. Dodatkową zaletą korzystania z zewnętrznego standardu jest to, że może on być już wstępnie wypełniony w części dotyczącej formatowania IDE.

Ktoś w zespole prawdopodobnie narzeka na określoną część standardu i będzie go winił za to, że użyłeś zewnętrznego standardu jako podstawy. Niech przeczytają:
- Nienawidzę jednego z naszych standardów kodowania i doprowadza mnie to do szaleństwa, jak go przetwarzać?
- Jak przezwyciężyć własne błędy w kodowaniu, gdy przekazuje się starszy kod?
a potem zdają sobie sprawę, że prawdopodobnie narzekaliby na coś w normie, bez względu na to, skąd to się wzięło. W całej liczbie zespołów, nad którymi pracowałem, nie widziałem jeszcze standardu, który wszyscy a) powszechnie lubili ib) zgadzali się z każdą częścią standardu. Odwołaj się do niektórych wczesnych linków, aby zobaczyć, jak poradzić sobie z tymi obawami.

W uzupełnieniu zapytałeś o „który” powinieneś użyć. W szczególności nie zamierzam na to odpowiedzieć, ponieważ każda odpowiedź jest potencjalnie sprzeczna z wojnami z płomieniami napędzanymi opinią. Możesz jednak spojrzeć na swoje IDE (Eclipse) i zobaczyć, jakie opcje zapewnia jako standardowa konfiguracja. Chciałbym również trochę przeszukać i sprawdzić, czy są jakieś projekty, które wtyczają się do twojego IDE i zapewniają dodatkowe opcje standardów do wyboru. Dobre czy złe, te standardy są już dla Ciebie wypełnione i mogą zaoszczędzić Twojemu zespołowi kawałka pracy przy konfigurowaniu go dla wszystkich.

Zacznę od pytona. Python ma wytyczne dotyczące kodowania, których przestrzega prawie każdy programista pythonowy. Są one częścią oficjalnej dokumentacji o nazwie PEP8 .

C / C ++ jest ogromnym bałaganem z powodów historycznych, ale ponieważ python nie jest, zalecam stosowanie się do konwencji nazewnictwa python w C / C ++ również ze względu na spójność.

Teraz w przypadku C ++ ważniejsze jest uzgodnienie wspólnych idiomów i upewnienie się, że wszyscy rozumieją rozsądny nowoczesny styl C ++ niż wszelkie wojny o konwencje nazewnictwa. Powinieneś zacząć od Standardów kodowania C ++ i z zasobów online, przeczytaj C ++ FAQ .

Nie można nawet omówić tego tematu bez rozróżnienia między standardem kodowania a standardem stylu kodowania .

Standard kodowania to zestaw reguł określających, jakich mechanizmów językowych wolno używać, których nie wolno używać i jak z nich korzystać. Innymi słowy, definiujesz podzbiór używanego języka i / lub nadzbiór, jeśli standard kodowania dotyczy niektórych niestandardowych rozszerzeń.

Standard stylu kodowania dotyczy tylko kwestii kosmetycznych: gdzie umieszczać nawiasy klamrowe i spacje, jak nazywać identyfikatory, jak umieszczać komentarze itp.

Te dwie różne rzeczy mogą znajdować się w tym samym dokumencie. Jednak najpoważniejsze standardy kodowania nie dotyczą stylu - nie polecam tych, które polecam poniżej. Najprawdopodobniej, ponieważ styl kodowania jest bardzo subiektywny i dlatego powoduje wiele tarcia, gdy opinie się kolidują.

W przypadku C / C ++ standardami kodowania o najlepszej reputacji są standardy MISRA . Są one zaprojektowane przede wszystkim do zastosowań krytycznych dla bezpieczeństwa / misji, ale ponieważ kluczem do zwiększenia bezpieczeństwa programów jest usuwanie i unikanie błędów, standardy MISRA mają zastosowanie do każdej gałęzi programowania, w której błędy nie są pożądane.

Standardy z CERT są również dość dobrze znane i bardziej nastawione na programowanie pulpitu i bezpieczeństwo oprogramowania (a nie bezpieczeństwo). CERT ma standardy dla C, C ++, Java i Perl, a standardy są bezpłatne.

Zacznę od spojrzenia na MISRA i CERT, a nie na losowy standard garażu znaleziony w Internecie.

Wykorzystanie istniejącego standardu jako podstawy własnego ma kilka zalet. Twój kod prawdopodobnie będzie bardziej podobny do kodu zewnętrznego, co ułatwi czytanie / integrację kodu. Ponadto, jeśli wybierzesz dobry standard, zostanie on zbadany przez ekspertów, którzy mieli uzasadnione powody, aby zdecydować się na ich szczególne zasady. Dopóki nikt w twoim zespole nie jest szczególnie przywiązany do normy, nie ma powodu, aby nie używać istniejącego standardu jako podstawy własnego.

Jeśli nie masz pewności, jakich standardów kodowania użyć, istnieje kilka oczywistych idealnych pierwszych wyborów. W żadnej szczególnej kolejności:
1. Który standard jest już obsługiwany przez twoje IDE. Prawdopodobnie można to skonfigurować.
2. Którykolwiek standard jest używany / zalecany przez autora twojego kompilatora.
3. Którykolwiek standard jest używany / zalecany przez autora twojego podstawowego frameworka (jeśli taki istnieje).
4. Którykolwiek standard jest używany / zalecany przez autora (-ów) / projektanta (-ów) twojego języka programowania.
5. Którykolwiek standard jest używany / zalecany przez bardzo dużą firmę.

Polecam osobę posiadającą specjalistyczną wiedzę techniczną na podstawie dowolnego standardu, którego używasz jako podstawy własnego standardu. Dobry standard często ma uzasadnienie dla każdej reguły, co pomoże ci w dostosowaniu standardu do twoich potrzeb.

Standard zwykle pomaga w komunikacji i konserwacji. Moim zdaniem powinno to podlegać pewnej dawce i przyjmowaniu, szczególnie w małych zespołach, i powinno ewoluować. Wywołanie ich wytycznymi może pomóc :-)

Inspiracje znajdziesz w wytycznych Google .

NIE, nie zawracałbym sobie głowy - myślę, że jedyną korzyścią byłoby przeniesienie twojego zespołu do miejsca, w którym również zastosowano te standardy, co nie jest tym, co chcesz osiągnąć :)

Standardy mają na celu jedynie ułatwienie współpracy, więc jeśli wiesz, że makro #define jest zawsze pisane wielkimi literami, to kiedy zobaczysz w kodzie duży identyfikator, będziesz miał dobry pomysł, że to makro. Podobnie inne konwencje nazewnictwa lub konwencje stylu przypominają ci, z czym masz do czynienia.

Uważam, że standardy takie jak lokalizacja i nazwa pliku są bardziej użyteczne1 niż te kodowe (w końcu kod ma wszystkie kształty i rozmiary, a ty wciąż musisz go czytać), nie znając pliku readme.txt w katalogu / bin / doc / debug / release / dokumenty to prawdziwy ból (tak kiepska ścieżka, ale to już inna historia).

Polecam, abyś sam tworzył własne standardy. W ten sposób otrzymujesz nie tylko te, które lubisz, ale także te, które są zdecydowanie odpowiednie dla ciebie, twojego zespołu i pracy, którą wykonujesz. Jeśli zdecydujesz, że nie obchodzi Cię, jak wygląda pętla while, lub że instrukcje case muszą być wcięte w określony sposób, to jesteś dobry. Jeśli zdecydujesz, że operatory ++ są zbanowane, to też dobrze. Cały twój wybór.

Musiałbyś ułatwić jej znalezienie i aktualizację, może wiki lub automatycznie wygenerowaną stronę internetową z opisu tekstowego, ale w przeciwnym razie - idź. Standardy mają mityczne podejście od niektórych osób, które są bardziej zainteresowane fanatycznym przestrzeganiem standardu niż pisaniem dobrego kodu, nie bądź do nich podobny - stwórz swój własny standard, który pomoże ci tam, gdzie go potrzebujesz.