Czy powinniśmy zachęcać do kodowania stylów na rzecz autonomii programistów, czy też zniechęcać do spójności?

Deweloper zapisuje if/elsebloki za pomocą instrukcji jednowierszowych, takich jak:

if (condition)
   // Do this one-line code
else
   // Do this one-line code

Inny używa nawiasów klamrowych dla wszystkich:

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

Deweloper najpierw tworzy instancję obiektu, a następnie go używa:

HelperClass helper = new HelperClass();
helper.DoSomething();

Inny programista tworzy instancję i używa obiektu w jednej linii:

new HelperClass().DoSomething();

Deweloper jest łatwiejszy dzięki tablicom i forpętlom:

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

Inny pisze:

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

Jestem pewien, że wiesz o czym mówię. Nazywam to stylem kodowania (ponieważ nie wiem, jak się nazywa). Ale jakkolwiek to nazwiemy, czy jest to dobre czy złe? Czy zachęcanie ma wpływ na wyższą produktywność programistów? Czy powinniśmy prosić deweloperów, aby spróbowali napisać kod w sposób, w jaki mówimy, aby cały system stał się spójny ze stylem?

Przydatny jest dokument standardów kodowania. Jest to najbardziej przydatne, gdy jest wystarczająco krótkie, aby każdy mógł zapamiętać całą sprawę bez większych problemów i gdy nie powoduje to zbytniego bólu.

To, jak wybierzesz wcięcie kodu w swojej organizacji, wielkie litery, implementację pętli lub komentowanie kodu, nie ma aż tak wielkiego znaczenia; pomocną częścią jest zachęcenie wszystkich do napisania kodu, który wygląda mniej więcej tak samo jak wszystkich innych.

• Pozwala to uniknąć konieczności ponownej kalibracji oczekiwania na to, gdzie powinny znajdować się nawiasy klamrowe i za każdym razem, gdy spojrzysz na kod innej osoby.
• Pozwala to uniknąć posiadania kilku różnych stylów kodu w jednym pliku.
• Być może, co najważniejsze, posiadanie pisemnego standardu pozwala uniknąć dyskusji na temat praktyk kodowania podczas przeglądów kodu.

Ponownie, standardy nie mają tak dużego znaczenia, jak posiadanie jakiegoś prostego, prostego standardu. Tak więc umieść wszystkich programistów w pokoju i pozwól im spierać się o standardy. Spotkanie może trwać w nieskończoność, więc zasady są następujące:

• O wszelkich decyzjach pod koniec spotkania decyduje kierownik.
• Spotkanie zakończy się po dwóch godzinach lub gdy ktoś zacznie krzyczeć lub płakać, w zależności od tego, co nastąpi wcześniej.
• Cały standard zmieści się (w rozsądnym rozmiarze!) Na arkuszu lub dwóch arkuszach papieru, dwustronnie tylko w razie absolutnej konieczności.

Rozważ przyjęcie kogoś | inne | standardy albo jako punkt wyjścia do spełnienia własnych standardów kodowania, albo jako sposób na całkowite uniknięcie spotkania.

Po uzgodnieniu programiści powinni mieć możliwość (i należy oczekiwać, że) sami siebie nadzorują. Sporadyczne odstępstwa od normy nie powinny być wielką sprawą (a nawet być uzasadnione), ale zuchwała odmowa rezygnacji z ulubionego osobistego stylu na rzecz normy powinna skutkować natychmiastowym przeniesieniem do biura z nieszczelnymi rurami wodnymi lub czymkolwiek innym .

Demian Brecht wskazuje na kłaczki. Stanowią one doskonałe uzupełnienie dokumentu standardów kodowania. Po prostu dobrze jest trzymać się standardów stylu kodowania ; to ważne , aby trzymać się standardów kodowania, które odnoszą się do niebezpiecznych praktyk. Nikt inny niż autor nie sprawdzi, czy każda linia kodu odpowiada standardowi stylu, ale z pewnością powinieneś rozważyć wbudowanie narzędzia do szuflady w obieg pracy zespołu, aby automatycznie wychwytywać potencjalne błędy. Ponadto samo narzędzie może kodyfikować przyjęte praktyki, abyś nie musiał wymieniać ich wszystkich indywidualnie w standardach kodowania; wystarczy określić konfigurację narzędzia.

