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)?
coding
coding-standards
Walter
źródło
źródło
Odpowiedzi:
Zespół musi mieć jeden standard kodowania dla każdego języka, aby uniknąć kilku problemów:
Jestem wielkim fanem tego, co wujek Bob ma do powiedzenia na temat standardów:
źródło
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:
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.
źródło
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
źródło
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.
źródło
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.
źródło
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.
źródło
Dyskusje o kodowaniu standardowym sprowadzają się do tego:
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.
źródło
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.
źródło
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.
źródło
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
źródło