Kiedy funkcja jest zbyt długa? [zamknięte]

Oto lista czerwonych flag (w żadnej konkretnej kolejności), które mogą wskazywać, że funkcja jest zbyt długa:

1. Deeply nested control structures: np. for-loops 3 levels deep lub nawet tylko 2 levels deep with nested if-statements that have complex conditions.

2. Too many state-defining parameters: By state-defining parameter , mam na myśli parametr funkcji, który gwarantuje określoną ścieżkę wykonania przez funkcja. Uzyskaj zbyt wiele tego typu parametrów i masz kombinatoryczną eksplozję ścieżek wykonania (zwykle dzieje się to w tandemie z #1).

3. Logika, która jest powielana w innych metodach: słabe ponowne użycie kodu jest ogromnym wkładem w monolityczny kod proceduralny. Wiele takich powielanie logiki może być bardzo subtelne, ale po ponownym uwzględnieniu, efekt końcowy może być znacznie bardziej elegancki.

4. Nadmierne sprzężenie międzyklasowe : to brak właściwej enkapsulacji powoduje, że funkcje są związane z cechami intymnymi innych klas, a więc ich wydłużenie.

5. Niepotrzebne narzuty: Komentarze wskazujące oczywiste, głęboko zagnieżdżone klasy, zbędne gettery i settery dla prywatnych zagnieżdżonych zmiennych klas oraz niezwykle długie nazwy funkcji/zmiennych mogą tworzyć szum składniowy w powiązanych funkcjach, który ostatecznie zwiększy ich długość.

6. Twój masywny wyświetlacz klasy deweloperskiej nie jest wystarczająco duży, aby go wyświetlić: W rzeczywistości dzisiejsze wyświetlacze są na tyle duże, że funkcja znajdująca się w dowolnym miejscu blisko swojej wysokości jest prawdopodobnie zbyt długa. Ale jeśli jest to większe , to jest to dymiąca Broń, że coś jest nie tak.

7. Nie można od razu określić celu funkcji: Ponadto, gdy rzeczywiście zrobić określić jej cel, jeśli nie można podsumować tego celu w jednym zdaniu lub zdarzy się mieć ogromny ból głowy, to powinna być wskazówka.

Podsumowując, funkcje monolityczne mogą mieć daleko idące konsekwencje i często są objawem poważnych braków konstrukcyjnych. Ilekroć napotykam kod, który jest absolutną radością do czytania, jego elegancja jest natychmiast widoczna. I zgadnij co: funkcje są często bardzo krótkie.

Myślę, że jest ogromne zastrzeżenie do mantry "zrób tylko jedną rzecz" na tej stronie. Czasami Robienie jednej rzeczy żongluje wieloma zmiennymi. Nie dziel długiej funkcji na kilka mniejszych funkcji, jeśli mniejsze funkcje mają długie listy parametrów. Robi to po prostu zamienia pojedynczą funkcję w zbiór wysoce sprzężonych funkcji bez rzeczywistej wartości indywidualnej.

Funkcja powinna robić tylko jedno. Jeśli robisz wiele małych rzeczy w funkcji, zrób każdą małą rzecz funkcją i wywołaj te funkcje z funkcji long.

To, czego tak naprawdę nie chcesz zrobić, to skopiować i wkleić co 10 linii swojej długiej funkcji do krótkich funkcji (jak sugeruje twój przykład).

Zgadzam się, że funkcja powinna robić tylko jedną rzecz, ale na jakim poziomie jest ta jedna rzecz.

Jeśli twoje 60 linijek osiąga jedną rzecz (z perspektywy programów) i elementy, które składają się na te 60 linijek, nie będą używane przez nic innego, to 60 linijek jest w porządku.

Nie ma realnej korzyści z rozbicia go, chyba że można rozbić go na betonowe kawałki, które stoją same. Metryką do użycia jest funkcjonalność, a nie linie kodu.

I have worked w wielu programach, w których autorzy wzięli tylko jedną rzecz do ekstremalnego poziomu, a wszystko skończyło się, aby wyglądało to tak, jakby ktoś wziął granat do funkcji/metody i wysadził go na dziesiątki niepowiązanych elementów, które są trudne do naśladowania.

Podczas wyciągania elementów tej funkcji należy również wziąć pod uwagę, czy będzie dodawanie niepotrzebnych kosztów i uniknąć przekazywania dużych ilości danych.

Uważam, że kluczowym punktem jest szukanie możliwości ponownego użycia w tej długiej funkcji i wyciągnij te części. To, co pozostało, to funkcja, niezależnie od tego, czy ma ona długość 10, 20 czy 60 linii.

60 linii jest duże, ale nie za długie dla funkcji. Jeśli zmieści się na jednym ekranie w edytorze, możesz zobaczyć to wszystko na raz. To naprawdę zależy od tego, co funkcje robią.

Dlaczego mogę rozbić funkcję:

• It is too long
• sprawia, że kod jest łatwiejszy do utrzymania, dzieląc go i używając znaczących nazw dla nowej funkcji
• funkcja nie jest spójna
• części funkcji są użyteczne same w sobie.
• kiedy trudno jest wymyślić z sensowną nazwą dla funkcji (prawdopodobnie robi za dużo)

Rozmiar OK rozmiar ekranu (więc idź dostać duży pivot panoramiczny i obrócić go)... :-)

