Wytyczne kodowania: metody nie powinny zawierać więcej niż 7 instrukcji?

Szukałem przez AvSol Kodowanie Wytyczne dla C # i zgadzam się z prawie wszystkiego, ale jestem bardzo ciekaw, co inni myśleć o jednej konkretnej reguły.

AV1500

Metody nie powinny przekraczać 7 instrukcji Metoda, która wymaga więcej niż 7 instrukcji, robi zbyt wiele lub ma zbyt wiele obowiązków. Wymaga również od ludzkiego umysłu przeanalizowania dokładnych instrukcji, aby zrozumieć, co robi kod. Podziel go na wiele małych i skoncentrowanych metod z samo-wyjaśniającymi się nazwami.

Czy większość z was przestrzega tej zasady? Nawet jeśli nie ma wiele do zapisania przy tworzeniu nowej metody (Twój kod wciąż jest SUCHY ) oprócz znacznego zwiększenia czytelności? A czy twój numer wciąż wynosi zaledwie 7? Skłoniłbym raczej do 10.

Nie twierdzę, że łamię tę zasadę wszędzie - wręcz przeciwnie, moje metody są w 95% małe i skoncentrowane, ale mówienie, że nigdy nie powinieneś łamać tej zasady, naprawdę mnie rozwaliło.

Naprawdę chcę tylko wiedzieć, co wszyscy myślą o NIGDY nie naruszającym tej zasady (jest to „1” w standardzie kodowania - co oznacza, że ​​NIGDY nie rób tego). Ale myślę, że miałbyś problem ze znalezieniem bazy kodu, która by tego nie zrobiła.

To dla mnie „zapach wzorcowy”. Ilekroć widzę standardy kodowania z określonymi limitami, martwię się. Prawie zawsze natrafiasz na przypadek, w którym metoda musi być większa niż pozwala na to norma (czy to długość / liczba linii, liczba zmiennych, liczba punktów wyjścia itp.). Normy powinny bardziej przypominać wytyczne i zapewniać wystarczającą swobodę w dokonywaniu właściwego osądu. Nie zrozumcie mnie źle, dobrze jest mieć standardy, ale nie powinny one stać się „mikrozarządzaniem przez proxy”.

Zwykle dobrym pomysłem jest podzielenie rzeczy na małe metody. Ale ważne jest, aby podzielić rzeczy tam, gdzie ma to sens.

Jeśli podział nie ma sensu, nie dziel się. Często dzieje się tak w przypadku niektórych procedur lub kodu GUI.

Steve McConnell stwierdził w Code Complete , że nie zawsze jesteś bardziej produktywny, kiedy używasz krótkich metod. Jeśli podzielisz się, gdy nie ma to sensu, zwiększysz złożoność kodu bez żadnych korzyści.

Jak zawsze w przypadku wytycznych, dobrze jest pamiętać, dlaczego istnieją ograniczenia, aby można było dowiedzieć się, kiedy nie mają zastosowania. W większości kodu metody będą krótkie lub prawdopodobnie masz problem z OSUSZANIEM lub separacją problemów . Ale jeśli tak nie jest, to dobrze.

Należy to traktować jako ogólną zasadę.

Rzeczy takie jak „Nie więcej niż 80 (100,120) kolumn tekstu”, „jeden punkt wyjścia na metodę”, „nie więcej niż 2 poziomy zagnieżdżania” to tak zwane progi dla wskaźników zapachu kodu. Jeśli czasem je naruszysz, niekoniecznie oznacza to, że kod jest zły. Jeśli konsekwentnie je naruszasz, w kodzie coś pachnie i możesz zrobić sobie przerwę i przemyśleć swoje podejście.

Dla mnie najważniejsze kryteria to: „Czy ten kod jest zrozumiały?”, „Czy jest powtarzalny?”, „Czy jest rozbity w logicznych miejscach?”, „Czy jest luźno powiązany?” Jest jeszcze kilka innych, ale myślę, że podstawową ideę można podsumować, pamiętając radę Donalda Knutha: „Programy są przeznaczone do czytania przez ludzi i tylko przypadkowo do uruchomienia przez komputery”.

