Czy narzucenie tego samego formatu kodu wszystkim programistom to dobry pomysł?

88

Rozważamy wprowadzenie jednego standardowego formatu kodu w naszym projekcie (format automatyczny z działaniami zapisu w Eclipse). Powodem jest to, że obecnie istnieje duża różnica w formatach kodu używanych przez kilku (> 10) programistów, co utrudnia jednemu programistowi pracę nad kodem innego programisty. Ten sam plik Java czasami używa 3 różnych formatów.

Uważam więc, że korzyść jest wyraźna (czytelność => wydajność), ale czy narzucenie tego byłoby dobrym pomysłem? A jeśli nie, to dlaczego?

AKTUALIZACJA
Wszyscy korzystamy z Eclipse i wszyscy znają plan. Format jest już używany przez większość, ale nie jest egzekwowany, ponieważ niektórzy wolą trzymać się własnego formatu kodu. Z powyższych powodów niektórzy woleliby to egzekwować.

Stijn Geukens
źródło
2
czy wszyscy twoi programiści używają Eclipse? rozmawiałeś z nimi o tym planie? Nie wiedząc o tym, trudno jest odpowiedzieć na twoje pytanie, trzeba by było zgadnąć za dużo
komiks
9
Czy faktycznie utrudnia to jednemu programistowi pracę nad kodem innego, czy też programiści mają alergię na czytanie nieco innego kodu?
Joris Timmermans,
27
Gdy używasz systemu kontroli kodu źródłowego (takiego jak svn), upewnij się , że zmiany w formatowaniu kodu są zatwierdzane oddzielnie od zmian semantycznych - w przeciwnym razie trudno będzie znaleźć te zmiany semantyczne.
Martin Schröder
4
Nie zgadzam się z Martinem tutaj, no cóż. Moją ogólną zasadą jest to, że jeśli dokonujesz zmiany logicznej / semantycznej, możesz zmienić format linii, które zmieniłeś, w przeciwnym razie nie możesz zmienić formatu linii tylko dlatego, że ci się podoba. Nie blokuj dziennika kontroli wersji drobnymi zmianami formatowania.
Benedykt
3
Z drugiej strony: jeśli wszyscy używają tego samego formatu, tylko pierwszy program do formatowania wszystkiego zostanie z nim zatkany. Wszystko inne dotknie wprowadzonych lokalnych zmian, co moim zdaniem jest dopuszczalne.
Jeroen Vannevel

Odpowiedzi:

107

Obecnie pracuję w miejscu, w którym wymuszany jest standardowy format kodu, a kod jest automatycznie formatowany podczas zapisywania pliku, tak jak masz zamiar to zrobić. Jako nowy członek firmy odkryłem, że wspólne reguły formatowania dały mi ciepłe i niewyraźne wrażenie, że „ci faceci wiedzą, co robią”, więc nie mogłem być szczęśliwszy. ;) Jako powiązana uwaga dodatkowa, wraz ze wspólnymi regułami formatowania wymuszamy również pewne, raczej ścisłe ustawienia ostrzeżeń kompilatora w środowisku Eclipse, przy czym większość z nich jest ustawiona na Błąd, wiele na Ostrzeżenie, a prawie żadna na Ignoruj.

Powiedziałbym, że istnieją dwa główne powody narzucenia jednego formatu kodu w projekcie. Po pierwsze, dotyczy kontroli wersji: dzięki każdemu identycznemu formatowaniu kodu wszystkie zmiany w plikach mają znaczenie. Nie trzeba już dodawać ani usuwać spacji tu czy tam, nie mówiąc już o przeformatowaniu całego pliku jako „efekt uboczny” faktycznej zmiany tylko jednej lub dwóch linii.

Drugim powodem jest to, że w pewien sposób usuwa ego programistów z równania. Gdy wszyscy formatują kod w ten sam sposób, nie można już tak łatwo powiedzieć, kto co napisał. Kod staje się bardziej anonimowy i jest wspólną własnością, więc nikt nie musi czuć się zaniepokojony zmianą kodu „kogoś innego”.