Żarty na bok, jedna logiczna rzecz na funkcję.

A pozytywne jest to, że testowanie jednostkowe jest naprawdę dużo łatwiejsze do zrobienia z małymi funkcjami logicznymi, które robią 1 rzecz. Duże funkcje, które robią wiele rzeczy, są trudniejsze do zweryfikowania!

/Johan

Zasada: jeśli funkcja zawiera bloki kodu, które robią coś, co jest nieco oderwane od reszty kodu, umieść ją w oddzielnej funkcji. Przykład:

function build_address_list_for_zip($zip) {

    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

function fetch_addresses_for_zip($zip) {
    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }
    return $addresses;
}

function build_address_list_for_zip($zip) {

    $addresses = fetch_addresses_for_zip($zip);

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

To podejście ma dwie zalety:

1. Za każdym razem, gdy potrzebujesz pobrać adresy dla określonego kodu pocztowego, możesz skorzystać z łatwo dostępnej funkcji.

2. Kiedy będziesz musiał ponownie przeczytać funkcję build_address_list_for_zip() wiesz, co zrobi pierwszy blok kodu (pobiera adresy dla określonego kodu pocztowego, przynajmniej to, co można uzyskać z nazwy funkcji). Jeśli zostawisz kod zapytania w linii, najpierw musisz przeanalizować ten kod.

[z drugiej strony (zaprzeczę, że ci to powiedziałem, nawet pod torturą): jeśli czytasz dużo o optymalizacji PHP, możesz wpaść na pomysł, aby utrzymać liczbę funkcji jak najmniejszą, ponieważ wywołanie funkcji jest bardzo, bardzo drogie w PHP. Nie wiem o tym, bo nigdy zrobił jakieś benchmarki. W takim przypadku prawdopodobnie lepiej byłoby nie stosować się do żadnej z odpowiedzi na swoje pytanie, jeśli aplikacja jest bardzo "wrażliwa na wydajność"; -)]

Rzuć okiem na cyklomatykę McCabe ' a, w której rozkłada swój kod na wykres, gdzie "każdy węzeł na wykresie odpowiada blokowi kodu w programie, w którym przepływ jest sekwencyjny, a łuki odpowiadają gałęziom pobranym w programie."

Teraz wyobraź sobie, że Twój kod nie ma funkcji/metod; jest to tylko jeden ogromny rozrost kodu w postaci wykresu.

Chcesz podzielić tę sprawl na metody. Rozważ, że kiedy to zrobisz, będzie pewna liczba bloków w każda metoda. Tylko jeden blok każdej metody będzie widoczny dla wszystkich innych metod: pierwszy blok (Zakładamy, że będziesz mógł przejść do metody tylko w jednym punkcie: pierwszy blok). Wszystkie pozostałe bloki w każdej metodzie będą informacjami ukrytymi w tej metodzie, ale każdy blok w metodzie może potencjalnie przeskoczyć do dowolnego innego bloku w tej metodzie.

Aby określić, jaki rozmiar powinny mieć twoje metody pod względem liczby bloków na metodę, możesz zadać jedno pytanie jak wiele metod powinienem mieć, aby zminimalizować maksymalną potencjalną liczbę zależności (MPE) między wszystkimi blokami?

