Jaka jest idealna długość metody dla Ciebie? [Zamknięte]

123

W programowaniu obiektowym oczywiście nie ma dokładnej reguły dotyczącej maksymalnej długości metody, ale nadal uważałem, że te dwa cytaty są ze sobą sprzeczne, więc chciałbym usłyszeć, co myślisz.

W czystym kodzie: Podręcznik zwinnego wytwarzania oprogramowania Robert Martin mówi:

Pierwszą zasadą funkcji jest to, że powinny być małe. Drugą zasadą funkcji jest to, że powinny one być mniejsze. Funkcje nie powinny mieć długości 100 linii. Funkcje rzadko powinny mieć długość 20 linii.

i podaje przykład z kodu Java, który widzi od Kent Beck:

Każda funkcja w jego programie miała tylko dwie, trzy lub cztery linie. Każda z nich była oczywista. Każdy opowiedział historię. I każdy prowadził cię do następnego w przekonującej kolejności. Tak krótkie powinny być twoje funkcje!

Brzmi świetnie, ale z drugiej strony w Code Complete Steve McConnell mówi coś zupełnie innego:

Należy pozwolić, aby rutyna rozwijała się w sposób organiczny do 100-200 linii, dekady dowodów wskazują, że procedury o takiej długości nie są bardziej podatne na błędy niż krótsze.

I podaje odniesienie do badania, które mówi, że rutyny 65 lub dłuższe są tańsze w opracowaniu.

Więc chociaż istnieją rozbieżne opinie na ten temat, czy istnieje dla Ciebie funkcjonalna najlepsza praktyka?

iPhoneDeveloper
źródło
17
Funkcje powinny być łatwe do zrozumienia. Długość powinna wynikać z tego, w zależności od okoliczności.
Henk Holterman,
56
Myślę, że prawdziwy limit wynosi 53 linie. Ze średnim rozmiarem linii 32,4 znaków. Poważnie, nie ma ostatecznej odpowiedzi. Metoda 100 linii może być bardzo przejrzysta i łatwa w utrzymaniu, a metoda 4 linii może być koszmarem do zrozumienia. Ogólnie jednak długie metody mają zbyt wiele obowiązków i są trudniejsze do zrozumienia i utrzymania niż mniejsze. Pomyślałem o kategoriach odpowiedzialności i starałbym się mieć jedną odpowiedzialność za metodę.
23
W programowaniu istnieje termin zwany „spójnością funkcjonalną”. Długość funkcji powinna być różna, pod warunkiem, że jej implementacja nadal stanowi jedną spójną jednostkę logiki w twojej aplikacji. Arbitralne dzielenie funkcji w celu ich zmniejszenia jest bardziej prawdopodobne, aby nadmuchać kod i zaszkodzić łatwości konserwacji.
9
A jeśli chcesz ograniczyć złożoność funkcji, powinieneś zmierzyć ich cykliczność , a nie ich długość. switchOświadczenie z 100 casewarunkach jest bardziej utrzymaniu niż 10 poziomów ifwypowiedzi zagnieżdżone wewnątrz siebie.
10
Podejście Boba Martina pochodzi z 2008 r., A Steve Mc Connell z 1993 r. Mają różne filozofie dotyczące tego, czym jest „dobry kod”, a IMHO Bob Martin stara się uzyskać znacznie wyższy poziom jakości kodu.
Doc Brown

Odpowiedzi:

114

Funkcje powinny zwykle być krótkie, od 5 do 15 wierszy jest moją osobistą „praktyczną zasadą” przy kodowaniu w Javie lub C #. Jest to dobry rozmiar z kilku powodów:

  • Z łatwością mieści się na ekranie bez przewijania
  • Chodzi o rozmiar pojęciowy, który możesz trzymać w głowie
  • Wystarczająco sensowne jest wymaganie samodzielnej funkcji (jako samodzielnej, znaczącej części logiki)
  • Funkcja mniejsza niż 5 linii jest wskazówką, że być może łamiesz zbyt mocno kod (co utrudnia czytanie / rozumienie, jeśli potrzebujesz nawigować między funkcjami). Albo to, albo zapominasz o specjalnych przypadkach / obsłudze błędów!