Uwaga: Idea „standardów kodowania” nie dotyczy wyłącznie programowania. „Standardy kodowania” są stosowane w wielu dziedzinach, czasem w organizacji, częściej w całej branży lub zawodzie. Kilka przykładów:

• Dokumenty prawne, takie jak akta sądowe i transkrypcje, są zgodne z określonymi formatami.
• Skrypty i scenariusze muszą być napisane w określonym stylu, aby można je było traktować poważnie.
• Rysunki techniczne często musi mieć blok tytułowy w postaci standardowego.
• Formaty bibliografii są znormalizowane.

W każdym przypadku (i wielu innych) kompetentny lekarz może łatwo zrozumieć „kod”, który nie spełnia oczekiwanego standardu. Dlaczego tak wiele branż upiera się przy pisaniu szczegółowych wymagań dotyczących dokumentów, które nawet nie muszą być analizowane przez kompilator? Ponieważ styl ma znaczenie . Prezentacja informacji w standardowym stylu pozwala czytelnikowi skupić się całkowicie na treści, przyspiesza czytanie, ułatwia zrozumienie i zmniejsza liczbę błędów.

Styl nie ma znaczenia.

Tam powiedziałem.

Po 30 latach i setkach witryn klienckich oraz kodzie od (szacunkowym) 500 (lub więcej) członków zespołu przez te lata, stwierdziłem, że styl po prostu nie ma znaczenia.

Najpierw zabierz go do pracy.

Niech wykorzysta optymalną ilość zasobów (tj. Odpowiednią strukturę danych, właściwy algorytm).

Zamieszanie nad „stylem” po tym, jak wszystko inne zostało rozwiązane. Zamieszanie w „stylu” tylko za pomocą narzędzi, nigdy ręcznie.

Istnieją style kodowania i zapachy kodujące. Nie raz znalazłem:

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

Mój poprzedni pracodawca surowo zabronił używania multilinii if()bez aparatu ortodontycznego. Uznano to za błąd typu „zrób to jeszcze raz, a wy zwolniony”. Dozwolone konstrukcje to

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

Wynikało to z błędu podobnego do tego, który pokazałem powyżej, który zajął kilka godzin, aby zatrzymać stronę główną portalu.

Są rzeczy, które powinieneś zawsze robić. Jak switch():

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

W międzyczasie pisanie:

     case 1:
         something();
     case 2:
         something();
     break;

bez zamykania casez //fallthroughuważany jest za błąd.

Ogólnie rzecz biorąc, istnieje standard kodowania, który jest wytycznymi, które można zignorować, zinterpretować twórczo lub zmodyfikować dla określonych potrzeb. Jest też sekcja o „zapachach”, której należy ściśle przestrzegać.

Stwórz spójność dzięki dobremu projektowi. To, co opisujesz w pytaniu, to nic innego jak mikrozarządzanie. Dużo zajmuję się tworzeniem stron internetowych. Dlatego faworyzuję rozwój RESTful i CRUD jako usługi. Zapewnia to proste, dobrze zdefiniowane byty, których można używać na różne sposoby.

Ten projekt pozwala mi również przekazywać szczegóły implementacji innym programistom. W ten sposób wypełniają puste pola zamiast tworzyć cały projekt systemu.

Brak ogólnego projektu powoduje niespójności systemu. Krytyka podstawowych iteracji i konstrukcji zapętlających niewiele poprawia projektowanie systemu. Tego rodzaju problemy są lepiej rozwiązywane bez użycia rąk, StyleCop.

Czy potrafisz narysować stosunkowo prosty schemat ogólnego projektu systemu? Projekt opisujący elementy / byty związane z nowym deweloperem zespołu. Jeśli nie możesz lub jest to bardzo zaangażowane, brakuje projektu.

IMHO to zależy ...