Tę odpowiedź daje równanie. Jeśli r jest liczbą metod minimalizujących MPE układu, A n jest liczbą bloków w układzie, to równanie wynosi: r = sqrt (n)

I można pokazać, że daje to liczbę bloków na metodę, również sqrt (n).

Moja osobista heurystyka polega na tym, że jest za długa, jeśli nie mogę zobaczyć całości bez przewijania.

Pamiętaj, że możesz skończyć na re-faktoringu tylko dla re-faktoringu, potencjalnie czyniąc kod bardziej nieczytelnym niż był w pierwszej kolejności.

Mój były kolega miał dziwną zasadę, że funkcja / metoda musi zawierać tylko 4 linijki kodu! Starał się trzymać tego tak sztywno, że jego nazwy metod często stały się powtarzalne i bez znaczenia, a połączenia stały się głęboko zagnieżdżone i mylące.

Więc moja własna mantra stała się: jeśli nie możesz wymyślić przyzwoitego nazwa funkcji/metody dla fragmentu kodu, który przeliczasz, nie przejmuj się.

Głównym powodem, dla którego zwykle rozbijam funkcję, jest albo to, że jej fragmenty są również składnikami innej pobliskiej funkcji, którą piszę, więc wspólne części zostają uwzględnione. Ponadto, jeśli używa wielu pól lub właściwości z innej klasy, istnieje duża szansa, że odpowiedni fragment może zostać podniesiony hurtowo i jeśli to możliwe, przeniesiony do innej klasy.

Jeśli masz blok kodu z komentarzem u góry, rozważ wyciągnięcie go do funkcji, z nazwy funkcji i argumentów ilustrujące jej przeznaczenie oraz zastrzegające komentarz do uzasadnienia kodu.

Jesteś pewien, że nie ma tam żadnych elementów, które mogłyby się przydać gdzie indziej? Co to za Funkcja?

Moim zdaniem odpowiedź brzmi: kiedy robi za dużo rzeczy. Twoja funkcja powinna wykonywać tylko działania, których oczekujesz od nazwy samej funkcji. Inną rzeczą do rozważenia jest to, czy chcesz ponownie użyć niektórych części swoich funkcji w innych; w tym przypadku może być użyteczne podzielenie go.

Zwykle rozbijam funkcje przez konieczność umieszczania komentarzy opisujących następny blok kodu. To, co wcześniej było w komentarzach, teraz przechodzi do nowej nazwy funkcji. To nie jest trudna zasada, ale (dla mnie) miła zasada. Lubię kod mówiący za siebie lepiej niż ten, który wymaga komentarzy (jak się dowiedziałem, że komentarze Zwykle kłamią)

Zwykle używam podejścia testowego do pisania kodu. W tym podejściu wielkość funkcji jest często związana z ziarnistością testów.

Jeśli twój test jest wystarczająco skoncentrowany, to doprowadzi Cię do napisania małej funkcji skupionej, aby przejść test.

To również działa w przeciwnym kierunku. Funkcje muszą być wystarczająco małe, aby skutecznie testować. Więc podczas pracy z kodem starszym często stwierdzam, że rozkładam większe funkcje w celu przetestowania różnych części.

Zazwyczaj zadaję sobie pytanie "Jaka jest odpowiedzialność tej funkcji" i jeśli nie mogę określić odpowiedzialności w jasnym zwięzłym zdaniu, a następnie przetłumaczyć to na mały skoncentrowany test, zastanawiam się, czy funkcja jest zbyt duża.

Jest to częściowo kwestia gustu, ale jak to określić, staram się zachować moje funkcje z grubsza tylko tak długo, jak zmieści się na moim ekranie w jednym czasie (maksymalnie). Powodem jest to, że łatwiej jest zrozumieć, co się dzieje, jeśli możesz zobaczyć całość na raz.

Kiedy koduję, jest to mieszanka pisania długich funkcji, a następnie refaktoryzacji, aby wyciągnąć bity, które mogą być ponownie użyte przez inne funkcje i pisania małych funkcji, które wykonują dyskretne zadania, gdy idę.

Nie wiem że istnieje jakaś dobra lub zła odpowiedź na to (np. możesz rozliczyć się na 67 liniach jako twój max, ale mogą być chwile, kiedy warto dodać kilka innych).

Przeprowadzono gruntowne badania na ten temat, jeśli chcesz mieć jak najmniej błędów, Twój kod nie powinien być zbyt długi. Ale nie powinno być też zbyt krótkie.

