A co z tymi wszystkimi zasadami kodowania?

10

Zawsze popierałem pomysł posiadania reguł kodowania dla programistów w firmie lub konkretnym projekcie. Zwłaszcza jeśli firma ma rozmiar większy niż 10. Im większa firma, tym większa potrzeba. Wiem, że wiele osób się nie zgodzi, ale widziałem projekty, które ich nie mają, a kod wygląda jak totalna katastrofa.

Prawdziwy problem z tym związany polega na tym, jak sprawić, by ci twardogłowi, którzy nie lubią używać nawiasów w instrukcjach if, lub używają tego samego ciągu połączeń w całym kodzie, czy cokolwiek innego, aby używali reguł kodowania bez przeciwstawiania się im pomysł?

TheBoyan
źródło
3
Jeśli używasz C # jako języka, użyj StyleCop. Jeśli używasz Java ...
Job
@Job - Tak, najczęściej używamy C #. StyleCop wygląda interesująco.
TheBoyan

Odpowiedzi:

9

Zaangażuj ich w rozwiązywanie problemu, a nie zasady walki. Osobiście wolę pomysł „przewodników po stylu”, „standardów kodowania” lub czegoś podobnego, w nadziei, że zapobiegnie to szarpnięciu kolan „reguła = zła” reakcja.

Ale nawet jeśli tak jest - wydaje mi się, że reguły obowiązują z jakiegoś powodu, a sposobem, aby skłonić twardych ludzi do zawracania, jest uświadomienie im, że postępując zgodnie z wytycznymi, pomagają ułatwić kodowi czytać dla wszystkich.

Czasami najlepszym rozwiązaniem jest presja otoczenia.

bethlakshmi
źródło
Grając tutaj w adwokata diabła, reguły mogą być po prostu błędne (na przykład coś wprowadzonego do poprzedniego projektu, ale stanowi obciążenie dla deweloperów bieżącego projektu) - więc proces przeglądu / uchylenia reguł - nawet jeśli jest rzadko używany - może być również pomocny w uspokajaniu ludzi, że reguły są raczej pomocną wskazówką niż narzucaniem wolności programistom.
Beekguk
Oczywiście - i myślę, że jeśli trzymasz się rady, aby skupić się na tym, dlaczego potrzebujesz reguły, to jeśli uznasz, że nie potrzebujesz reguły, wiesz, że zespół lub osoba przyjęła ją z otwartego sposobu myślenia, a nie tylko bycie defensywnym z powodu niewytłumaczalnego procesu rządzenia.
bethlakshmi
6

W mojej pracy wykorzystujemy wszystkie trzy z następujących rozwiązań:

1) Zastosuj moduł sprawdzania stylu kodu, taki jak doskonały Checkstyle (dla Java) lub StyleCop (dla C #). Są to łatwo konfigurowane narzędzia, które mogą automatycznie wyróżniać odchylenia stylu / reguły kodowania. Daje to wszystkim neutralną stronę trzecią w celu ustalenia, co jest i jest nie do przyjęcia.

2) Zastosuj szablon automatycznego formatowania kodu formatowania (oto przykład z użyciem Eclipse) (i inny dla Visual Studio), który automatycznie sformatuje kod po zapisaniu. Jest to świetne, ponieważ pozwala komuś zakodować, jak chce, ale cały kod należy sformatować w ten sam sposób przy zapisie / zatwierdzeniu. Naprawdę podoba mi się ten, a nasz kod nigdy nie był bardziej spójny.

3) Recenzje kodu. Mam nadzieję, że i tak je robisz, ale jedną z rzeczy, które powinny podkreślić, jest to, gdzie reguły / style kodowania łamią konwencję.

Oprócz powyższego ważne jest, aby wszyscy byli na tej samej łodzi i uzgodnili style / zasady, nad którymi pracują. Wyjaśnij, że nie uzyskasz zgody wszystkich na wszystko, ale poproś zespół o zaangażowanie, aby dotrzymać tego, co decyduje zespół. Pamiętaj, aby od czasu do czasu sprawdzać style / zasady wybrane w celu uwzględnienia rzeczywistego korzystania z nich i rotacji zespołu.

Chris Knight
źródło
Możesz skonfigurować niektóre systemy kontroli wersji, aby wymuszać takie rzeczy, jak Checkstyle podczas odprawy. Jeśli to zrobisz, zacznij od najbardziej krytycznych reguł, a następnie dodaj bardziej szczegółowe reguły.
BillThor
4

Prawdziwy problem z tym związany polega na tym, jak sprawić, by ci twardogłowi, którzy nie lubią używać nawiasów w instrukcjach if, lub używają tego samego ciągu połączeń wszędzie w kodzie, czy cokolwiek innego,