Są to główne powody, są też inne. Pocieszające jest dla mnie to, że nie muszę się martwić myśleniem o formatowaniu kodu, ponieważ Eclipse zrobi to dla mnie automatycznie po zapisaniu. Jest beztroski, podobnie jak pisanie dokumentów za pomocą LaTeX: jest później formatowany i nie musisz się tym martwić podczas pisania. Pracowałem także przy projektach, w których każdy miał swój własny styl. Następnie musisz pomyśleć o głupich i pozbawionych znaczenia kwestiach, takich jak na przykład modyfikowanie czyjegoś kodu we własnym stylu, czy też próba naśladowania jego stylu.

Jedynym argumentem przeciwko powszechnym ustawieniom formatowania kodu, o którym mogę pomyśleć w twoim przypadku, jest to, że najwyraźniej jest to już trwający projekt, więc spowoduje wiele niepotrzebnych zmian we wszystkich plikach, psując rzeczywiste historie plików. Najlepszym scenariuszem jest rozpoczęcie egzekwowania ustawień od samego początku projektu.

Zero jeden
źródło
20
+100 za usunięcie ego programistów (i własności) z równania. „Roszczenia” programistów do części kodu nie przyczyniają się do produktywności, ponieważ utrudniają dzielenie się wiedzą i oznaczają, że istnieje sygnał, że nie wszyscy programiści mogą pracować na tym samym fragmencie kodu.
Marco
Trudno było zdecydować, którą odpowiedź zaakceptować, ale uznałem, że jest to najlepsza argumentacja, która najlepiej odpowiada na pytanie.
Stijn Geukens
„oznacza, że ​​podany jest sygnał, że nie wszyscy programiści mogliby pracować na tym samym fragmencie kodu”: Cóż, ale tak naprawdę jest to coś, co możesz chcieć mieć: dopóki nie znasz wystarczająco dobrze fragmentu kodu, powinieneś nie pracuj nad nim / modyfikuj go. Zbyt wiele własności kodu współdzielonego może prowadzić do tego, że każdy będzie pracował nad całą bazą kodu i nikt tak naprawdę nie opanuje żadnej jego części.
Giorgio
Miałbym dużo więcej czasu na tego typu rzeczy, gdyby kod był automatycznie formatowany do mojego stylu przy ładowaniu. Kiedy Roslyn wyląduje na C #, mam nadzieję, że zobaczę wszystkie ładowanie, zapisywanie, wersjonowanie i tak dalej na AST zamiast tekstu.
Mark Rendle,
Ostrzejsze ostrzeżenia i błędy to dobra rzecz.
Christophe Roussy,
37

Każdy profesjonalny twórca oprogramowania będzie wolał przyjąć (dobry) standard, niż wdawać się w ewangeliczne wojny ponad styl, z tych samych powodów, które przedstawiłeś.

Wielu programistów prowadzi wojny ewangeliczne ......

W zależności od pozycji w zespole i dynamiki zespołu możesz zdecydować, że wygrana wojna nie jest możliwa. W takim przypadku najlepiej nie zaczynać ...