Nigdy nie poświęciłem czasu na policzenie liczby instrukcji w moich metodach, ale staram się pisać metody, które czysto spełniają jeden, jasny cel. Tak długo, jak twój kod jest czysty, czytelny i zgodny z zasadami DRY i Single Responsibility , prawdopodobnie wykonałeś swoją pracę. Uważam, że arbitralne dzielenie metody tylko w celu wymuszenia ograniczenia siedmiu instrukcji może sprawić, że Twój kod będzie mniej czytelny / możliwy do utrzymania.

To jest przybliżone

Tego rodzaju zasad nie należy brać zbyt dosłownie. Mogliby powiedzieć, że „ metody powinny być krótkie ”. Jednak niektórzy interpretowaliby to jako „mniej niż 1 stronę”, a inni jako „najwyżej 2 linie”.

Zakładam , że powiedzieli „7 stwierdzeń”, aby dać ci ogólny pogląd (choć myślę, że powinni byli powiedzieć „około 7”). Jeśli potrzebujesz od czasu do czasu 9, nie przejmuj się. Ale jeśli zdobędziesz 20, będziesz wiedział, że nie masz odpowiedniego pola do gry dla tej reguły.

7 to liczba całkowicie dowolna, absolutnie bez znaczenia.

Złożoność cykliczna jest większym problemem niż liczba stwierdzeń. Widziałem kod, który zawierał setki instrukcji w jednej metodzie (co uważałem za okropne), ale miał cykliczną złożoność 1 i naprawdę tylko jedną rzecz. Było tylko wiele kroków. Dyskutowaliśmy o podzieleniu go na mniejsze metody, ale metody te można by wywołać tylko za pomocą tej jednej metody.

Chociaż jest to dość ekstremalny przypadek, chodzi o to, aby zachować SUCHY kod i niską złożoność cykliczną. Jest to ważniejsze niż liczba linii w metodzie.

Weźmy na przykład instrukcję switch / case. Jeśli masz więcej niż 7 możliwych wartości, musisz podzielić ocenę na wiele metod? Oczywiście, że nie, to byłoby głupie.

Sztuczne dzielenie kodu na więcej metod w celu utrzymania liczby instrukcji poniżej 7 tylko pogarsza kod.

Wytyczne powinny być następujące: Każda metoda powinna zrobić jedną rzecz i zachować SUCHY kod.

Cóż, to trochę zależy. Piszę dużo kodu, który ma dostęp do baz danych. Kod płyty kotłowej do obsługi wyjątków ma w wielu przypadkach więcej niż siedem instrukcji. Powiedziałbym, że najlepszą wskazówką jest upewnienie się, że twoja funkcja ma jeden cel

Wszystko jest kompromisem. Problem z proponowanym podejściem - refaktoryzacją na kilka metod i klas, tak aby każda metoda była krótka - polega na tym, że chociaż z różnych powodów prowadzi do nieczytelnego kodu, gdy doprowadzi się do skrajności.

Wyobraź sobie metodę, foo()która robi 7 rzeczy. Możesz argumentować, że 7 rzeczy to za dużo. Może w wielu przypadkach masz rację. Z drugiej strony te 7 rzeczy mogą być ściśle powiązane; logika może płynąć płynnie i czytać jak proza; możesz nie mieć problemów ze zrozumieniem, kiedy naprawdę potrzebujesz. To, co może skończyć się znacznie gorzej, to mieć te 7 rzeczy rozmieszczonych w dużym drzewie źródłowym, więc jeśli spojrzysz na foo()nie, nie masz pojęcia, co on robi bez patrzenia w 7 różnych miejscach.