Pierwsze dwa przykłady nie są dla mnie tylko osobistym gustem.

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(bez nawiasów) = bardziej podatny na błędy, jeśli później zostanie dodany więcej kodu:

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

A to jest mniej wygodne do debugowania:

new HelperClass().DoSomething(GetSomeData()); // etc.

Nie możesz po prostu ustawić punktu przerwania tam, gdzie go potrzebujesz. Jeśli jest to jednorazowe - w porządku, ale rozmawiamy o tym ze względu na styl, a kiedy już masz takie rzeczy wszędzie, debugowanie staje się bardziej nieprzyjemne, niż powinno być.

Jeśli chodzi o twój trzeci przykład (dla vs foreach), widzę to jednak jako kwestię gustu.

Ani. Unikałbym surowych zasad kodowania, aby uniknąć żmudności, wybredności, zarządzania mikro i najgorszego z marnowania czasu. Twoje poczucie autonomii jest twoim własnym problemem. Jeśli chcę, żebyś poczuł się lepiej, kupię ci rundę twojego ulubionego napoju. Poza tym zrób coś.

Stosowanie konwencji, nazw zmiennych, nazw klas itp. Jest dobrą praktyką. Ale style kodowania, takie jak podane przez Ciebie przykłady, są dość trywialne i nie mają wpływu na czytelność ani wydajność kodu. Z drugiej strony narzut związany z egzekwowaniem danego stylu w połączeniu z wysiłkami programistów, aby go zastosować, spowoduje problemy.