Ale nie sądzę, aby pomocne było ustalenie bezwzględnej reguły, ponieważ zawsze będą istniały ważne wyjątki / powody do odstąpienia od reguły:

  • Jednowierszowa funkcja akcesorium, która wykonuje rzutowanie typu, jest w niektórych sytuacjach wyraźnie akceptowalna.
  • Istnieje kilka bardzo krótkich, ale przydatnych funkcji (np. Zamiana, o której wspomniał użytkownik nieznany), które wyraźnie wymagają mniej niż 5 linii. Nie jest to wielka sprawa, kilka 3-liniowych funkcji nie szkodzi twojej bazie kodu.
  • Funkcja 100-liniowa, która jest pojedynczą dużą instrukcją przełączania, może być akceptowalna, jeśli jest bardzo jasne, co się dzieje. Ten kod może być koncepcyjnie bardzo prosty, nawet jeśli wymaga wielu wierszy do opisania różnych przypadków. Czasami sugeruje się, że należy to przeformułować na osobne klasy i zaimplementować za pomocą dziedziczenia / polimorfizmu, ale IMHO to za daleko posuwa OOP - wolałbym mieć tylko jedną dużą instrukcję 40-drożną zamiast 40 nowych klas do obsługi na 40-kierunkową instrukcję switch, aby je utworzyć.
  • Funkcja złożona może mieć wiele zmiennych stanu, które stałyby się bardzo nieporządne, gdyby były przekazywane między różnymi funkcjami jako parametry. W takim przypadku można zasadnie argumentować, że kod jest prostszy i łatwiejszy do naśladowania, jeśli zachowa się wszystko w jednej dużej funkcji (chociaż, jak słusznie zaznacza Mark, może to być również kandydat do przekształcenia się w klasę, która zawiera zarówno logikę i stan).
  • Czasami mniejsze lub większe funkcje mają zalety w zakresie wydajności (być może z powodu inlinii lub powodów JIT, jak wspomina Frank). Jest to w dużej mierze zależne od implementacji, ale może mieć znaczenie - upewnij się, że przeprowadzasz testy!

Zasadniczo używaj zdrowego rozsądku , trzymaj się małych rozmiarów funkcji w większości przypadków, ale nie bądź dogmatyczny, jeśli masz naprawdę dobry powód, aby wykonać niezwykle dużą funkcję.

mikera
źródło
9
Jest też techniczny / perficzny powód dla krótkich metod: trafienia w pamięć podręczną JIT. Wiele mniejszych, wielokrotnego użytku metod jest częściej wywoływanych wcześniej. No i dodatkowa korzyść diag, StackTraces są bardziej skupione na logice, która się pop.
Luke Puplett,
20
„kieruj się zdrowym rozsądkiem” to najważniejsza rada
Simon
Należy zdawać sobie sprawę, że ta heurystyka spowoduje narzekanie na „kod ravioli” z powodu głębokości stosu w punktach przerwania podczas debugowania.
Frank Hileman
5
@FrankHileman Wezmę ravioli nad spaghetti każdego dnia, gdy piszę kod
1
@Smanman: te wybory nie wykluczają się nawzajem ... idealne są krótkie stosy bez spaghetti. Głębokie stosy, ze spaghetti na boku?
Frank Hileman,
29

Chociaż zgadzam się z komentarzami innych, którzy mówili, że nie ma twardych zasad dotyczących właściwego numeru LOC, założę się, że jeśli spojrzymy wstecz na projekty, które oglądaliśmy w przeszłości i zidentyfikujemy każdą funkcję powyżej, powiedzmy 150 linii kodu, ja ' zgaduję, że dojdziemy do konsensusu, że 9 na 10 z tych funkcji łamie SRP (a także bardzo prawdopodobne OCP), ma zbyt wiele zmiennych lokalnych, zbyt duży przepływ sterowania i jest ogólnie trudny do odczytania i utrzymania.

Więc chociaż LOC może nie być bezpośrednim wskaźnikiem złego kodu, z pewnością jest przyzwoitym pośrednim wskaźnikiem, że pewna funkcja może być napisana lepiej.

W moim zespole znalazłem się na czele i z jakiegokolwiek powodu ludzie wydają się mnie słuchać. Na ogół zdecydowałem się powiedzieć zespołowi, że chociaż nie ma absolutnego limitu, każda funkcja więcej niż 50 wierszy kodu powinna co najmniej podnieść czerwoną flagę podczas przeglądania kodu, abyśmy mogli na niego spojrzeć i ponownie go ocenić dla złożoności i naruszeń SRP / OCP. Po tym drugim spojrzeniu możemy to zostawić w spokoju lub możemy to zmienić, ale przynajmniej każe to ludziom myśleć o tych rzeczach.