mattnz
źródło
Tx, wiem dokładnie, co masz na myśli
Stijn Geukens
15
Nieprofesjonalne jest toczenie wojen o formatowanie kodu. Profesjonalny programista wykona zadania równie dobrze, bez względu na to, czy ich kod czyta „ if( foo )” czy „ if (foo)”. Jeśli naprawdę chcesz sprzedać komuś taką zmianę, powinieneś odwołać się do faktu, że są to profesjonaliści. Nie mogą oddzwonić, albo zachowają się analnie. Jeśli ktoś i tak to zrobi, mam nadzieję, że dla ciebie wkrótce znajdzie nową pracę.
ZeroOne
7
Profesjonalny programista pisałby również czytelny kod i byłby w stanie dość łatwo odczytać kod innych profesjonalnych programistów, eliminując w ten sposób potrzebę opracowania obszernego standardu. Martwiłbym się, że tutaj „standard” jest złym rozwiązaniem niewłaściwego problemu (nie naprawiasz niechlujnych programistów za pomocą standardu kodowania).
Joris Timmermans,
2
Najlepszym sposobem na ominięcie większości świętych wojen jest zaakceptowanie domyślnych ustawień językowych tam, gdzie to możliwe. Tak, co oznacza, że ​​twój styl kodowania będzie różny w różnych językach (np. Kod C # będzie miał {w osobnych wierszach, java będzie je miał w poprzednim wierszu, a to, co pascalCased lub camelCased będzie się różnić); ale każde źródło poszczególnych języków będzie wyglądało „normalnie”, gdy zaangażujesz nowych programistów w projekcie.
Dan Neely,
1
@ruakh Spójrz na próbki kodu MSDN C #, zobacz, jak Visual Studio formatuje domyślnie C #: {ma własną linię. Powtórz ćwiczenie dla Java w dokumentacji Oracle i ustawieniach domyślnych Eclipse podczas ponownego formatowania kodu: {znajduje się w powyższej linii.
Dan Neely,
30

Tak, dobrze jest mieć jeden styl formatu dla wszystkich programistów.

Zaprojektuj formaty stylu kodu i zaimportuj je do wszystkich programistów.

Pomoże to, gdy będziemy mergingkodować do systemu kontroli wersji.

NPKR
źródło
5
+1 za wzmiankę o narzędziach do scalania i porównywania. Naprawdę trudno jest dostrzec różnice między dwiema wersjami bazy kodu, gdy formatowanie nie jest spójne między programistami.
pgras
1
+1, zdecydowanie popieram argument systemu kontroli wersji. (ale dzieje się tak głównie z powodu zasad wcięcia. Rzeczy takie jak konwencje nazewnictwa nie mają tak dużego wpływu)
BiAiB
Konwencje nazewnictwa pomagają, gdy musisz dowiedzieć się, jak nazywa się metoda, o której wiesz, że istnieje w klasie.
Dan Neely
1
@Giorgio Są rzeczywiście programiści, którzy to robią. Podczas mieszania z innymi zmianami (np. Krytyczne poprawki błędów). Niektóre rzeczy są wysyłane, aby nas wypróbować…
Donal Fellows
1
@Donal Fellows: Masz rację. Kieruję się zasadą, że każdy znak, który wpisujesz w pliku źródłowym, to (1) potencjalny błąd (2) wprowadza zmianę, która utrudnia późniejsze rozpoznanie kodu. Dlatego moim zdaniem każda zmiana powinna być jak najmniejsza. Ale tak, są programiści, którzy zmieniają kod bez zastanowienia. Zastanawiam się, czy automatyczne formatowanie kodu może rozwiązać problem. Wolałbym być właścicielem kodu (patrz np. Punkt 7 na paulgraham.com/head.html ).
Giorgio
16

Co próbujesz zyskać, jak bardzo będziesz utrzymywał anal w egzekwowaniu tego (a na poziomie szczegółowości zostaną określone twoje „reguły”), czy spróbujesz wymusić to na kodzie napisanym w różnych językach, czy spróbujesz wymusić to z mocą wsteczną na istniejącym kodzie?

  1. wspólny wygląd i działanie kodu może rzeczywiście pomóc w zwiększeniu czytelności kodu, ale może również pogorszyć sytuację, jeśli jest to zły wygląd i działanie. _hUngarian_lpfstr notacja stanowi doskonały przykład :)
  2. Widziałem „standardy kodu” wymuszające liczbę spacji między blokami komentarzy, alfabetyczną kolejność nazw metod i inne bzdury. Nie rób tego
  3. Różne języki mają różne standardy, do których ludzie są przyzwyczajeni. Niektórzy nawet nakazują te standardy (uważają, że Python, Cobol, Visual Studio automatycznie narzuca konwencje stężeń w stylu C ++, podczas gdy Java używa stylu C zgodnie z konwencją itp.).
  4. nigdy nie zmieniaj istniejącego kodu w celu jego zmiany, w ten sposób wprowadzasz tylko nowe problemy. A to oznacza sekcje kodu, a także całe pliki źródłowe. Nie należy więc ponownie formatować istniejącego kodu, gdy ktoś zmienia pojedynczy wiersz w pliku 1000 linii.
  5. doświadczeni programiści mogą być znacznie bardziej produktywni, jeśli nie będą musieli zastanawiać się przez pół czasu, czy to, co piszą, „będzie wyglądać dobrze” w przypadku automatycznego systemu zatwierdzania lub recenzenta. Będą też mieli zwyczaj pisania czystego kodu po prostu dlatego, że to działa, nawet jeśli istnieją niewielkie różnice między ich naturalnymi stylami.



Chociaż istnieją dobre powody, aby narzucić określony styl i standard, istnieją równie dobre powody, aby tego nie robić (zbyt) ściśle.

