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

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.

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.

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.

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.

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.

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.

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.

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]

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.

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.