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

31

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

Walter
źródło
Wygląda na to, że występuje problem z linkiem (prawie 6-letnim) w tym pytaniu. Zgodnie ze stroną tutaj: 1code.codeplex.com strona główna Microsoft All-In-One Code Framework została zmigrowana do blogs.msdn.com/b/onecode . Nie sprawdzałem stron blogu MSDN, aby zobaczyć (czy lub), gdzie można uzyskać dostęp do standardu.
Kevin Fegan

Odpowiedzi:

39

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ę.
Paddyslacker
źródło
3
+1 za zacytowanie wuja Boba. i +1 (gdybym mógł) za sugestię NIE zapisywania ich.
Walter,
21
Dlaczego ich nie spisujesz?
Fishtoaster,
8
@Fishtoaster - Chodzi o to, że sam kod dokumentuje standard. Podobnie jak dokumentacja projektowa często nie jest utrzymywana ze względu na zmiany kodu, tak szczegółowe dokumenty standardów kodowania nie będą synchronizowane z kodem w miarę ewolucji standardów. Wybieramy reprezentatywne moduły i wykorzystujemy je jako wytyczne. Warto napisać krótki dokument wprowadzający (korzystamy z wiki i linku do faktycznego kodu), który pokazuje, gdzie znaleźć kod reprezentatywny.
Paddyslacker,
Ok, dokumenty kodowe-standard mają sens, jeśli zakładamy, że standard często się rozwija. Rodzi to pytanie, dlaczego Twój standard ewoluuje. Największym powodem, dla którego mogę wymyślić standard kodowania, jest spójność, której nie dostaniesz, jeśli standard ewoluuje.
Fishtoaster,
Jeśli standard należy do zespołu, zespół powinien być w stanie go rozwijać w miarę upływu czasu. Jeśli nie, skończysz ze standardem będącym pomysłem jednej osoby lub z archaicznymi sugestiami, które są obecnie dokumentowane w tym pytaniu: programmers.stackexchange.com/questions/1338/…
Paddyslacker
8

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.

Fishtoaster
źródło
5

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

sylvanaar
źródło
1
+1. Mój Objective-C nie wygląda na WSZYSTKO jak mój PHP.
Dan Ray
2

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.

George Marian
źródło
1

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.

Wizard79
źródło
3
Ojej, nigdy nawet nie rozważałem wielu języków ... to musi być trudne.
Walter
1

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.

Scott Dorman
źródło
1
Tak, rozumiem, że dokument, do którego się powołałem, jest specyficzny dla ram kodowania All-In-One, ale jest to geneza pytania, które wynikło z jego przeczytania.
Walter
1

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.

dwynne
źródło
1

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.

Tim Williscroft
źródło
1

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.

zaraz
źródło
1

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

jk.
źródło