Nie zgadzam się, że metoda powinna zmieścić się na wyświetlaczu w jednym, ale jeśli przewijasz w dół o więcej niż stronę, to metoda jest zbyt długa.

Zobacz optymalna wielkość klasy dla Oprogramowanie obiektowe do dalszej dyskusji.

Napisałem wcześniej 500 funkcji liniowych, jednak były to tylko duże polecenia przełączania do dekodowania i odpowiadania na wiadomości. Kiedy Kod pojedynczej wiadomości stał się bardziej złożony niż pojedynczy if-then-else, wyodrębniłem go.

Zasadniczo, chociaż funkcja wynosiła 500 linii, niezależnie utrzymywane regiony miały średnio 5 linii.

Jeśli ma więcej niż trzy gałęzie, oznacza to, że funkcja lub metoda powinny być rozdzielone, aby enkapsulować logikę rozgałęzień w różnych metodach. Każda pętla for, Instrukcja if, itd. nie jest wtedy postrzegana jako gałąź w wywołującej metodzie. Cobertura dla kodu Javy (i jestem pewien, że są inne narzędzia dla innych języków) oblicza liczbę if, itp. w funkcji dla każdej funkcji i sumuje ją dla "średniej złożoności cyklomatycznej". Jeśli funkcja / metoda ma tylko trzy branches, dostanie 3 na tej metryce, co jest bardzo dobre. Czasami trudno jest przestrzegać tych wytycznych, a mianowicie do walidacji danych wejściowych użytkownika, jednak umieszczenie gałęzi w różnych metodach pomaga nie tylko w rozwoju i utrzymaniu, ale także w testowaniu, ponieważ dane wejściowe do metod, które wykonują rozgałęzienie, mogą być łatwo analizowane, aby zobaczyć, jakie dane wejściowe muszą być dodane do przypadków testowych, aby pokryć gałęzie, które nie zostały pokryte - jeśli wszystkie gałęzie znajdowały się w jednym miejscu. metoda, wejścia musiałyby być śledzone od początku metody, co utrudnia testowalność.

Podejrzewam, że znajdziesz na ten temat wiele odpowiedzi.

Prawdopodobnie podzieliłbym to na podstawie logicznych zadań, które były wykonywane w ramach funkcji. Jeśli wydaje ci się, że Twoje opowiadanie zamienia się w powieść, sugerowałbym znalezienie i wyodrębnienie odrębnych kroków.

Na przykład, jeśli masz funkcję, która obsługuje jakieś wejście łańcuchowe i zwraca wynik Łańcuchowy, możesz podzielić funkcję na podstawie logiki, aby podzielić Łańcuch Na części, logikę na dodaj Dodatkowe znaki i logikę, aby połączyć je z powrotem w sformatowany wynik.

Krótko mówiąc, to, co sprawia, że Twój kod jest czysty i łatwy do odczytania (czy to po prostu przez zapewnienie, że twoja funkcja ma dobre komentowanie lub łamanie go), jest najlepszym podejściem.

Zakładając, że robisz jedną rzecz, Długość będzie zależała od:

• co robisz
• jakiego języka używasz
• ile poziomów abstrakcji trzeba sobie poradzić w kodzie

60 linii może być zbyt długie lub może być w sam raz. podejrzewam jednak, że może to być zbyt długie.

Jedna rzecz (i to powinno być oczywiste z nazwy funkcji), ale nie więcej niż ekran pełen kodu, niezależnie od tego. I nie krępuj się, aby zwiększyć rozmiar czcionki. A jeśli masz wątpliwości, zmień go na dwie lub więcej funkcji.

Rozbudowując ducha tweeta od wujka Boba jakiś czas temu, wiesz, że funkcja staje się zbyt długa, gdy czujesz potrzebę umieszczenia pustej linii między dwoma wierszami kodu. Chodzi o to, że jeśli potrzebujesz pustej linii, aby oddzielić kod, jego odpowiedzialność i zakres są oddzielone w tym momencie.

Moim pomysłem jest to, że jeśli muszę zadać sobie pytanie, czy jest za długi, to prawdopodobnie jest zbyt długi. Pomaga w tworzeniu mniejszych funkcji w tym obszarze, ponieważ może pomóc w późniejszym cyklu życia aplikacji.