jwenting
źródło
1
1-2-3: To Java, a format kodu to Sun; po prostu formatuje, więc nie zamawia metod ani nazw zmiennych; 4-5: Cóż, pomysł polegałby na automatycznym sformatowaniu podczas zapisywania (akcje zapisywania Eclipse), więc bez dodatkowej pracy (nie musisz nawet myśleć o formacie podczas kodowania), ale oczywiście również istniejące pliki zostałyby sformatowane ( pierwszy raz).
Stijn Geukens
1
+1 dla KISS. @Stijn Po co formatować stary kod? Po prostu naciśnij, gdy musisz go zmodyfikować.
Erik Reppen
3
W rzeczywistości planujemy kilka poważnych refaktoryzacji i przeformatowalibyśmy cały kod w tym czasie, ponieważ scalanie i tak będzie prawie niemożliwe z powodu refaktoryzacji. Jeśli sformatujemy tylko przy zmianie, nadal będziemy mieli problemy z scalaniem z powodu zmienionego formatu za rok.
Stijn Geukens
4
Ogólnie zgadzam się z @StijnGeukens; nie tylko z powodów scalania, ale dlatego, że każde czyszczenie formatowania na dużą skalę utrudni śledzenie historii zmian w narzędziu do obwiniania. Jeśli wszystkie twoje zmiany hałasu są w jednym miejscu, zawsze możesz po prostu obwinić, aby rozpocząć przed tym punktem początkowo, a następnie zrobić drugą rundę zatrzymując się przed nim, jeśli chcesz spojrzeć na starszą historię.
Dan Neely,
2
zapomniałeś innego powodu Dan: zmiany formatowania na dużą skalę mogą łatwo wprowadzić nowe błędy w nieoczekiwanych miejscach.
jwenting
11

Tak, konsystencja jest to dobry pomysł, ze względu na inne nie wymienione .

Chciałem tylko dodać kilka punktów, które nie zostały wykorzystane w innym miejscu:

  • Oracle opublikowało zestaw konwencji dla Javy, które są de facto standardem.
    • Korzystanie z nich powinno pomóc uniknąć kłótni o to, który styl należy zastosować.
    • Wiele bibliotek publicznych i projektów typu open source zwykle korzysta z tych konwencji, więc kiedy trzeba na nie spojrzeć, formatowanie powinno być znane.
    • Formatyzator Eclipse ma wbudowane reguły pasujące do tych konwencji, które również powinny pomóc.
  • Możesz rozważyć wbudowanie haka w konfigurację kontroli źródła, aby kod był automatycznie formatowany przed wejściem do głównej gałęzi.
    • Możesz unikać bitew ze szczególnie upartymi programistami, którzy odmawiają przestrzegania standardu. Mogą nawet używać własnego formatowania podczas pracy, które później zostanie znormalizowane!
    • Jeśli w końcu użyjesz niestandardowych ustawień formatowania (np. Wiele osób zignoruje konwencję „maks. 80 znaków na linię”), musisz wprowadzić zmiany tylko w jednym miejscu.
vaughandroid
źródło
9

Byłem w zespole, który korzystał z wtyczki Checkstyle . Zamiast korzystać z gotowych funkcji, utworzyliśmy mały komitet zainteresowanych programistów. Dyskutowaliśmy o tym, co wydawało się brakujące, co wydawało się przesadne, i rozwaliliśmy sprawy. Wszyscy nauczyliśmy się czegoś w tym procesie i wzmocniliśmy mięśnie programistów.

(Przykłady naszych decyzji: 72 znaki szerokości są za małe, ale 120 było lepsze; lepiej użyć _ALLCAPS do statycznych finałów; wymuszanie pojedynczego wyjścia z funkcji jest dobrym pomysłem.)

Kiedy mieliśmy recenzje kodu, jedno z pierwszych pytań brzmiało: „Czy przejrzałeś go przez Checkstyle?” Zgodność ze standardami kodowania była w dużej mierze zautomatyzowana i odciągnęła uwagę od wybrednego recenzenta. Cudownie było łatwo, aby Checkstyle podświetlił podpis metody, kliknął prawym przyciskiem myszy i zmienił zmienną na końcową. Może także naprawić wcięcia i nawiasy klamrowe, dzięki czemu kod każdego z nas będzie wyglądał podobnie. Brakuje Javadoc dla funkcji publicznej? Checkstyle oznaczy funkcję.

(Usuwanie zapachu kodu jest ważniejsze niż spójne formatowanie. Jest to zaleta zautomatyzowanych narzędzi).

