Jak ważne są wytyczne dotyczące formatowania kodu? [Zamknięte]

18

Standardy kodowania są powszechne w każdej organizacji zajmującej się programowaniem oprogramowania, ale jak ważne są ich przestrzeganie? Potrafię zrozumieć potrzebę pewnej spójności, ale kiedy mam do czynienia z prostymi rzeczami, takimi jak położenie nawiasów, długość linii itp., Nie jestem pewien, czy nadmiernie surowe standardy mają duży wpływ na rozwój oprogramowania.

Czy nie jest ważniejsze, aby Twój kod był czytelny, czy nie jest zgodny ze zdefiniowanym standardem? Wygląda na to, że są bardziej jak ... wytyczne.

derekerdmann
źródło

Odpowiedzi:

12

Proszenie wszystkich o przestrzeganie w 100% tych samych standardowych wytycznych dotyczących formatowania kodu jest jak proszenie wszystkich o osobną współpracę przy pisaniu 100-stronicowego papieru o tym samym stylu pisania.

Mam nadzieję, że każdy napisze artykuł po angielsku (lub w tym samym języku), ale widoczne będą różne style. Niektórzy dobrze to piszą, inni nie. Niektórzy użyją skurczów, inni przeliterują słowa w pełni (przykład: to jest verus). Itp.

Myślę, że poruszyłeś najważniejsze kwestie:

  1. To jest wskazówka
  2. Czytelność

Jeśli chcesz, aby kod był zgodny z tym samym formatowaniem, tak jak papier w tym samym stylu pisania, musisz go edytować i poprawić. Kod będzie musiał zostać wyczyszczony, sprawdzony, ponownie uwzględniony itp.

Nigdy nie byłem w sklepie, w którym byłem całkowicie zadowolony ze stylu kodowania lub formatowania innego dewelopera (minimalnie, ponieważ nie jest dokładnie taki jak mój). Ale będę zadowolony, jeśli będę mógł to przeczytać / zrozumieć i jeśli będzie to spójne. Cała reszta to cukier syntaktyczny.

Tak więc, aby odpowiedzieć na twoje pytanie: trochę ważne, ale na pewno nie koniec świata, jeśli nie.

gąbka
źródło
3
Szczególnie # 2: Czytelność. Czasami określony fragment kodu można uczynić bardziej czytelnym poprzez odstępstwo od wytycznych.
Bart van Heukelom,
Dzięki dzisiejszym IDE możesz zbliżyć się do 100%, jeśli sformatujesz kod w oparciu o szablon przy każdej operacji składowania. Eclipse robi to całkiem nieźle.
Markus,
1
@ Markus to działa, dopóki ktoś nie chce użyć innego IDE lub edytora. Wolę robić to w haczyku przed zatwierdzeniem, aby dać więcej swobody twórcom.
Gustav Karlsson,
Dobry punkt @GustavKarlsson, w ten sposób scentralizujesz formatowanie i utworzysz pojedynczy punkt zmiany na wypadek zmiany „standardowej”. W celu obejścia tego problemu (przy większym wysiłku) zawsze można napisać dodatkowy szablon dla nowego IDE.
Markus
5

Jeśli chodzi o standardy formatowania, podążam za tym, co robią wszyscy inni. Jeśli używają PascalCase do wszystkiego, to używam PascalCase. Jeśli używają _camelCase, to używam _camelCase. Dlaczego? Ponieważ ogranicza to ilość przeprowadzanych przeze mnie formatowań i ogranicza to, co inni muszą zrobić, aby „wyglądać dobrze”. Standardy formatowania są zwykle po to, aby ułatwić wszystkim.

TheLQ
źródło
5

W mojej obecnej pracy jednym z moich pierwszych zadań było opracowanie standardu kodowania dla naszej grupy programistów.

Mój pierwszy wysiłek miał około sześćdziesięciu stron (zawierał wiele Wytycznych ramowych od Microsoft). Poproszono mnie, aby to zmniejszyć, a mój następny wysiłek trwał dziesięć stron, wykorzystując pomysły z wielu dobrych źródeł. Zostałem poproszony o ponowne przeanalizowanie go i myślę, że w końcu udało mi się zredukować go do trzech lub czterech stron.

Nigdy nie został przyjęty.

Dlaczego? Ponieważ pracuję z wieloma naprawdę inteligentnymi ludźmi, którzy instynktownie przestrzegają rozsądnego standardu kodowania.