DXM
źródło
3
Wydaje się to rozsądne - LOC nie ma żadnego znaczenia w odniesieniu do złożoności lub jakości kodu, ale może być dobrym wskaźnikiem dla możliwości, że rzeczy powinny zostać zrefaktoryzowane.
cori
4
„dojdzie do konsensusu, że 9 na 10 z tych funkcji psuje SRP” - nie zgadzam się, jestem całkiem pewien, że 10 na 10 z tych funkcji to złamie ;-)
Doc Brown
1
+1 za podniesienie flagi podczas przeglądania kodu: innymi słowy, nie jest to twarda i szybka reguła, ale omówmy ten kod jako grupę.
21

Włączyłem się w projekt, który nie dbał o wytyczne dotyczące kodowania. Kiedy patrzę na kod, czasami znajduję klasy zawierające więcej niż 6000 linii kodu i mniej niż 10 metod. Jest to scenariusz grozy, w którym musisz naprawić błędy.

Ogólna zasada, jak duża powinna być metoda, nie zawsze jest tak dobra. Podoba mi się reguła Roberta C. Martina (wujek Bob): „Metody powinny być małe, mniejsze niż małe”. Cały czas staram się korzystać z tej reguły. Staram się, aby moje metody były proste i małe, wyjaśniając, że moja metoda robi tylko jedną rzecz i nic więcej.

Smokefoot
źródło
4
Nie rozumiem, dlaczego funkcja 6000 linii jest trudniejsza do debugowania niż krótsza ... Chyba że ma też inne problemy (np. Powtórzenie)
Calmarius
17
Nie ma to nic wspólnego z debugowaniem ... chodzi o złożoność i łatwość konserwacji. Jak rozszerzyłbyś lub zmieniłeś metodę 6000 linii wykonaną przez inną?
Smokefoot
9
@Calmarius różnica polega zwykle na tym, że 6000 funkcji liniowych zwykle zawiera zmienne lokalne, które zostały zadeklarowane bardzo daleko (wizualnie), co utrudnia programiście budowanie mentalnego kontekstu wymaganego do dużej pewności co do kodu. Czy możesz być pewien, w jaki sposób zmienna jest inicjowana i budowana w dowolnym momencie? Czy jesteś pewien, że nic nie zadziała na twojej zmiennej po ustawieniu jej na linii 3879? Z drugiej strony, mając 15 metod liniowych, możesz być pewien.
Daniel B
8
@Calmarius zgodził się, ale oba te oświadczenia są argumentem przeciwko 6000 funkcjom LOC.
Daniel B
2
Zmienna lokalna w metodzie 600 linii jest zasadniczo zmienną globalną.
MK01
10

Nie chodzi o liczbę linii, chodzi o SRP. Zgodnie z tą zasadą, twoja metoda powinna robić jedną i tylko jedną rzecz.

Jeśli twoja metoda robi to ORAZ to ORAZ to => prawdopodobnie robi to zbyt wiele. Spróbuj spojrzeć na tę metodę i przeanalizować: „tutaj otrzymuję te dane, sortuję je i otrzymuję potrzebne elementy” oraz „tutaj przetwarzam te elementy” i „tutaj w końcu łączę je, aby uzyskać wynik”. Te „bloki” należy przefaktoryzować na inne metody.

Jeśli po prostu zastosujesz się do SRP, większość twojej metody będzie niewielka iz wyraźną intencją.

Nieprawidłowe jest stwierdzenie „ta metoda ma> 20 wierszy, więc jest błędna”. Może to wskazywać, że coś może być nie tak z tą metodą, nie więcej.

Być może masz metodę przełączania 400 linii w metodzie (często dzieje się to w telekomunikacji), i nadal jest to pojedyncza odpowiedzialność i jest całkowicie OK.