Umieściłbym zautomatyzowane narzędzia, takie jak Checkstyle, jako narzucające ten sam format, a bardziej na zachęcanie do podobnego wyglądu. A kiedy wypasasz koty, zautomatyzowane narzędzie może pomóc wyostrzyć umiejętności i zmniejszyć zapach kodu bez tworzenia kruchego ego.

rajah9
źródło
5
Pojedynczy punkt wyjścia? Istnieją pewne zasady stylu, z którymi naprawdę się nie zgadzam. (Jeśli problemem jest wielokrotne wyjście, funkcja / metoda jest za długa…)
Donal Fellows
@DonalFellows, Checkstyle dał nam punkt odniesienia, z którego możemy przejść w kierunku preferencji komitetu. Było wiele okrzyków natury: „Nie rozumiem, dlaczego wprowadzili ten standard!” Podczas gdy OP pytał o spójne formatowanie, myślę, że zautomatyzowane narzędzie daje znacznie więcej bez dodatkowego bólu.
rajah9,
6

Jeśli zamierzasz trzymać się tego samego IDE i zastosować narzędzia do formowania, to dobry pomysł, ponieważ nie wymagasz zbyt wiele wysiłku. Uprość zasady, koncentrując się na czytelności, a nie na zatrzymaniu analnym . To powinien być miarka.

Chociaż konsekwentnie formowana kula z błota jest lepsza niż zwykła kula z błota, lepiej byś spędził czas na jego czyszczeniu, niż na zbyt wybrednym podejściu do nawiasów. Nie zamieniaj się w menedżera, który ma wrażenie, że wykonuje swoją pracę, licząc wcięcia podczas przeglądu kodu i upewniając się, że nowe okładki znajdują się w raportach TPS .

Właśnie takie są osobiste preferencje i rzadko poprawiają produkcję: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Jeśli tak, przełam to i zrób coś.

JeffO
źródło
6

Zdecydowanie zalecam, aby ludzie wymuszali formatowanie kodu, a drobne naruszenia były łaskawie pomijane lub poprawiane. Przyczyny tego są krótko

  1. Urządzenie źle to robi w najgorszym możliwym czasie i zwykle, gdy używasz nowej funkcji języka. Jak poradzi sobie z zamknięciami w Javie itp.? Jalopy ma problem z wyliczeniami z funkcjami składowymi.
  2. Myślę, że to bardzo rozsądne obciążenie na programiście, aby produkował kod dla firmy, która wygląda jak kod firmy. Przydało mi się wspomnieć, że w ten sposób kod jest formatowany „tutaj”, a nie jak cały kod powinien być formatowany wszędzie. Ich poprzednia firma mogła wybrać inną ścieżkę i to jest w porządku. Podobnie jak w języku ojczystym, istnieją idiomy specyficzne dla kultury kodu, które chcesz wydobyć.
  3. Egzekwowanie składni kodu najlepiej wykonać przy pomocy recenzji kodu:
    1. Jeśli formatowanie jest ważne, to zachęca Twoją organizację do przeglądu kodu. Jest to ogromna korzyść.
    2. Jeśli reguła formatowania zostanie złamana, człowiek może na nią spojrzeć i lepiej ocenić maszynę, jeśli zamiar zostanie przekazany w bardziej czysty sposób. Jest to bardzo rzadkie, ale zdarza się czasami.

Jeśli chodzi o „czytelność => produktywność”, struktura kodu (taka jak klasy i funkcje jednej odpowiedzialności) kupi cię znacznie szybciej niż formatowanie kodu. Formatowanie kodu może być pomocne, ale różne umysły analizują instrukcje w różny sposób - nie wszyscy będą „bardziej produktywni”. Chciałbym podwoić strukturę kodu w stosunku do formatowania, ponieważ jest to coś, co zachęci cię do robienia recenzji kodu i zmusi zespół do myślenia o tym, jak działa program, a nie o tym, jak wygląda pojedyncza pętla.

Nie jestem wielkim fanem Domain Driven Design, ale jest to jeden z najnowszych modeli, który ma BARDZO dobrze zdefiniowany pomysł, w jaki sposób należy ustrukturyzować kod, a konwencje formatowania kodu wypływają naturalnie z programu strukturalnego Domain Driven Design. Znowu ... Nie lubię DDD, ale to świetny przykład, ponieważ jest tak dobrze zdefiniowany.