Wiele osób ma takie zasady w głowie, a efektem tego jest spaghetti OO. Wszystko jest schludne, zapakowane we własną małą metodę lub klasę, w każdym miejscu występują małe atomowe mikro-transakcje. Ale nie da się odświeżyć takiej bazy kodu i wiedzieć, co ona robi. Zgubiłeś się.

to nie jest zła wskazówka. Nigdy nie żałowałem, że dzieliłem metody i klasy (nigdy nie zauważyłem, że miałem ich zbyt wiele), o ile są wystarczająco zgrupowane i powiązane ze sobą.

Sztuczka polega na tym, aby NIE rozdzielać jej w pionie (po prostu uszczypnij metodę w jednym punkcie i uruchom nową). Sztuczka, podobnie jak w przypadku testów jednostkowych, polega na tym, aby od początku pamiętać o takiej zasadzie, aby właściwie projektować lepiej, przekazując 3 lub 4 instrukcje w połowie metody do innej metody, ponieważ wywołanie metody opisuje to, co robisz lepiej niż te 3 lub 4 instrukcje w środku kodu.

Ten rodzaj podziału, nawet jeśli jest arbitralny i użyty tylko raz, może prowadzić do lepszych refaktoryzacji później ze względu na nową przejrzystość kodu, dotyczy to również mniejszych klas.

Pomyśl o tym jak o testowaniu jednostkowym. Jeśli spróbujesz dodać testowanie jednostek po fakcie, że jest to trudne, a czasem wydaje się niemożliwe, ale jeśli projektujesz go od samego początku, poprawia cały kod.

Podsumowanie? Porównując zapach projektowy „Użyj mniej niż 7 instrukcji” z zapachem kodu „Użyłem więcej niż 7 instrukcji”, wolałbym wyeliminować zapach kodowy.

Łał! Nigdy nie spodziewałem się tak intensywnej dyskusji na prostej wytycznej, która z grubsza mówi, że twoje metody powinny być bardzo małe. Ponieważ zawsze są programistami, którzy chcą, aby ich wytyczne były wyraźne, wybrałem 7, ponieważ brzmiało to jak niezły próg.

Niektórzy z was cytowali już zrzeczenie się odpowiedzialności na początku dokumentu. Ale dla jasności, ten dokument stanowi zbiór wskazówek, które próbują pomóc Ci napisać lepszy kod i zaprojektować lepsze systemy. Nigdy nie twierdziłem, że cokolwiek powinno być regułą, mimo że wytyczna jest oznaczona jako poziom 1. Poziomy te są po prostu zbiorową opinią wielu osób, które korzystają z tego dokumentu od jakiegoś czasu.

Nigdy też nie twierdziłem, że jestem ekspertem. Ale jestem w tym zawodzie od 15 lat, z około 4-letnim doświadczeniem w C ++ i 11-letnim doświadczeniem w C #. Pierwotnie był oparty na przemysłowej sile C ++, ale od tego czasu udoskonalałem go przy wsparciu społeczności.

Niezależnie od tego, chciałem poruszyć kwestię, że powinieneś myśleć sam za siebie. Jeśli uważasz, że wytyczna dotycząca 7 stwierdzeń nie jest przydatna, po prostu przedłuż ją. Cholera, czasem nawet naruszam tę wytyczną. Po prostu naruszam to świadomie i akceptuję konsekwencje.

Po pierwsze: jest to wytyczna, a nie reguła. Nazywa się to wytyczną, więc traktuj to jako takie. Oznacza to, że wymagany jest również Twój własny osąd (jak zawsze)

Poza tym mogę wymyślić wiele przykładów dobrego kodu, który nie przestrzega tego ograniczenia. Chociaż jest to tylko wskazówka, jest kiepska.

Zgadzam się ze stwierdzeniem nade mną. To tylko wytyczne, a w idealnym świecie wszystko byłoby przedmiotami, ponownie wykorzystywanymi w każdym programie, a świat byłby pięknym miejscem. Nie zawsze jest to prawdą i czasami prowadziłoby to do dużych kosztów ogólnych lub marnowania zasobów. Musisz o tym również pamiętać.