Alexey
źródło
2
Duże instrukcje przełączania, formatowanie wyjściowe, definicje skrótów / słowników, które powinny być zakodowane na stałe, a nie elastyczne w niektórych bazach danych, często się to zdarza i jest całkowicie w porządku. Dopóki logika jest podzielona, ​​wszyscy jesteście dobrzy. Duża metoda może skłonić cię do myślenia „powinienem to podzielić”. Odpowiedź mogłaby równie dobrze brzmieć „nie, tak jest w porządku” (lub tak, to absolutny bałagan)
Martijn
Co oznacza „SRP”?
thomthom,
3
SRP oznacza zasadę pojedynczej odpowiedzialności i stwierdza, że ​​każda klasa (lub metoda) powinna ponosić tylko jedną odpowiedzialność. Jest to związane ze spójnością i sprzężeniem. Jeśli zastosujesz się do SRP, twoje klasy (lub metody) będą miały dobrą spójność, ale sprzężenie może zostać zwiększone, ponieważ skończysz na większej liczbie klas (lub metod).
Kristian Duske
+1 dla SRP. Pisząc spójne funkcje, można łatwiej łączyć je w funkcjonalny styl, aby uzyskać bardziej złożone wyniki. W końcu lepiej, aby funkcja składała się z trzech innych funkcji, które zostały ze sobą sklejone, niż gdyby jedna funkcja wykonywała trzy dyskretne, nawet jeśli w jakiś sposób powiązane, rzeczy.
Mario T. Lanza,
Tak, ale co to jest jedna odpowiedzialność. To tylko koncepcja stworzona w twojej głowie. Jeśli potrzebujesz 400 linii na jedną odpowiedzialność, twoja koncepcja pojedynczej odpowiedzialności jest prawdopodobnie inna niż moja
Xitcod13,
9

Zależy to , poważnie, naprawdę nie ma solidnej odpowiedzi na to pytanie, ponieważ język, w którym pracujesz, ma znaczenie, od pięciu do piętnastu wierszy wymienionych w tej odpowiedzi może działać dla C # lub Java, ale w innych językach nie daje dużo pracy z. Podobnie, w zależności od domeny, w której pracujesz, możesz znaleźć wartości ustawień kodu w dużej strukturze danych. W przypadku niektórych struktur danych możesz mieć dziesiątki elementów, które musisz ustawić, czy powinieneś rozdzielić elementy na osobne funkcje tylko dlatego, że twoja funkcja działa długo?

Jak zauważyli inni, najlepszą regułą jest to, że funkcja powinna być pojedynczą logiczną jednostką, która obsługuje jedno zadanie. Jeśli spróbujesz wymusić drakońskie reguły, które mówią, że funkcje nie mogą być dłuższe niż n wierszy, a wartość ta będzie zbyt mała, twój kod będzie trudniejszy do odczytania, gdy programiści będą próbowali użyć wymyślnych sztuczek, aby obejść regułę. Podobnie, jeśli ustawisz go zbyt wysoko, nie będzie problemu i może prowadzić do złego kodu, choć lenistwo. Najlepiej jest po prostu przeprowadzić przegląd kodu, aby upewnić się, że funkcje obsługują jedno zadanie, i zostaw to.

rjzii
źródło
8

Myślę, że jednym z problemów jest to, że długość funkcji nie mówi nic o jej złożoności. LOC (linie kodu) to zły instrument do mierzenia czegokolwiek.

Metoda nie powinna być zbyt skomplikowana, ale istnieją scenariusze, w których można łatwo utrzymać długą metodę. Zauważ, że poniższy przykład nie mówi, że nie można go podzielić na metody, tylko że metody nie zmieniają łatwości konserwacji.

na przykład moduł obsługi danych przychodzących może mieć dużą instrukcję przełączania, a następnie prosty kod dla każdej sprawy. Mam taki kod - zarządzanie przychodzącymi danymi z kanału. 70 (!) Kodowanych numerycznie programów obsługi. Teraz powiedzą „użyj stałych” - tak, z wyjątkiem tego, że API ich nie udostępnia i lubię być blisko „źródła”. Metody? Jasne - niestety wszystkie one zajmują się danymi z tych samych 2 ogromnych struktur. Nie ma korzyści z ich rozdzielenia, z wyjątkiem może posiadania większej liczby metod (czytelności). Kod z natury nie jest złożony - jeden przełącznik, w zależności od pola. Następnie każda sprawa ma blok, który analizuje x elementów danych i publikuje je. Bez koszmaru konserwacji. Jest jeden powtarzający się „warunek, który określa, czy pole ma dane (pField = pFields [x], jeśli pField-> IsSet () {blabla}) - to samo w zasadzie dla każdego pola.

Zamień to na znacznie mniejszą procedurę zawierającą zagnieżdżoną pętlę i wiele prawdziwych instrukcji przełączających, a ogromna metoda może być łatwiejsza w utrzymaniu niż jedna mniejsza.

