Czy Twoja firma ma standard kodowania? [Zamknięte]

Niedawno zobaczyłem, że Microsoft wydał dokument standardów kodowania ( All-In-One Code Framework Coding Standards ) i to sprawiło, że pomyślałem ... Firma, dla której pracuję, w ogóle nie ma formalnych standardów kodowania. Jest tylko kilku programistów i byliśmy razem wystarczająco długo, aby ewoluować w podobne style i nigdy nie było problemu.

Czy firma, dla której pracujesz, ma udokumentowane standardy kodowania? Jeśli nie, dlaczego nie? Czy posiadanie standardu robi różnicę? Czy warto napisać standard od zera, czy też należy przyjąć inny standard jako swój własny (tj. Dostosować standardy Microsoft do swoich)?

Zespół musi mieć jeden standard kodowania dla każdego języka, aby uniknąć kilku problemów:

• Brak standardów może spowodować, że Twój kod będzie nieczytelny.
• Nieporozumienie w sprawie standardów może powodować wojny o rejestrację między deweloperami.
• Widzenie różnych standardów w tej samej klasie może być bardzo irytujące.

Jestem wielkim fanem tego, co wujek Bob ma do powiedzenia na temat standardów:

1. Niech ewoluują podczas pierwszych kilku iteracji.
2. Niech będą specyficzne dla zespołu, a nie dla firmy.
3. Nie zapisuj ich, jeśli możesz tego uniknąć. Zamiast tego niech kod będzie sposobem na uchwycenie standardów.
4. Nie ustanawiaj dobrego projektu. (np. nie mów ludziom, żeby nie używali goto)
5. Upewnij się, że wszyscy wiedzą, że standard dotyczy komunikacji i nic więcej.
6. Po kilku pierwszych iteracjach zbierz zespół razem, aby podjąć decyzję.

Myślę, że niezbędny jest standard kodowania, nawet jeśli wszystko, co mówi, to: „używamy wcięcia 3-spacji, a nawiasy otwarte przechodzą do następnej linii”. Kilka korzyści:

• To sprawia, że ​​czytanie całej bazy kodu jest znacznie łatwiejsze, ponieważ przełączanie stylów kodowania między plikami jest denerwujące.
• Ułatwia to odczytanie pojedynczego pliku, ponieważ każdy plik zaktualizowany przez dwóch programistów o sprzecznych stylach ostatecznie będzie miał tendencję do mieszania tych stylów. Czytanie pliku, który miesza tabulatory i spacje (i edytowanie go później), jest uciążliwe.
• Ułatwia nowym programistom korzystanie z dobrego stylu, jeśli istnieje wyraźny standard, a nie domniemany.
• Spójne konwencje nazewnictwa znacznie ułatwiają wyszukiwanie funkcji / zmiennych. Czy to ArraySort lub array_Sort lub sortTheArray lub doSortArray czy ...?

Jeśli chodzi o to, czy przyjąć istniejący standard, nie ma to tak naprawdę znaczenia - najważniejsza jest spójność. Jeśli twoi programiści mają tuzin różnych stylów, równie dobrze możesz wybrać istniejący, opublikowany. Jeśli wszyscy wyewoluowaliście w całkiem spójny styl, po prostu zapiszcie to i używajcie.

Nie zgadzam się z „jesteśmy sklepem X”, więc formatujemy kod we wszystkich językach w ten sam sposób.

Osobiście przekonałem się, że większość języków ma różne akceptowane style.

Naprawdę nie mogę znieść, gdy programiści C piszą kod Java z formatowaniem C. Nie tylko nie wygląda jak Java, ale oszukuje ich do myślenia, że ​​mogą korzystać z innych praktyk podobnych do C w Javie.

Uważam, że jeśli masz standard, powinien on być zgodny z językiem

Mój były pracodawca ma standard kodowania. Rozważam też formalne udokumentowanie jednego dla siebie.

Lub, jak sugerujesz, znalezienie przyzwoitego istniejącego standardu i jego modyfikacja / przyjęcie. W przypadku firmy z pewnością sugerowałbym, aby spojrzeli na istniejące standardy kodowania, ale stworzyli / zmodyfikowali je według własnych potrzeb. Niekoniecznie trzeba tworzyć je od zera, ale należy zachować ostrożność, aby upewnić się, że standard kodowania ma sens dla oprogramowania tworzonego przez firmę.

Tak, posiadanie standardu kodowania robi różnicę, ale to nie jest srebrna kula. Kod jest bardziej czytelny, ponieważ nie ma tak wielu sprzecznych stylów, a niektórych typowych błędów / pułapek można uniknąć. Nawet ze standardem będziesz mieć pewne różnice w stylach kodowania, ale ta zmienność zostanie zmniejszona. Celem nie jest uniknięcie wszystkich odmian lub przygotowanie się na każdą możliwą sytuację. Zbyt skomplikowany standard kodowania może być gorszy niż żaden.

