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ć.
java
eclipse
code-formatting
Stijn Geukens
źródło
źródło
Odpowiedzi:
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.
źródło
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ć ...
źródło
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ę.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
merging
kodować do systemu kontroli wersji.źródło
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?
Chociaż istnieją dobre powody, aby narzucić określony styl i standard, istnieją równie dobre powody, aby tego nie robić (zbyt) ściśle.
źródło
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:
źródło
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.
źródło
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ś.
źródło
Zdecydowanie zalecam, aby ludzie wymuszali formatowanie kodu, a drobne naruszenia były łaskawie pomijane lub poprawiane. Przyczyny tego są krótko
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.
źródło
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!
źródło
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.
źródło
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?
źródło
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.
źródło
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.
źródło
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.
źródło
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” .
źródło
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.
źródło
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
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.
źródło