Przypuszczam, że tematem tej odpowiedzi jest: Wykonuj recenzje kodu i pozwól, aby formatowanie wypłynęło z kultury i z procesu recenzji.

Sam
źródło
Tx, niezły punkt widzenia tego. Ale z drugiej strony dodatkowa praca polega na tym, że podczas każdej recenzji recenzent musi również sprawdzić format.
Stijn Geukens
3
Jest to dodatkowe kliknięcie, aby wywołać linię czegoś w rodzaju „rybiego oka”, „niespójnego wcięcia” lub „otwartego nawiasu klamrowego”, więc tak, to więcej niż zero wysiłku. Jeśli jednak wydłuży to recenzje kodu o więcej niż 1 minutę, istnieje poważny problem. Po tygodniu pracy nad przeglądaniem własnego kodu wszyscy powinni bardzo szybko zauważać „zły” kod i poprawiać go.
Sam
4

Ogólnie rzecz biorąc, zakładając, że zatrudnisz rozsądnych programistów, złym pomysłem jest narzucenie uniwersalnego formatu kodu. Dobrym pomysłem jest jednak przyjęcie wytycznych kodowych .

Nigdy nie widziałem zestawu reguł formatowania kodu, które optymalizują czytelność we wszystkich przypadkach. Podobnie nie ma w 100% obowiązujących zasad gramatyki w języku angielskim: nasze mózgi po prostu nie są podłączone w ten sposób. Dlatego używaj wytycznych, ale daj programistom swobodę nadpisywania ich według własnego uznania.

Biorąc to pod uwagę, trudniejsza jest zasada „przestrzegaj konwencji kodu, która już istnieje w pliku / projekcie”.

Należy jednak pamiętać, że formatowanie przyczynia się znacznie mniej do czytelności niż po prostu logicznie zorganizowany kod. Widziałem mnóstwo nieczytelnego kodu spaghetti z doskonałym formatowaniem!

Keredson
źródło
2

Nie sądzę, że istnieje prosta odpowiedź na to pytanie. To nie jest pytanie tak lub nie. Chociaż uważam, że styl i konwencje nazewnictwa są w pewnym stopniu ważne, dość łatwo jest tracić zbyt dużo czasu na myślenie o tym. Najlepiej odpowiedzieć przykładem.

W jednym konkretnym projekcie, nad którym pracowałem, nie było żadnych konwencji. Każdy programista robił rzeczy na swój sposób. Z powodu względnego braku doświadczenia tego zespołu chodzenie z jednej klasy do drugiej było naprawdę denerwujące. Styl stanowił mniejszy problem niż problem konwencji nazewnictwa. Jeden programista odniósłby się do elementów interfejsu użytkownika okropną notacją węgierską (głupia praktyka w dobie współczesnych IDE), jeden nazwałby członków prywatnych w jeden sposób, inny nazwałby ich inaczej. Po prostu nigdy nie wiedziałeś, na co patrzysz.

Przeciwnie, jeden zespół wykorzystał StyleCop (był to projekt .Net) jako część procesu kompilacji. Co gorsza, korzystali także z większości domyślnych reguł. Zrobiłbyś więc coś zupełnie normalnego pod względem odstępów między wierszami lub położenia nawiasów klamrowych, a kompilacja z tego powodu wymiotowałaby. Zmarnowano tyle czasu, dodając spacje i wiersze do rzeczy, i wszyscy, łącznie z kolesiami, którzy nalegali na użycie StyleCop, skończyli na prawie każdym zatwierdzeniu. To była ogromna strata czasu i pieniędzy.

Chodzi mi o to, że bycie nieelastycznym nie jest odpowiedzią, ale bycie na Dzikim Zachodzie też nie jest. Prawdziwą odpowiedzią jest znalezienie miejsca, które ma największy sens, co moim zdaniem nie ma zautomatyzowanych narzędzi do sprawdzania rzeczy, ale też nie rzuca konwencji na wiatr.

Jeff Putz
źródło
2

Moim głównym argumentem przeciwko wspólnemu stylowi kodowania jest to, że do czytania własnego stylu używa się doświadczonego programisty. Możesz trenować rękę do pisania określonego stylu, ale jest prawie niemożliwe, aby wyćwiczyć oko, aby zrozumieć styl, którego nienawidzisz. Programista pisze raz fragment kodu, a następnie odczytuje go wielokrotnie podczas programowania i debugowania. Jeśli za każdym razem, gdy czyta własny kod, stara się go zrozumieć, ponieważ zmuszony jest napisać go w złym stylu, będzie bardzo nieszczęśliwy i mniej produktywny. To z mojego doświadczenia.