Niestety nie. Tak więc każdy ma swój własny sposób używania spacji, wcięć itd., Wszystko mieszane (w ten sposób nie musimy nawet używać funkcji „obwiniania”, aby wiedzieć, kto jest autorem linii kodu!)

Ale, co najgorsze, ktoś pisze nazwy zmiennych i klas w języku włoskim, ktoś inny w języku angielskim ...

Zawsze dostosowuję swój styl do używanego języka, biblioteki i frameworka, aby kod źródłowy wyglądał jednolicie i jednoznacznie.

Należy pamiętać, że jest to dokument standardów kodowania, który jest specyficzny dla ramowego kodu All-In-One.

Pracowałem w różnych firmach, z których niektóre posiadały istniejący standard, a niektóre (większość) pomogły mi opracować ten standard. W większości przypadków, jeśli wykonujesz programowanie w oparciu o platformę .NET (a nawet jeśli nie jesteś, większość zasad nadal ma zastosowanie), powinieneś zapoznać się z Wytycznymi projektowania ram . Chociaż jest to specyficzne dla pisania publicznych interfejsów API, większość wytycznych stosuje się równie dobrze do każdego kodu.

Największe obawy związane ze standardami kodowymi polegają na tym, aby były stosunkowo proste i jednoznaczne. Chcesz, aby programiści mogli zinternalizować przedstawione wytyczne, więc przekazanie im dokumentu na ponad 50 stron jest bezużyteczne. Nadal możesz utworzyć ten dokument, jeśli chcesz podać tło, przykłady itp., Ale potrzebujesz również czegoś, co sprowadza się do zestawu wypunktowanych wytycznych. Standard kodowania musi również być elastycznym, żywym dokumentem, który musi się zmieniać wraz ze zmianami technologii.

Dyskusje o kodowaniu standardowym sprowadzają się do tego:

• Tak, potrzebujesz ich, spójność i czysty kod to podstawa dobrego rozwoju.
• To, czym są prawie nie ma znaczenia, o ile wszyscy przestrzegają tych samych standardów.
• Nie pisz własnego, skończysz w niekończącej się i bolesnej dyskusji. Istnieje wiele popularnych.
• Korzystanie ze standardów publicznych (takich jak MSDN ) daje agnostyczną stronę trzecią, z którą nie można się kłócić. Jeśli chcesz się z nimi kłócić, zapoznaj się z punktem 2.

Jeśli tworzysz w C # w Visual Studio, StyleCop jest srebrną kulą. Jeśli używasz również ReSharper, wtyczka StyleCop dla ReSharper jest po prostu niesamowita.

Jesteśmy sklepem blub, więc używamy konwencji programowania blub.

Teraz Paul Graham i przyjaciele są znacznie mądrzejsi od nas, ale my, programiści blub, wszyscy możemy czytać siebie nawzajem blub, w rzeczywistości każdy programista blub może odczytać nasz kod blub.

W rzeczywistości, z powodu projektu blub, każdy programista blub może odczytać dowolny pojedynczy plik blub i zrozumieć go, ponieważ blub nie ma systemu makr.

Jeśli programujemy powiedzmy C lub C ++ (wszyscy jesteśmy wielojęzyczni, chociaż programujemy w blubie), używamy głównie stylu blub dla nowego kodu lub dla rzeczy open source, standardu projektu, nad którym pracujemy.

Potrzebujesz jednego standardu. Widziałem różne standardy w różnych zakątkach aplikacji, które miały różne potencjalne szanse, że wszyscy chcieli to zrobić „po swojemu”. Być może pojęcie „standardu” zostało źle zrozumiane. Bardzo szalony. A najgorsze standardy generuje jedna osoba. Nie ma znaczenia, kim jest ta osoba, jeśli tylko jedna osoba opracuje standard, prawie na pewno jest zły.

Może pomagać ludziom, może też naprawdę pomagać z narzędziami:

Jeśli chcesz mieć możliwość korzystania z dowolnego rodzaju automatycznego formatowania kodu, naprawdę musisz ustandaryzować reguły, których będzie używał, w przeciwnym razie będziesz ciągle otrzymywał wiele bezsensownych zmian formatowania zaśmiecających twoje różnice.

Domyślne zestawy reguł dla narzędzi analizy statycznej mogą sprawdzać konkretny styl nazewnictwa, i prawdopodobnie łatwiej jest się do tego dostosować, a następnie napisać kilka nowych reguł. (chyba że zamierzasz całkowicie wyłączyć regułę)

wreszcie dobrze jest ujednolicić wszystko, co wymaga konsultacji z kimś spoza zespołu. tzn. prawdopodobnie potrzebujesz standardowej informacji o prawach autorskich w nagłówkach, ponieważ nie chcesz uruchamiać każdego nowego pliku, który piszesz poza zespołem prawnym Twojej firmy, a na pewno chcesz uzyskać nazwy dowolnego publicznego interfejsu API za pierwszym razem