Czy są „twarde”, jeśli nie używają nawiasów, czy jest to „twarde” żądanie?

Wybierz bitwę. Wątpię, że jest to jeden z tych, które warto wybrać. Nie chciałbym korzystać w dowolnym miejscu pracy, które oczekiwane nigdzie w pobliżu tego poziomu szczegółowości na „pierwszej kontroli w kodzie”. Jest to wskaźnik czerwonej flagi, że zespół nie rozumie refaktoryzacji.

OO 101 : „Refaktoryzuj, gdy produkt robi to, co musi”. Nie przed.

P.Brian.Mackey
źródło
Nieużywanie nawiasów to tylko przykład :) chociaż pracowałem dla dużej firmy, która miała książkę> 200 stron zasad kodowania i to była jedna z nich. W każdym razie jestem pewien, że zgodziłbyś się ze mną, że ktoś, kto umyślnie używa tego samego ciągu połączenia (przykład ponownie) w kodzie, tylko dlatego, że jest zbyt leniwy, aby umieścić go w pliku konfiguracyjnym i przeczytać stamtąd wymaga uwagi i trzeba umieć radzić sobie z tego rodzaju sytuacjami.
TheBoyan
2

Trudno jest usiąść na ramieniu każdego programisty w dużych zespołach, upewniając się, że umieszczają aparat na szynie tam , gdzie Twoim zdaniem powinni pójść - zaufaj mi w tym;).

Jeśli naprawdę przeszkadza ci to w rozwoju, będziesz potrzebować „strażnika”. Nie pozwól, aby ludzie się zameldowali bez recenzji kodu. Poproś architekta technicznego lub kierownika zespołu, aby przejrzał kod i odrzucił go, dopóki nie „poprawi” stylu kodu. Niedługo się tym zmęczy i dostosują do zasad, być może tylko tak długo, jak będą sprawdzane.

Oczywiście niektóre firmy całkowicie odbierają uprawnienia do odprawy młodszym programistom. Kiedy w końcu poznają zasady kodowania firm, otrzymują przywilej.

Martin Blore
źródło
2
Jeśli umieszczenie aparatu jest twoim największym problemem jakościowym, myślę, że masz szczęście. Czy to właściwy poziom, na którym można się skoncentrować?
Bo Persson
Czysto przykład wzięty z pytania. Zasada jest taka, że ​​„wytyczne” do projektowania kodu, jak mówi poniżej bethlakshmi, to tylko wytyczne. Jeśli naprawdę martwisz się, w jaki sposób są przestrzegane, to muszą pojawić się punkty w procesie przypominania / uczenia / egzekwowania ich.
Martin Blore,
Ale nawiasy klamrowe tam, gdzie twoim zdaniem powinny pójść ... To mówi dużo. Myślę, że istnieją bardziej podstawowe aspekty czytelności / standardów kodowania niż umieszczanie nawiasów klamrowych. Zgadzam się, że wszyscy w projekcie powinni przestrzegać tego samego standardu, ale jeden nad drugim nie ma tutaj większego znaczenia. Może pozwolisz im „wygrać” bitwę o nawiasy klamrowe w zamian za zaakceptowanie twoich innych sugestii dotyczących standardów kodowania? Nie tylko, ale będą czuć się częścią rozwiązania, jeśli ich pomysł umieszczenia aparatu będzie zgodny ze standardami.
Gilles
1
Dokładnie. Zrezygnowałem z próby przekonania dewelopera do zrobienia nawiasów na ich własnej linii, zamiast nawiasów wbudowanych, w zamian za to, że uczył się SOLID i TDD ... to świetny zawód;).
Martin Blore,
1
„Oczywiście niektóre firmy całkowicie odbierają uprawnienia do odprawy młodszym programistom. Kiedy w końcu nauczą się zasad kodowania firm, otrzymują ten przywilej”. - to jedyny sposób, aby to zrobić, gdy ma to znaczenie.
ocodo
2

Myślę, że mówisz o problemach na bardzo różnych poziomach:

jak zrobić te twardogłowe, które nie lubią używać nawiasów w instrukcjach if,

Jest to głównie kwestia stylu / czytelności, chyba że występuje wyraźny problem z pierwszeństwem operatora. Ten ostatni nie powinien być bardzo powszechny i ​​i tak można go testować jednostkowo, a zatem łatwo go naprawić. Ten pierwszy może łatwo cofnąć się do Świętej Wojny, z niewielkim zyskiem, ale poważnymi negatywnymi konsekwencjami dla morale drużyny. Uważaj więc - wypychaj wypróbowane i przetestowane reguły, które zostały zaakceptowane przez co najmniej niektóre zespoły / społeczności i sprawdziły się.