Nie jestem zbyt obeznany z Eclipse, ale automatyczne formatowanie przy zapisie brzmi jak przerażający pomysł. Deweloper musi mieć pełną kontrolę nad swoim kodem niezależnie od tego, czy styl kodowania jest narzucony czy nie. Operacja „zapisz” nie może zmieniać pojedynczego znaku bez wyraźnej zgody użytkownika.

Jeśli Twoja firma sprzedaje kod źródłowy, styl kodowania jest ważniejszy, ale jeśli sprzedajesz skompilowany kod, jest on mniej istotny.

Nadzieja, że ​​styl kodowania sprawi, że oryginalny koder będzie mniej rozpoznawalny i zapobiegnie wojnom ego, to bzdura w najlepszym przypadku i po prostu głupota w najgorszym przypadku. Świetni programiści zawsze produkują elegancki kod niezależnie od stylu.

Jestem również zdecydowanie pro oddając każdemu deweloperowi własność określonych jednostek kodu i nie pozwalam wszystkim dotykać każdego fragmentu kodu swobodnie. Opracowywanie całych jednostek w kodzie i bycie odpowiedzialnym za nie pozwala deweloperowi być dumnym ze swojej pracy i zapobiegać tworzeniu przez niego bzdurnego kodu, wiedząc, że błędy powrócą, by na niego polować.

Wreszcie, każdy, kto jest profesjonalnym stylem kodowania, zawsze zakłada, że ​​jego własny styl kodowania zostanie wybrany i wszyscy inni będą go śledzić. Wyobraź sobie, że styl kodowania, który najmniej ci się podoba od wszystkich programistów wybieranych jako standard. Czy nadal opowiadasz się za narzuceniem stylu kodowania?

Gur
źródło
2

Jeden format rządzący nimi wszystkimi ... czy jest naprawdę optymalny?

To jak jazda samochodem kogoś innego ...

Oczywiście można wskoczyć w samochód i jechać dowolny, ale będzie bezpieczniejsze, wygodniejsze i mniej prawdopodobne, aby upaść, jeśli masz trochę czasu, aby ustawić siedzenie, kierownicę i lusterka TWOJEJ preferencji.

W przypadku kodu formatowanie wpływa na komfort czytania i rozumienia kodu. Jeśli jest zbyt daleko od tego, do czego jesteś przyzwyczajony, będzie to wymagało większego wysiłku umysłowego. Czy konieczne jest narzucenie tego twórcom oprogramowania?

+1 do wszystkich wymienionych wyżej korzyści, ale ...

Automatyczne egzekwowanie wiąże się z kosztami, które należy wziąć pod uwagę:

-1 do faktu, że formatery kodu nie rozumieją estetyki formatowania kodu. Ile razy formatator kodu niszczył blok komentarza, który był ładnie wyrównany w formie tabelarycznej? Ile razy celowo wyrównywałeś złożone wyrażenie w pewien sposób, aby zwiększyć czytelność, tylko po to, aby automatyczne formatowanie pomieszało je w coś, co „przestrzega reguł”, ale jest znacznie mniej czytelne?

Czasami istnieją obejścia tych problemów, ale programiści mają ważniejsze rzeczy do rozważenia niż to, jak uchronić automatyczny formatator przed zniekształcaniem kodu.

Mają reguły formatowania, ale pozwalają zachować swobodę stosowania zdrowego rozsądku.

swpalmer
źródło
2
Absolutnie się zgadzam! Autoformatowanie jest głupie.
Łukasz Wiktor,
1

Dobrzy programiści to kreatywni ludzie, daj im licencję artystyczną. „Keep it simple” powinna być mantrą programistów. Mam dwie zasady:

Reguła 1: Podaj zmienne / kursory / obiekty / procedury / cokolwiek INNE NAZWY. Jednoznaczne nazwy, które nadają sens i zrozumienie Twojemu kodowi.

Reguła 2: Użyj wcięcia, aby pokazać strukturę kodu.

Otóż ​​to.