Przykro nam, LOC nie jest dobrym pomiarem na początek. Jeśli już, to należy użyć punktów złożoności / decyzji.

TomTom
źródło
1
LOC są doskonałym narzędziem do zastosowania w jednym obszarze, w którym zapewniają odpowiedni środek - bardzo dużych projektach, w których można je wykorzystać, aby pomóc oszacować, ile czasu może zająć ukończenie podobnego projektu. Poza tym ludzie zbyt często się o nich martwią.
rjzii
Dobrze. To nie jest tak, że LOC nie zależy od tego, jak ekspresywnie piszę kod, od wymagań dotyczących formatowania itp. LOC są całkowicie nieodpowiednie i są czymś, czego MBA nie używa. Tylko. Możesz umieścić się na liście osób, które nie rozumieją, dlaczego LOC jest złym pomiarem, ale wyraźnie nie sprawi, że będziesz wyglądać jak ktoś, kogo będziesz słuchać.
TomTom
Proszę przejrzeć to, co powiedziałem ponownie, zauważyłem, że LOC są dobrym narzędziem tylko do jednego obszaru pomiaru i zastosowania (tj. Wyjątkowo dużych projektów, w których można je wykorzystać do oszacowania). Wszystko mniejsze niż na dużą skalę, a oni używają większości, jeśli nie wszystkich, do czegoś poza szybkimi dźwiękami podczas spotkań, aby ludzie byli szczęśliwi. Przypominają próbę wykorzystania lat świetlnych do zmierzenia, jak uczciwa jest kawiarnia w biurze, na pewno da się to zrobić, ale pomiar jest bezużyteczny. Ale kiedy musisz omówić odległości między gwiazdami, działają świetnie.
rjzii
2
+1 funkcja powinna zawierać cały kod potrzebny do wykonania funkcji. Powinien zrobić tylko jedną rzecz - ale jeśli zajmie to 1000 linii kodu, niech tak będzie.
James Anderson
Napisałem programy obsługi przychodzących danych gniazd i tak, mogą wymagać tysiąca lub więcej LOC. Jednakże, mogę policzyć na palcach jednej ręki, ile razy mam potrzebnych do zrobienia, że nie może liczyć liczbę razy było nie odpowiedni sposób do kodu.
6

Wrzucę jeszcze jeden cytat.

Programy muszą być napisane, aby ludzie mogli je czytać, a tylko przypadkowo, aby maszyny mogły je uruchomić

- Harold Abelson

Jest bardzo nieprawdopodobne, że funkcje, które rosną do 100-200, postępują zgodnie z tą zasadą

Pete
źródło
1
Z wyjątkiem sytuacji, gdy zawierają przełącznik.
Calmarius
1
lub skonstruuj obiekt na podstawie wyników zapytania do bazy danych, które zwraca dziesiątki pól na wiersz w zestawie wyników ...
jwenting
Wyniki bazy danych są z pewnością akceptowalnym wyjątkiem - a ponadto są to zwykle „głupie” instrukcje, które zapełniają pewne wystąpienia klasy (lub cokolwiek innego), a nie logikę, niż trzeba przestrzegać.
MetalMikester,
6

Jestem w tej szalonej rakiecie, tak czy inaczej, od 1970 roku.

Przez cały ten czas, z dwoma wyjątkami, do których dojdę za chwilę, NIGDY nie widziałem dobrze zaprojektowanej „procedury” (metoda, procedura, funkcja, podprogram, cokolwiek), POTRZEBUJĄCEJ być więcej niż jedną wydrukowaną stroną ( około 60 linii). Zdecydowana większość z nich była dość krótka, rzędu 10-20 linii.

Widziałem jednak DUŻO kodu „strumienia świadomości”, napisanego przez ludzi, którzy najwyraźniej nigdy nie słyszeli o modularyzacji.

Te dwa wyjątki były bardzo szczególnymi przypadkami. Jeden z nich to tak naprawdę klasa wyjątków, które zbijam w całość: duże automaty o stanie skończonym, zaimplementowane jako duże brzydkie instrukcje przełączników, zwykle dlatego, że nie ma prostszego sposobu ich implementacji. Te rzeczy zwykle pojawiają się w automatycznych urządzeniach testowych, analizując dzienniki danych z testowanego urządzenia.