lub użyj tego samego ciągu połączeń wszędzie w kodzie,

Jeśli masz na myśli Magic Constants, jest to rzeczywiście problem z utrzymaniem (i potencjalnie bezpieczeństwem), i jako taki IMHO każdy doświadczony programista zrozumie i zaakceptuje, że jest to Zła Rzecz.

czy cokolwiek innego, aby użyć zasad kodowania bez zmuszania ich do sprzeciwiania się temu pomysłowi?

Nie możesz zmusić ludzi do zgodzenia się z jakimikolwiek zasadami kodowania - jedyną szansą jest porozumienie i akceptacja członków zespołu poprzez dyskusję i (czasem zaciętą) debatę . Musisz użyć logicznych i przekonujących argumentów , pokazujących wartość każdej reguły i wyjaśniających, w jaki sposób przestrzeganie jej zapłaci za niedogodności związane z dostosowaniem zakorzenionych nawyków. Z drugiej strony staraj się, aby przejście było jak najłatwiejsze , np. Poprzez wprowadzenie automatycznego formatowania kodu przy odprawie, zgodnie z przyjętymi zasadami.

Jednak czasami trzeba po prostu zaakceptować fakt, że ludzie mają różne opinie , dlatego zasady kodowania, które każdy może zaakceptować, będą łagodne pod pewnymi względami. Zaakceptuj to i skup się na obszarach, w których możesz poprawić rzeczy przy mniejszym wysiłku.

Péter Török
źródło
„wprowadzenie automatycznego formatowania kodu przy odprawie zgodnie z przyjętymi zasadami”… to brzmi interesująco, wszelkie dalsze pomysły na to, gdzie mogę znaleźć coś takiego.
TheBoyan
@bojanskr, większość popularnych IDE obecnie obsługuje reguły formatowania kodu w mniejszym lub większym stopniu i może automatycznie formatować kod po zapisaniu lub zameldowaniu. W przypadku Java, zarówno Eclipse, jak i IntelliJ, wydaje mi się, że NetBeans również, ale nie mam z tym dużego doświadczenia. Dla C #, patrz komentarz @ Job powyżej. Ale istnieją również samodzielne narzędzia, takie jak Styl artystyczny dla C / C ++. I większość SCC, które znam, obsługuje wykonywanie specyficznych dla użytkownika skryptów / wyzwalaczy np. Podczas meldowania.
Péter Török
2

Zaangażuj ich w ustalanie reguł. Zwykle pomaga to zachęcić ludzi do podążania za nimi.

JeffO
źródło
1

Do tego służy przegląd kodu. Recenzenci kodu nie powinni pozwalać na przekazywanie kodu, który nie spełnia standardów. Pamiętaj, aby nie rozluźniać zasad dotyczących pilnych poprawek. Ponowne wykonanie kilku czynności pod presją, aby to zrobić, naprawi niechęć do poprawnego wykonywania zadań za pierwszym razem.

HLGEM
źródło
1

Ten sam ciąg połączenia wszędzie? Rozwiązaniem tego jest refaktoryzacja do momentu usunięcia całej duplikacji. Kodery kopiuj-wklej powinny przejść do więzienia programisty. (Nie śmiej się! Steve Ballmer jest naczelnikiem.)

Ale prawdziwym problemem jest twój czasownik „make” . Nie możesz zmusić programistów do zrobienia czegokolwiek, a jeśli to zrobisz, zmarnujesz ich najcenniejszą cechę: głębokie zaangażowanie intelektualne wynikające z pracy nad czymś, na czym ci zależy.

Sposób, w jaki to rozwiązałem:

  1. Nalegaj, aby zespół miał wspólny standard kodowania. Może mieć 5 linii, ale wszystkie muszą się zgodzić.
  2. Za każdym razem, gdy zauważysz argument, nalegaj, aby uzgodnili go razem i umieścili w standardzie kodowania. Jeśli zauważysz, że ludzie zmieniają format rzeczy w tę iz powrotem, potraktuj to jako argument.
  3. Za każdym razem, gdy zostanie uzgodniony standardowy element, sprawdź, czy istnieje narzędzie, które od razu wyczyści całą bazę kodu.
  4. Co kilka miesięcy zapoznaj się ze standardem kodowania i sprawdź, które z nich są nadal prawdziwe i odpowiednie. Standard po prostu dokumentuje to, co ludzie robią. I nie ma sensu utrzymywać przedmiotów w standardzie, które stały się oczywiste.

Programowanie to sport zespołowy lub wspólne dzieło artystyczne. To, na co ludzie się zgadzają, nie ma znaczenia tak bardzo, jak się zgadzają, i są dobrzy w zawieraniu nowych umów w razie potrzeby.

William Pietri
źródło