Użyj standardowego przemysłowego narzędzia do przyciemniania (najwyraźniej FxCop dla C #). Mimo że konsekwencja nie jest ostateczna, konsekwencja jest ważna w dużych projektach, w których pracuje wiele osób.

Jeśli pracujesz nad własnym projektem lub małym zespołem, wielu twierdzi, że to przesada. Wierzę inaczej (używam PEP8 dla Pythona, nawet w moich osobistych projektach dla jednego dewelopera).

Jednak większość podanych przez ciebie przykładów najprawdopodobniej nie zostałaby złapana przez narzędzie do szorowania, ponieważ po prostu nie mają znaczenia.

Egzekwowanie jednolitego stylu kodowania jest zawsze trudne. Idealnie takie przyziemne zadanie powinno być pozostawione narzędziu do obsługi. Pochwalam za to społeczność językową Go.

To połączenie obu. To, że jest to standard, nie czyni go czytelnym i łatwym w utrzymaniu. Jeśli nie ma jeszcze zaszczepionego standardu lub istnieją jego wadliwe i nieczytelne aspekty, poprawka jest odpowiednia.

W końcowej analizie programista steruje programowaniem. Istnieją problemy ze stylem, ale mają one drugorzędne znaczenie dla wyjścia z programu.

Pomocne jest udzielenie programistom SOME wskazówek dotyczących stylu. Można to / należy zrobić, zanim programiści zaczną działać, szczególnie jeśli są względnymi początkującymi w stosunku do środowiska lub samego programowania. Biorąc pod uwagę wskazówki, niektórzy programiści będą bardzo świadomi stylu, inni mniej. Wskazówki podane na początku projektu pomogą pierwszej grupie programistów, tym samym ułatwiając ogólne zadanie. Niewiele może to zrobić dla drugiej grupy, która (miejmy nadzieję) nadrabi kreatywność, której brakuje zgodności.

Myślę, że sprowadza się to do wielkości projektu i liczby osób nad nim pracujących. Doświadczony programista może spojrzeć na oba style różniące się formatem i wiedzieć, co się dzieje w obu z nich, ale musi być pewna konsekwencja, aby oko mogło ją łatwo złapać. Jeśli zamierzasz wykonać swoje ifstatamenty z pojedynczą linią bez nawiasów klamrowych, to ten projekt nie powinien ich używać. Kto kiedykolwiek prowadzi ten projekt, powinien mieć taki wybór. Lubię rzeczy, które wyglądają wyraźnie, a także bardzo kompaktowe, ponieważ mogę je zdobyć. Jeśli zamierzasz zrobić pojedynczą linię, jeśli statuty, lepiej tak to wygląda

if() {}
else() {}

Lub nawet:

if() {} else () {}

Ale pojedyncza linia, jeśli nie powinna używać odstępu mulitiliny, jeśli. Tak właśnie robię. Nie przeszkadza mi sposób, w jaki obiekt jest nazywany, a to zależy od tego, ile razy jest wywoływany. jeśli zostanie wywołany kilka razy, to raczej uruchamiam obiekt i zależy, czy ma on konstruktorów, a co nie. Ponieważ jeśli masz konstruktora i wywołujesz:

Object.method();
Object.method2();

Następnie dwukrotnie wywołałeś metodę konstruktora obiektów, gdy można było tego uniknąć, w pełni wykonując obiekt.

Jeśli chodzi o foreach i pętle Dotyczy to również lanauge, niektóre lanauges dają lepszą kontrolę, gdy patrzysz na tablicę w pętli foreach, dzięki czemu masz klucz i wartość w tablicach temp. Wiem, że niektóre ligi mają jakąś optymalizację, ponieważ mogą spojrzeć na pętlę i dokładnie wiedzieć, ile razy zostanie wywołana.

Chociaż twój pierwszy przykład nie jest świetny (argument, że jest bardziej podatny na błędy w trakcie modyfikacji, ma pewną wagę), ogólnie rzecz biorąc, tak naprawdę wolałem, aby programiści używali nieco innych stylów kodowania.

Po pracy z kodem innych członków zespołu, czasem nawet przez kilka miesięcy, zasadniczo zaczyna on działać w trybie liniowym git blame. Po ponad 10 latach pracy w mojej firmie mogę prawdopodobnie powiedzieć z 80% dokładnością, kto napisał dowolną klasę w dowolnym miejscu w naszych 500 000 liniach kodu, po prostu patrząc na to.

Chociaż jest trochę „czasu narastania”, kiedy zaczynasz patrzeć na kod, który używa stylu, z którym się nie zgadzasz, tak naprawdę robisz w tym czasie, mówiąc „och, to wygląda jak kod Johna Doe'a (ponieważ używa stylu X, ale nie stylu Y itp.) ”. I to pociąga za sobą całą masę kontekstu. W pierwszym przybliżeniu wiesz, czego się spodziewać po kodzie Johna - jakie inne części bazy kodu dobrze rozumie, a które nie, czy to guru SQL, czy nowicjusz GUI itp. Itp.

Uruchomienie kodu każdego przez formatyzator zasadniczo usuwa te informacje, ukrywając je za plikiem git blame, którego uruchomienie może być trudne.

To naprawdę zależy od rodzaju organizacji.

Jeśli jesteś małą grupą superbohaterów, każdy styl jest w porządku. Jeśli każdy ma swój własny styl, który jest zarówno dobry, jak i spójny wewnętrznie, to wszystko, czego potrzebujesz. Superbohaterowie powiedzą: „Jane ma nawiasy, więc to ona ma na myśli” lub „Jack używa camelCase do zmiennych”.

Uniwersalne standardy są zwykle najlepsze, aby każdy mógł być graczem B +. Twoi superbohaterowie zostaną przez to zburzeni. Ale jeśli chcesz, aby jeden gracz A i pół tuzina graczy B i pół tuzina graczy C osiągnęło średnią do B +, to chcesz spójnych standardów. W tym przypadku chcesz, aby wszyscy robili to samo, aby gracz A mógł przejść przez kod każdego użytkownika tak szybko, jak to możliwe.

Wielu z was mówi: „Ale czekaj, dlaczego nie pozbyć się graczy B i C?”

W rzeczywistości nie ma wielu superbohaterów. Chociaż znalezienie i pielęgnowanie ich w Google może być opłacalne, wprowadzenie nowego systemu rozliczeniowego Ma Bell może być bardziej opłacalne w przypadku tego drugiego zespołu. (A jeśli naprawdę masz Superbohaterów, 4 lub 5 z nich będzie dwa razy droższych niż tuzin juniorów)