Drugim była procedura torped fotonów z gry STARTRK Matuszek-Reynolds-McGehearty-Cohen, napisana w CDC 6600 FORTRAN IV. Musiał przeanalizować linię poleceń, a następnie zasymulować lot każdej torpedy, z zaburzeniami, sprawdzić interakcję między torpedą a każdym rodzajem rzeczy, w które mogła trafić, i, nawiasem mówiąc, zasymulować rekurencję, aby uzyskać łączność 8-kierunkową na łańcuchach nowe od torpedowania gwiazdy znajdującej się obok innych gwiazd.

John R. Strohm
źródło
2
+1 za wibrację „zejdź z mojego trawnika”, którą otrzymuję z tej odpowiedzi. Ponadto, z osobistych doświadczeń sprzed języków OOP były szeroko rozpowszechnione.
To nie tyle „zejdź z trawnika”, co spostrzeżenie, że przez lata widziałem DUŻO bzdur i wydaje się, że robi się gorzej.
John R. Strohm,
Mój szef ma zwyczaj pisania metod o długości kilkuset linii, często z kilkoma poziomami zagnieżdżonych ifs. Używa także klas częściowych (.NET), aby „podzielić” klasę na kilka plików, aby mógł twierdzić, że je skraca. To tylko dwie rzeczy, z którymi mam do czynienia. Robię to od około 25 lat i mogę potwierdzić, że sytuacja się pogarsza. A teraz czas, abym wrócił do tego bałaganu.
MetalMikester,
5

Jeśli znajdę długą metodę - mógłbym się założyć, że ta metoda nie jest odpowiednio testowana jednostkowo lub przez większość czasu wcale jej nie testuje. Jeśli zaczniesz robić TDD, nigdy nie zbudujesz 100-liniowych metod z 25 różnymi obowiązkami i 5 zagnieżdżonymi pętlami. Testy zobowiązują cię do ciągłego refaktoryzowania bałaganu i pisania czystego kodu wuja Boba.

Sergii Szewczyk
źródło
2

Nie ma bezwzględnych reguł dotyczących długości metody, ale przydatne były następujące reguły:

  1. Podstawowym celem funkcji jest znalezienie wartości zwracanej. Nie ma innego powodu jego istnienia. Po wypełnieniu tego powodu nie należy do niego wstawiać żadnego innego kodu. To z konieczności sprawia, że ​​funkcje są małe. Wywołanie innych funkcji powinno być wykonane tylko wtedy, gdy ułatwia to znalezienie wartości zwracanej.
  2. Z drugiej strony interfejsy powinny być małe. Oznacza to, że albo masz dużą liczbę klas, albo masz duże funkcje - jedna z nich wydarzy się, gdy zaczniesz mieć wystarczającą ilość kodu, aby zrobić coś znaczącego. Duże programy mogą mieć oba.
tp1
źródło
1
Co z efektami ubocznymi - zapisywanie do pliku, resetowanie statusu itp.?
Vorac,
2

Czy autorzy rozumieją to samo przez „funkcję” i „rutynę”? Zazwyczaj, gdy mówię „funkcja”, mam na myśli podprogram / operację, która zwraca wartość i „procedurę” dla takiej, która tego nie robi (a której wywołanie staje się pojedynczą instrukcją). Nie jest to powszechne rozróżnienie w SE w świecie rzeczywistym, ale widziałem to w tekstach użytkowników.

Tak czy inaczej, nie ma na to właściwej odpowiedzi. Preferencje dla jednego lub drugiego (jeśli w ogóle są preferencje) to coś, czego spodziewałbym się bardzo różnić między językami, projektami i organizacjami; tak jak w przypadku wszystkich konwencji kodu.

Dodam tylko, że całe twierdzenie, że „długie operacje nie są bardziej podatne na błędy niż krótkie operacje”, nie jest ściśle prawdziwe. Oprócz faktu, że większa liczba kodów równa się większej potencjalnej przestrzeni błędów, oczywiste jest, że podzielenie kodu na segmenty sprawi, że błędy będą łatwiejsze do uniknięcia i łatwiejsze do zlokalizowania. W przeciwnym razie nie byłoby powodu, aby w ogóle rozbijać kod na części, z wyjątkiem powtórzeń. Być może jest to jednak prawdą tylko wtedy, gdy wspomniane segmenty są wystarczająco dobrze udokumentowane, aby można było określić wyniki wywołania operacji bez czytania lub śledzenia rzeczywistego kodu (projekt na podstawie umowy oparty na specyfikacjach, a nie konkretnej zależności między obszarami kodu).