Całkiem głupie, gdy dodasz obsługę wyjątków do mieszanki.

Po „spróbuj złapać, w końcu” masz cztery instrukcje na metodę!

Weź również pod uwagę metodę „validateForm” dla formularza 20 pól, nawet jeśli obsłużysz wszystkie indywidualne sprawdzania poprawności w oddzielnych metodach, nadal masz 20 metod sprawdzania poprawności pól. Zgodnie z tymi wskazówkami skończyłbyś się bezsensownym podziałem, takim jak „validateTopOfScreen”, „validateMiddleOfScreen” i „validateBottomOfScreen”.

Pytanie polega na połączeniu „reguł” z „wytycznymi”. Reguły powinny być przestrzegane - wytyczne to porady, które mają skłonić cię do zastanowienia się nad tym, co robisz i czy naprawdę można to zrobić lepiej.

Powiedziałbym, że większość programów jest prawdopodobnie ulepszona dzięki przestrzeganiu wytycznych, ale zawsze będą przypadki, w których dogmatyczne stosowanie wytycznych spowoduje więcej problemów, niż zamierzano rozwiązać. Dlatego nie są one przedstawiane jako reguły, ale jako wytyczne.

Poprzedni odpowiadający wykazał, że autorzy wytycznych nigdy nie zamierzali stosować ich w sposób dogmatyczny, i zamieścili w tym dokumencie oświadczenia w tej sprawie.

Zgadzam się z powyższymi komentarzami. 7 dla mnie jest arbitralne i może być przydatne w niektórych językach, w których ruby, ale dla języków takich jak C #, Java, C ++ wątpię w tę konwencję „7 linii”. Dam ci przykład: moja obecna aplikacja ma 22 pola tekstowe i sprawdzam poprawność po stronie serwera. Ta metoda nazywa się validateInput (), a moją preferencją jest sprawdzanie poprawności wszystkich pól w samej metodzie, chyba że sprawdzę coś złożonego, na przykład checkEmailFormat (). Tak więc w zasadzie mój kod metody validateInput ma 108 linii z okazjonalnymi wywołaniami złożonej weryfikacji.

Teraz wyobraź sobie, że zadzwoniłem do 25 metod w celu sprawdzenia poprawności każdego pola. Jeśli pojawi się nowy programista, będzie musiał wejść i wyjść z głównej metody, aby przejść przez 25 metod, które z kolei mogą wywoływać kilka innych. Z pewnością zgubi się w dużych projektach.

To, co naprawdę robię, aby mój kod był przejrzysty, to dostarczanie czystych komentarzy, które w zasadzie mówią, co robią te 4 linie, np.

validateInput (użytkownik UserObj) {

// Potwierdź imię ....... ......

// sprawdź nazwisko ...... ......

// sprawdzanie poprawności wiadomości e-mail ..... // zbyt skomplikowane, aby sprawdzić format wyrażenia regularnego checkEmailFormat (); .... .....

i tak dalej.. }

Zła reguła. W przypadku kodu obsługi wyjątków, ustawiania pól bazy danych, sprawdzania poprawności, w jaki sposób większość metod może mieć mniej niż siedem instrukcji? Czy nigdy nie powinniśmy wykonywać wbudowanych funkcji lambda?

Linie kodu to dowolna liczba złożoności. Metodami rozszerzenia mogę tworzyć podobny kod

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

Wszyscy młodsi programiści powinni być zmuszeni do przestrzegania tej zasady. Zmusiłoby ich to do zastanowienia się nad strukturą tego, czym są zajęci, zamiast dodawania coraz większej liczby wierszy kodu.

Obecnie patrzę na metodę 550 wierszy kodu z dużą ilością instrukcji if else i kontynuuje i zwraca utkane w nim. To bzdura. Gdyby programista był zmuszony myśleć tylko o tym, co robi ...