Czy standardy kodowania mogą być zbyt jednolite?

12

Czy istnieje coś takiego jak zbyt duża jednolitość? Tam, gdzie pracuję, mamy oczywiście standardy, w tym konwencje nazewnictwa, architektury, frameworki do wykorzystania itp. Jednak ostatnio pojawiło się wiele krytyki rzeczy, które uważałbym za bardziej stylowe.

Na przykład pisanie ifinstrukcji w wielu wierszach w stosunku do jednego wiersza przy użyciu ??operatora zerowania c # zamiast powiedzieć == null, że odstępy między wcięciami itp.

Wydaje mi się, że zaczyna to bardziej zależeć od osobistego stylu i nie musi być jednolite w zespole lub firmie. To, co jedna osoba myśli, czyta jaśniej, inne może nie. Czy ta „dodatkowa” jednolitość ma jakąś wartość?

programming-practices team coding-standards

— Przyjemny
źródło

2

Cześć Gratzy, Programmers.SE nie jest forum dyskusyjnym ; jesteśmy tutaj, aby rozwiązać prawdziwe problemy, z którymi możesz się spotkać. Czy masz rzeczywisty problem, który próbujesz rozwiązać? Jeśli tak, czy możesz przeredagować swoje pytanie, aby zachować konstruktywne odpowiedzi i uniknąć pułapek związanych z dyskusją?

1

@Gratzy, mówiąc inaczej, biorąc pod uwagę sytuację, w której osobiście się znajdujesz, jakie byłyby kryteria prawidłowej odpowiedzi?

2

@ Mark Trapp według FAQ są to kryteria pytania. Oczekuje się, że wszystkie subiektywne pytania będą konstruktywne. Jak to zdefiniujemy? Konstruktywne subiektywne pytania… 1. inspirują odpowiedzi wyjaśniające „dlaczego” i „jak”. 2. zwykle mają długie, a nie krótkie odpowiedzi. 3. mieć konstruktywny, uczciwy i bezstronny ton. 4. zapraszają do dzielenia się doświadczeniami nad opiniami. 5. nalegać, aby opinia została poparta faktami i odniesieniami. 6. są czymś więcej niż bezmyślną rozrywką społecznościową. Myślę, że moje pytanie dotyczy co najmniej pierwszych 4

— Gratzy

2

@Gratzy również z FAQ: „Powinieneś zadawać tylko praktyczne, możliwe do odpowiedzi pytania oparte na rzeczywistych problemach, z którymi się borykasz. Rozmowne, otwarte pytania zmniejszają użyteczność naszej strony i wypychają inne pytania z pierwszej strony”.

2

@ Mark Trapp Już określiłem kryteria dla akceptowalnej odpowiedzi i tak, ponieważ powiedziałem, że jest to faktyczny problem i szczerze mówiąc z zainteresowania pytaniem i odpowiedziami, które, jak twierdzą inni, są zgodne.

— Gratzy

16

Jednorodność nie stanowi problemu (jest dobra), ale może być sztywna lub nieelastyczna . Jeśli dążąc do jednolitości stajesz się dogmatyczny, szkoda wyrządzona zespołowi może być większa niż dobro wynikające z (być może) wynikowej jednolitości.

Najlepiej jest ustawić podstawowy styl najważniejszych rzeczy (standardy nazewnictwa i wielkich liter, wcięcia, nowe wiersze i rozmieszczenie nawiasów itp.), Ustawić zalecenia dotyczące mniej ważnych rzeczy (jeśli format instrukcji, inne białe znaki w nawiasach itp.) , a potem nie martw się o resztę.

— Nicole
źródło

1

Byłem tam

+1, powiedziałem, co miałem na myśli, ale lepiej!

— FrustratedWithFormsDesigner

@Pierre jest dlatego dlatego jesteś teraz niezależnym? :)

— Nicole

nie bardzo, ale spotkałem obsesyjnych ludzi na temat wytycznych. To przerażające, jak może być ekstremalne. Myślę, że całkiem dobrze zdefiniowałeś limit.

7

Kiedy potencjalnie dziesiątki ludzi pracują nad projektem przez lata jego życia, czasami staje się mylące, gdy musisz skakać ze stylów. Wyobraź sobie, że czytasz książkę, w której różne rozdziały są pisane przez różnych autorów, którzy tylko w pewnym stopniu zachowują styl pisania. Jest to możliwe, ale irytujące.