Ponadto, jeśli chcesz, aby dłuższe operacje działały dobrze, możesz zastosować bardziej surowe konwencje kodu w celu ich obsługi. Rzutowanie instrukcji return w środku operacji może być odpowiednie dla krótkiej operacji, ale w dłuższych operacjach może to stworzyć dużą sekcję kodu, która jest warunkowa, ale oczywiście nie zależy od szybkiego odczytu (tylko na przykład).

Sądzę więc, że to, który styl jest mniej prawdopodobnym koszmarem wypełnionym błędami, będzie w dużej mierze zależeć od konwencji, których przestrzegasz w pozostałej części kodu. :)

Trixie Wolf
źródło
1

IMHO, nie powinieneś używać paska przewijania, aby odczytać swoją funkcję. Gdy tylko będziesz musiał przesunąć pasek przewijania, potrzeba więcej czasu, aby zrozumieć, jak działa ta funkcja.

W związku z tym zależy to od zwykłego środowiska programistycznego pracy zespołu (rozdzielczość ekranu, edytor, rozmiar czcionki itp.). W latach 80. było to 25 linii i 80 kolumn. Teraz w moim edytorze wyświetlam prawie 50 wierszy. Liczba wyświetlanych kolumn nie zmieniła się, ponieważ podzieliłem ekran na dwie części, aby wyświetlać dwa pliki naraz.

W skrócie, zależy to od konfiguracji twoich współpracowników.

Jérôme Pouiller
źródło
2
Czy to nie było wtedy 24 linii? Mam na myśli terminale 3270 lub 9750, gdzie 25. był linią statusu. Po tym nastąpiły końcowe emulacje.
ott--
niektóre systemy / edytory miały od 40 do 50 linii. Obecnie 150 linii nie jest rzadkością, a ponad 200 jest wykonalnych, więc to nie jest tak naprawdę dobry wskaźnik.
Móż
Używam ekranu w orientacji pionowej, widzę jednocześnie 200 wierszy kodu.
Calmarius
a jeśli nie używam żadnych
podziałów
1

Myślę, że odpowiedź TomTom była zbliżona do tego, jak się z tym czuję.

Coraz bardziej odczuwam złożoność cykliczną niż linie.

Zwykle dążę do uzyskania nie więcej niż jednej struktury kontrolnej na metodę, z wyjątkiem wielu pętli potrzebnych do obsługi tablicy wielowymiarowej.

Czasami umieszczam jednowierszowe ifs w przypadkach przełączania, ponieważ z jakiegoś powodu są to przypadki, w których podział przeszkadza, a nie pomaga.

Zauważ, że nie liczę logiki wartownika przed tym limitem.

Loren Pechtel
źródło
Wykazano, że złożoność cykliczna, przy dużych ilościach rzeczywistego kodu produkcyjnego, jest BARDZO silnie skorelowana z surowym SLOC, dzięki czemu obliczanie złożoności cyklicznej jest całkowitą stratą czasu, energii i cykli zegara.
John R. Strohm,
@ JohnR.Strohm Mówię o metodzie, a nie ogólnie. Jasne, na dużym obrazie jest on wysoce skorelowany - pytanie brzmi, jak podzielić ten kod na metody. 10 metod na 100 linii lub 100 metod na 10 linii nadal będzie miało taki sam ogólny poziom SLOC i złożoność, ale z pierwszą z nich będzie znacznie trudniej pracować.
Loren Pechtel,
ja też. Badanie korelacji dotyczyło WIELU kodu i WIELU procedur. (Było to jedno z dużych publicznych repozytoriów.)
John R. Strohm,
-3

W OOP wszystkie rzeczy są przedmiotem i są te funkcje:

  1. Wielopostaciowość
  2. Abstrakcja
  3. Dziedzictwo

Kiedy przestrzegasz tych reguł, twoje metody są zwykle małe, ale nie istnieją żadne reguły dla małych lub bardzo małych (np. 2-3 wiersze) reguł. Zaletą małej metody (małej jednostki, np. Metody lub funkcji) są:

  1. lepiej czytelny
  2. utrzymać się lepiej
  3. naprawiono błąd lepiej
  4. zmienia się lepiej
Sam
źródło