Jonesi
źródło
1
Czy możesz wyjaśnić, dlaczego tak jest? W jaki sposób pozwolenie każdemu deweloperowi na posiadanie licencji artystycznej (która różni się między twórcami tego samego projektu) jest lepszym pomysłem niż posiadanie tego samego formatu? Czy są jakieś problemy, które rozwiązuje Twoja alternatywa? I wzajemnie?
Myślę, że próbuję (i nie udaje mi się) to, że używanie rozsądnych nazw i dobre wcięcie kodu jest o wiele ważniejsze w odniesieniu do czytelności / konserwacji niż inne reguły, które możesz wymyślić. Nie twierdzę, że wszyscy w zespole powinni mieć swój własny styl, tylko jeśli tak, to co z tego.
Jonesi,
Zastanów się, czy mam formater kodu w Eclipse skonfigurowany w jeden sposób i zawsze sformatuję swój kod ... a ty skonfigurowałeś nieco inaczej ... i ciągle modyfikujemy ten sam kod. Czy ta „licencja artystyczna” powoduje jakieś problemy w różnicach?
Rozumiem, o czym mówisz, ale myślę, że problem z twoim punktem widzenia polega na tym, że masz bardzo różne style (zwróć uwagę, nie tylko źle, ale inaczej). Może to powodować prawdziwe problemy i opóźnienia podczas łączenia tych różnych stylów.
Daniel Hollinrake
1
Tak, rozumiem, Daniel. Powinienem dodać trzecią zasadę: modyfikując istniejący kod, dostosuj go do stylu edytowanego kodu. To naturalnie zrobiłbym, gdybym naprawiał stary program.
Jonesi
0

Dla mnie główną zaletą wspólnego formatu stosowanego automatycznie jest to, że pomaga nam w śledzeniu zmian i przeglądaniu kodu. git (i większość innych narzędzi kontroli źródła) może wyświetlać różnice w poprzednich wersjach plików. Wymuszając wspólny styl, minimalizuje różnice preferencji programistów.

Kristian H.
źródło
-1

To języki, a nie kody. My, ludzie, mamy ponad 6000 języków, więc tłumaczymy je. Jeśli więc chcesz, aby Twoje „kody” się komunikowały, musisz wprowadzić odpowiednie zmiany. Widzisz, że użytkownicy muszą zmienić nasze formaty danych, abyśmy nie stracili danych.

Vic Belleli
źródło
-2

Powiedziałbym, że tak nie jest. Wspólna struktura / format kodu w zespole jest zdecydowanie dobrą rzeczą, ale nie jest to wymuszane automatycznie. Powinni to robić ludzie, a nie komputer.

Moje największe problemy z koncepcją to

  1. Jeśli piszę kod w jednym formacie i jest on automatycznie formatowany ponownie, jaka jest zachęta do nauki tego formatu?
  2. Po poprzednim punkcie, jeśli nie nauczysz się formatu, cały punkt autoformatowania (aby ułatwić czytanie i modyfikację kodu) zostanie całkowicie utracony. Nadal musisz znaleźć czas na zrozumienie formatowania podczas czytania kodu, ponieważ nie nauczyłeś się tego formatu
  3. Myślę, że pisanie lekcji, zamykanie jej i wracanie następnego dnia, by zobaczyć, że jest zupełnie inaczej, byłoby niepokojącym doświadczeniem dla deweloperów. Oznacza to, że nie tylko inni muszą nauczyć się twojego kodu, ale musisz nauczyć się swojego kodu.
  4. Może również zachęcać do leniwego kodowania. Zamiast zachęcać programistę do nauki formatu, mogą pisać w dowolnym formacie pod słońcem, a on automatycznie będzie wyglądał tak, jak wszyscy tego chcą. Wraca to do nr 2, gdzie nie uczysz się stylu i nadal nie możesz go poprawnie odczytać.

Mogę teraz powiedzieć, że dobrym pomysłem byłoby uruchomienie automatycznego formatowania w projekcie, który jest całkowicie zamknięty. Spowodowałoby to uruchomienie każdego dewelopera na tej samej stopie dla projektu, gdy później przejdziesz do naprawy / dodawania funkcji. Jednak podczas aktywnego rozwoju uważam, że jest to bardzo zły wybór.

Zasadniczo: nałóż na pracownika odpowiedzialność za poznanie stylu firmy, nie zmuszaj jego kodu, by był czymś, czym nie jest.

Josh Janusch
źródło
+1: Dobre punkty, choć nie jestem pewien, czy przewyższają powody zautomatyzowanego formatowania. Dlaczego opinie?