Ze swojej strony postępuję zgodnie z ogólnie przyjętymi wytycznymi firmy Microsoft i emuluję powszechnie stosowane style innych (JavaScript i jQuery są formatowane inaczej niż C #, mimo że oba są językami nawiasów klamrowych). Od czasu do czasu łamię też reguły, dzięki czemu kod będzie bardziej czytelny.

Robert Harvey
źródło
Dlaczego napisałeś swój własny standard kodowania, skoro tak wiele istnieje i są w rzeczywistości standardem dla używanego języka / frameworka?
Florian Margaine,
2
Nigdy nie został przyjęty - tadaa, i było takie stwierdzenie, którego szukałem podczas przeglądania odpowiedzi. O to właśnie chodzi: im więcej ludzi i im większa złożoność i arbitralność przepisów, tym mniejsze prawdopodobieństwo, że kiedykolwiek zostaną one przyjęte przez większość członków zespołu. O ile nie jest to w jakiś sposób wymuszone, tak jak w przypadku Visual Studio lub języka Go, programiści zwykle podążają za swoimi umysłami. Od prawie 10 lat czekam na IDE, które oddziela zawartość kodu od stylizacji kodu.
JensG
2

Jeśli używasz i IDE, które wykonują to za Ciebie (na przykład Visual Studio), pozwól IDE zrobić to samo, a cokolwiek wydaje się być trudne do spojrzenia na ciebie, modyfikuj tak długo, jak długo pozwalasz IDE to zrobić lub następna osoba, która automatycznie formatuje, i tak go zabije.

To, co jest najbardziej czytelne dla jednej osoby, nie będzie dla wszystkich ludzi.

Jeśli nie używasz tego rodzaju IDE, zdobądź je. Nawet myślenie o tym przez ponad 10 minut jest marnotrawstwem zasobów IMHO.

Rachunek
źródło
4
Muszę się nie zgodzić. Nic bardziej irytującego niż IDE, które samodzielnie zmienia formatowanie. Dlaczego powinienem pozwalać na modyfikowanie mojego kodu bez mojej zgody? To odcina przyzwoitą kontrolę, którą lubię mieć nad swoją pracą.
derekerdmann,
Bill, mówisz o konwencjach nazewnictwa typu przeciągnij i upuść, które generuje IDE, takich jak TextBox01? Czy masz na myśli wtyczkę Visual Studio, taką jak Resharper?
gąbka
derek - tak, to denerwujące, ale czas, który mnie oszczędza, nie muszę na to zwracać uwagi, 90% czasu jest warte 10% czasu, w którym muszę się zmagać.
Bill
słońce - miałem na myśli formatowanie tylko w tym przypadku. Byłbym w porządku z domyślnymi nazwami kontrolnymi przy upuszczaniu tylko wtedy, gdy byłoby niezwykle oczywiste, co się dzieje. w wielu postaciach, które rozpadają się po drugiej kontroli. Nie jestem wielkim fanem resharperów, ale kiedy go używam, nie próbuję też poprawiać tego, co generuje. Nie walcz ze swoim zestawem narzędzi, kiedy nie musisz.
Bill
W tym samym zespole może znajdować się wiele IDE - np. Eclipse i IDEA dla Java. Ustawienie formatowania kodu w postaci plików konfiguracyjnych wymagałoby trochę wysiłku - ale warto.
talonx,
1

Myślę, że pomoc w szybkim zrozumieniu kodu jest niewymieniona. Im bardziej formatowanie kodu jest podobne w projekcie i dla wszystkich programistów, tym łatwiej (i bardziej podświadomie) będziesz w stanie pracować z kodem.

Miałem młodszych programistów, którzy przyszli do mnie po tym, jak próbowałem radzić sobie nawet z prostymi błędami przez dłuższy czas. Po kilku minutach zastosowania z nimi naszego formatu kodu szybko zauważyli błąd, który wcześniej przeoczyli.

Chociaż czytelność jest zdecydowanie ważna. Jeśli standardy formatu kodu są dobrze przemyślane i właściwie stosowane, może się okazać, że możesz wyjść poza samo czytanie kodu i jeszcze szybsze zrozumienie kodu.

Jednym z zestawów wskazówek, których używam podczas opracowywania lub aktualizacji naszych formatów kodowania, są Zasady grupowania Gestalt - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

Jako bezpośredni wynik / przykład nasze formatowanie kodu wymaga, aby każdy kod bloku (if, switch itp.) Miał otwarte nawiasy klamrowe w następnym wierszu, tak aby pasowały do ​​nawiasu zamykającego:

if(true)
{
}

Rozumując, że zgodnie z zasadą symetrii twój umysł zobaczy otwierające i zamykające nawiasy klamrowe i szybciej będzie mógł naturalnie postrzegać blok kodu.

Chris
źródło
After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before.Nie dzieje się tak, ponieważ Twój format kodu pomógł im zobaczyć błąd. Wynika to z faktu, że zadanie ponownego sformatowania kodu zmusiło ich do uważnego przyjrzenia się kodowi, przed którym właśnie przeglądali.
Brandin
1

Bez względu na to, jakiego języka lub narzędzia używasz, wymyśl coś. Skonfiguruj IDE i sprawdź w pliku konfiguracyjnym.

Kiedy ktoś obejrzy projekt, użyje tych samych stylów formatowania. Nie ma znaczenia, jaki jest styl, tylko że jest spójny. Mam własne preferencje dotyczące spacji w. Tabulatorów i linii, w których nawiasy klamrowe się poruszają. Ale bardziej niż moje własne preferencje, zależy mi tylko na tym, aby dany plik kodu źródłowego zgadzał się ze sobą. To sprawia, że ​​jest o wiele bardziej czytelny niż bycie miszmaszem wynikającym z wojny formatu.


źródło
0

Najgorszą rzeczą, jaką do tej pory spotkałem, jest brak standardów kodowania. I zabronione jest, aby jakiś blok kodu był bardziej czytelny, ponieważ łamie on narzędzia diff ... Ponieważ używamy łat do wprowadzania zmian (zmiana / żądanie naprawy błędu -> naprawa / zmiana -> łatka -> łatka zastosowana przez „zaufaną” osobę) -> commit) możesz uzyskać całkiem zabawny wygląd kodu źródłowego (z punktu widzenia czytelności). Przynajmniej nie mamy nikogo, kto użyłby dwuliterowych zmiennych (-.

[rant] Najśmieszniejsze jest to, że wszyscy zgadzają się, że musimy to zmienić. Było nawet kilka prób sformatowania (zautomatyzowanych przy zatwierdzaniu), ale ponieważ brakuje jednej niewielkiej opcji formatowania bitów - wszystko się udało. Sight ... [/ rant]

Audrius
źródło
0

Wytyczne pomagają poprawić jakość kodu:

  • z punktu widzenia pisarza: wiele zasad ma na celu ograniczenie wprowadzania błędów. Na przykład reguła stwierdzające, że if()albo for(;;)konstrukcje muszą być przestrzegane przez blok, a nie pojedynczej instrukcji, sprawia, że początkowy zamiar koder wyraźny i pomaga utrzymać ten następny koderów.

  • z punktu widzenia czytelnika: kod zgodny z ustalonymi wytycznymi jest sprawdzany bardziej skutecznie niż kod z różnymi stylami. Recenzent wie lepiej przy mniejszym wysiłku, gdzie szukać możliwych błędów.

mouviciel
źródło
0

Nie ma uniwersalnego standardu określającego, co zespół powinien robić, a czego nie. Niektóre zespoły muszą przestrzegać ścisłych wytycznych, niektóre nie.

Chodzi o to, że powinieneś współpracować jako zespół i zdecydować, co jest najlepsze dla twojego zespołu . Kod powinien być łatwy do odczytania, ponieważ jest odczytywany o rząd wielkości więcej razy niż jest napisany. Jeśli Twój zespół potrzebuje wskazówek, aby stworzyć czytelny kod, trzymaj się standardu kodowania. Jeśli nie, nie rób.

Biorąc to wszystko pod uwagę, myślę, że większość zespołów skorzystałaby na uzgodnieniu standardowego sposobu nazywania zmiennych, funkcji i klas, nawiasów klamrowych i tak dalej. Jeśli zespół nie może się zgodzić na coś tak prostego, jak mogą spodziewać się spotkania i podjęcia naprawdę ważnych decyzji? Ponadto Twój zespół nie będzie składał się z tych samych osób na zawsze - ludzie odchodzą, zatrudniani są nowi ludzie. Im łatwiej nowi ludzie mogą przeglądać bazę kodów, tym szybciej mogą przyczynić się do zespołu bez obniżania jakości kodu.

Bryan Oakley
źródło