Czy istnieje optymalna liczba wierszy kodu na funkcję? [Zamknięte]

18

Funkcje służą nie tylko do zminimalizowania powielania kodu - służą również do dzielenia długiej funkcji na mniejsze w celu zwiększenia czytelności, a także do komentowania kodu. Jednak to wzmocnienie nie jest wprost odwrotnie proporcjonalne do liczby LOC na funkcję lub metodę; w przeciwnym razie mielibyśmy tony funkcji, z których każda zawiera tylko jedną linię lub dwie kody.

Doprowadziło mnie to do zastanowienia: czy istnieje optymalna liczba LOC na funkcję? Jeśli tak, co to jest i czy różni się między językami?

functions

— gablin
źródło

6

Zobacz kod Complete Vol. 2 autorstwa Mitcha McConnella, rozdział 7, sekcja 4, aby dobrze się bawić.

— Peter Turner,

2

@Peter - Myślę, że masz na myśli „Steve McConnell”

— JohnFx

Tak, zabawne, że napisałbym to, patrząc na książkę… Wasnt Mitch McConnell Pres. Szef sztabu Busha?

— Peter Turner,

3

Liczba ta prawie na pewno różni się w zależności od języka: byłbym zaskoczony, widząc 6-liniową klauzulę Prolog, a jednocześnie jestem całkowicie w porządku z 20-liniową metodą Delphi. Moja odpowiedź poniżej dotyczy Smalltalk, który wykorzystuje środowisko do zachęcania do krótkich metod.

— Frank Shearar,

1

@ Peter Turner: Hm ... S1 do S15 i I1 do I11. Wygląda na to, że myli zmienne tymczasowe z rejestrami. ^^

— gablin

33

Zamiast liczby linii, użyłbym kryteriów, że każda funkcja powinna robić tylko jedną rzecz i robi to dobrze.

— grokus
źródło

Tak, jeśli mamy jednostkę pracy, nie chcę przechodzić między 50 funkcjami, aby uzyskać najświeższe informacje o tym, co się dzieje. Jeśli odpowiednio rozdzielisz swoje funkcje za pomocą tej miary, powinny one mieć naturalnie rozsądny rozmiar.

— ChaosPandion

2

@ChaosPandion: ale twoja jednostka pracy może być prawdopodobnie wyrażona jako sekwencja bardziej elementarnych kroków. Jeśli przeglądasz funkcję, przejrzysz sekwencję kroków, a nie kod każdego kroku.

— Wizard79

2

@Lorenzo - W takim przypadku każdy krok staje się jednostką pracy. Funkcja nadrzędna staje się ogólnym przeglądem jednostek pracy.

— ChaosPandion

1

Tak, to prawda. Hm, pozwólcie, że ponownie sformułuję

— gablin

@gablin, trudno powiedzieć, a także LOC są zależne od języka, ale jeśli zastosujesz się do tej zasady, zwykle kończy się w rozsądnym zakresie, powiedzmy 1 ~ 50.

— grokus

21

Stara zasada mówi, że funkcja powinna być całkowicie widoczna na ekranie, bez potrzeby przewijania.

Podstawową ideą jest to, że jeśli nie możesz spojrzeć na całą funkcję naraz, funkcja jest zbyt złożona i powinieneś podzielić ją na bardziej podstawowe części.

Chociaż ta zasada jest bardzo praktyczna i przydatna, formalna reguła mówi, że powinieneś zachować tylko jeden logiczny krok w funkcji. Funkcja wykonuje tylko elementarne zadanie, jeśli możesz podzielić zadanie na więcej elementarnych elementów, funkcja musi zostać podzielona.

— Wizard79
źródło

21

Ta miara staje się stopniowo coraz bardziej bezużyteczna wraz ze wzrostem średniego rozmiaru / rozdzielczości monitora.

— Adam Lear

2

Nasz programista powiedział właśnie ten przykład innej nocy :)

— cdnicoll

2

@ Anna: cóż, mój monitor ma wysoką rozdzielczość, ale wzrosła także liczba pasków narzędzi / palet / panelu. A potem mogę teraz użyć czcionki o wysokości 14 pt! :)

— Wizard79

4

Rozmiar terminala 24 x 80 nie zmienia się.

— alternatywny

1

nonsens, zasadą jest to, że „widzisz to wszystko bez przewijania”. Z dużym monitorem możesz mieć więcej w swojej funkcji bez naruszania tej reguły, nie oznacza to, że duże monitory mogą wyświetlać tylko małe funkcje (chociaż przy wszystkich paskach narzędzi i oknach właściwości, które posiada IDE, prawdopodobnie nadal jest to prawdą: - ))

— gbjbaanb

15

Nie ma żadnego.

Ekrany stają się coraz większe, a rozmiary czcionek coraz mniejsze. Praktyczne zasady nie działają tak dobrze, gdy ludzie mają kciuki różnej wielkości.

