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

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ć.

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.

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ć ...

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.

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.

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.

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.

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ś.

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.

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!

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.

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?

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.

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.

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.

Przewodniki po stylach umożliwiają także łatwiejsze programowe analizowanie kodu do różnych celów analitycznych.

Google opublikował artykuł na ten temat zatytułowany „Wyszukiwanie długu kompilacyjnego: doświadczenia w zarządzaniu długiem technicznym w Google” .

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.

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.