Większość IDE może egzekwować style w dzisiejszych czasach, więc jeśli to konieczne, możesz rozpowszechniać (jako część kodu źródłowego projektu) plik preferencji IDE, który określa wybrany styl kodowania i każe wszystkim go zainstalować i używać go do formatowania pisanego kodu . Założę się, że istnieją nawet sposoby na przeformatowanie / nadanie stylu kodowi przy odprawie (chociaż nie musiałem tego jeszcze badać).

— FrustratedWithFormsDesigner
źródło

Tak, prawdopodobnie mógłbyś gdzieś tam umieścić skrypt mrówki.

— Michael K

1

IntelliJ ma przynajmniej opcję sformatowania kodu przed zameldowaniem.

— Nicole,

3

Jednym z przypadków nadmiernej jednolitości, jaki widziałem, jest posiadanie jednego standardu, który dotyczy wszystkich języków programowania, niezależnie od stosowności:

Zniechęcanie gotonawet w językach takich jak C bez try... catch.
Używanie InitialCapsnazw (jak w Microsoft MFC i C #) w JavaScript, gdzie znajduje się standardowa biblioteka initialLowerCase.

— dan04
źródło

2

Nie wydaje mi się, żeby istniała zbyt duża jednolitość. Jednak często uważam, że ta specyfika jest zbyt szczegółowa. Korzyści płynące z umieszczenia nawiasów otwierających w osobnej linii są co najmniej wątpliwe i nie przeważają nad czasem spędzonym na kłótniach lub rozwiązywaniu problemów kosmetycznych w kodzie.

— JohnFx
źródło

2

@Tungano Nie mogłem się więcej zgodzić. Paradoks standardów kodowania polega na tym, że warto je mieć, ale nie warto się o nie kłócić.

— Charles E. Grant,

3

Nie rozumiem, jak zmuszanie konkretnego stylu do gardła programisty pomoże ci uniknąć tych argumentów. W rzeczywistości argumentowałbym, że dostosowanie programisty do stylu, którego nie lubią ZACHĘCA do tych argumentów, a przynajmniej do niechęci.

— JohnFx

1

@JohnFx, ponieważ większość programistów zdaje sobie sprawę, że spójność stylu ma znacznie większy wpływ na jakość kodu i łatwość konserwacji niż jakikolwiek konkretny wybór stylu. Z mojego doświadczenia wynika, że możesz szybko przeliczyć liczbę członków zespołu, zobaczyć, co ludzie lubią, a czego nie, i szybko dojść do konsensusu. Czasami ktoś będzie miał osobliwy błąd, a ty go pomieścisz, a potem ulegnie komuś innemu. Jeśli przez pięć minut będę prześladować zespół, dlaczego skrzynia wielbłądów jest zła, po prostu poddaję się i poddaję jako test mojej osobistej elastyczności.

— Charles E. Grant

1

Sądzę, że większość programistów MYŚLA, że spójność stylu ma tak duży wkład, ale tak naprawdę nie. Wydaje się, że tak powinno być, denerwujące jest patrzeć na kod, który nie pasuje do Twojego stylu zwierzaka, a przejście przez blok kodu „czyszczenie” w przypadku drobnych problemów kosmetycznych jest dobrym sposobem na odkładanie na później. Słuchaj, też byłem na tym modnym wagonie, dopóki nie zdałem sobie sprawy, że koncentruję się na złoceniu, a nie na dostawie.

— JohnFx,

1

Pracuję z kodem naszego niemieckiego zespołu, kilkoma projektami OSS i jakimś starożytnym kodem, który mamy, a także z naszymi bieżącymi rzeczami. Niektóre to C, niektóre C ++, niektóre C #. Więc muszę cały czas pracować z kilkoma różnymi stylami kodu. Kiedy to robisz, zdajesz sobie sprawę, jak małe są wytyczne dotyczące stylu, które są obowiązkowe w standardach. Jeśli mogę przejść z jednego projektu do drugiego, mogę obsłużyć kogoś umieszczającego {} w różnych miejscach. Dlatego uważam, że jedynym standardem wartym cholerności jest zasada z 1 zasadą: „spójność w ramach każdego projektu”.

— gbjbaanb

2

Miałem 2 argumenty za jednolitością:

Promowanie zbiorowej własności. Że ktoś może edytować kod innej osoby, nie obawiając się, że ta zmiana „zrani” dziecko. Rodzaj mentalności „wszyscy jesteśmy w tym razem”.
Łatwość dodawania do niego. Jeśli coś zostało już zrobione gdzie indziej, można to wziąć i ewentualnie ponownie wykorzystać. Niektóre konwencje mogą czasem ułatwić czytanie lub zmianę, więc jest to kolejna korzyść dla mojego umysłu.

— JB King
źródło