Bądź zwięzły. Jeśli twoja funkcja wykonuje wiele rzeczy, prawdopodobnie dobrym pomysłem jest podzielenie jej na mniejsze.

— Josh K.
źródło

Najmniej możesz powiedzieć, dlaczego uważasz, że moja odpowiedź nie jest przydatna.

— Josh K

7

Myślę, że ktoś cię obraził za użycie tagu h1 .

— ChaosPandion

@Chaos: To podstawowa odpowiedź.

— Josh K

6

Może byłem trochę zbyt subtelny, ale chciałem zasugerować, że nie ma ważnego powodu, by głosować za odrzuceniem twojej odpowiedzi. Ktokolwiek popełnił czyn, miał na to jakiś osobisty powód. Mogą po prostu myśleć, że Josh to okropne imię.

— ChaosPandion

6

Smalltalk ma nieco nietypowy sposób zmniejszania rozmiaru metod. Kiedy piszesz kod, zapisujesz go w widżecie zwanym Przeglądarką. Przeglądarka ma dwie główne części, podzielone poziomo. Twój kod znajduje się w dolnej połowie.

Domyślnie przeglądarka nie jest bardzo duża. Możesz zmieścić 5 lub 6 linii, zanim będziesz musiał zacząć przewijać. Przewijanie jest oczywiście nieco irytujące.

Dlatego w Smalltalk środowisko „zachęca” do pisania krótkich metod, o długości co najwyżej około 6 linii. (To zwykle dużo; Smalltalk to dość zwięzły język.)

— Frank Shearar
źródło

2

Idealna liczba wierszy kodu w metodzie jest zmienna. Zasadniczo chcesz napisać tylko tyle kodu, aby zrobić to, co trzeba zrobić w kontekście definicji funkcji. Myślę o tym jako o zasadzie pojedynczej odpowiedzialności , stosowanej tylko do metody zamiast klasy.

Tam, gdzie metoda ma dużo logiki i szereg kroków do wykonania, wówczas sensowne jest podzielenie metody na kilka odrębnych kroków. Każdy z tych kroków zostanie wyodrębniony zgodnie z potrzebami w nowych metodach.

„w przeciwnym razie dysponowalibyśmy tonami funkcji, z których każda zawiera tylko jeden wiersz lub dwa kody”.

Im mniej każdej metody, tym łatwiej ją zdefiniować i tym łatwiej jest ją zrozumieć i zarządzać. Nie ma nic złego w posiadaniu setek metod, jeśli ich potrzebujesz. Ponadto, zgodnie z SRP , o którym wspomniałem wcześniej, łatwiej jest wyodrębnić nowe klasy, gdy metody zostały rozbite na mniejsze i łatwiejsze do opanowania części.

— S.Robins
źródło

1

Odpowiedź brzmi oczywiście 42 .

Ważne, aby pamiętać: Żadna funkcja nie może nigdy naruszać SRP , lub musisz stawić czoła hiszpańskiej inkwizycji .

Kilka wskazówek, jak zmniejszyć ilość linii:

Czy są komentarze do poszczególnych sekcji? Te sekcje powinny być funkcjami.
Czy istnieją łańcuchy if-else lub instrukcje przełączania poza fabryką / konstruktorem? Twój projekt może wymagać lepszych wzorców projektowych, które pomogą ci rozdzielić obowiązki.
Czy twoje funkcje są łatwe do przetestowania? Ułatw testowanie swoich funkcji, one się rozpadną.
Czy jest złożony i po prostu nie ma ziemi w sigth (1000 potworów liniowych)? Dokonuj refaktoryzacji złomu - to jest refaktoryzacja i nie oszczędzaj go w nadziei, że zdobędziesz wiedzę na temat obowiązków związanych z kodeksami.

— Johannes
źródło

1

Nie spodziewa się, że Hiszpan ... ah bugger, jestem tu trochę spóźniony.

— lewo wokół około

0

Oto kilka wskazówek:

Jeśli masz problem z napisaniem komentarza wyjaśniającego cel i użycie funkcji, jest ona zbyt długa.
Jeśli masz ochotę napisać komentarz wyjaśniający aktywność sekcji kodu w funkcji, funkcja jest za długa.
Jeśli wklejasz kod z innej funkcji, oba są za długie (wyodrębnij ten kod jako osobną funkcję).
Jeśli potrzebujesz konwencji kodowania, aby oddzielić elementy danych klasy od zmiennych lokalnych, funkcja jest za długa, a klasa ma zbyt wiele elementów.
Jeśli musisz robić notatki podczas czytania funkcji, jest ona zbyt długa.

Posiadanie „ton” funkcji, z których każda ma tylko jedną lub dwie linie, niekoniecznie jest złą rzeczą. Odkryłem, że te małe funkcje zostały ponownie wykorzystane znacznie bardziej niż początkowo się spodziewałem.

— Kevin Cline
źródło