Mówię między 1 a 5 liniami. Więcej niż powinieneś usprawiedliwić, wysyłając wiadomość e-mail do reszty zespołu programistów. To pomaga w ponownym użyciu, wymusza dobre nazewnictwo i metody par.Jaki jest dobry średni rozmiar metody?
Masz jakieś uwagi?
Dzięki
Nieco ekstremalnych, myślę, że złożoność cyklometryczne 5 lub mniej jest rozsądny środek aniżeli liczba linii. Zerwanie kodu do mniej niż 5 linii może oznaczać, że będzie on nieczytelny i żmudny. Wiem, że będą różne myśli na ten temat, dlatego ten wątek powinien być zamknięty jako subiektywny.
1 i 5 linii wydaje mi się zbyt małym ograniczeniem. Jeśli tworzysz uproszczone aplikacje biznesowe, które nie przetwarzają dużo, to wydaje się to być w porządku, ale jeśli istnieją jakieś algorytmy lub procesy, często jest o wiele bardziej czytelny (i obsługiwany), aby pisać etapy przetwarzania sekwencyjnie, a nie na wielu metodach lub klas - nawet jeśli jest to logiczne w celu enkapsulacji, sprawdzania poprawności i tak dalej.
5 linii w wielu przypadkach nie jest wystarczające do sprawdzenia poprawności parametrów i iteracji poprzez kolekcję.
Proponuję "o zabawie"; 20 do 30 linii jest idealnych.
Na przykład: to wydaje się ważne dla mnie, ale można rozważyć dobry w 8 liniach:
// Calculates the depth of the layer in the object graph
public int GetIndex()
{
int ct = 0;
ViewLayer pos = this;
while (pos.Parent != null)
{
ct++;
pos = pos.Parent;
}
return ct;
}
(zdaję sobie sprawę, ja otwarcie się do krytyki przez kod księgowania, ale moja statywy punktowe, to jest czytelny kod)
To zbyt długo, powinieneś używać coś w stylu: 'public int GetIndex (ViewLayer pos = this) {\ n return (pos.Parent == null)? 0: 1 + GetIndex (pos.Parent); \ n} \ n' taktowanie w 3 liniach :-) – paxdiablo
To nie jest czysty kod. Czysty kod dla tak trywialnego zadania nie wymagałby komentarza. Po pierwsze, nazwa mogła brzmieć DepthInObjectGraph. Po drugie, może to być rekursywne i przyjmować 1 lub 4 linie, w zależności od tego, czy wolisz, czy/else lub?:. – qertoip
@qertiop - dobra robota, znalazłeś sposób na ulepszenie kodu - coś, co prawie zawsze jest możliwe. czy Twój komentarz dotyczy odpowiedzi, tzn. czy uważasz, że żadna metoda nie powinna być dłuższa niż 1-4 wiersze? –
Rozmiar kodu metody jest błędnym wskaźnikiem dla obowiązków metody. Ta metoda powinna mieć właśnie jedno główne zadanie behawioralne/kreacyjne bez duplikatów kodu.
Myślę, że jest to bardziej skomplikowane.
Po pierwsze, metody mają tendencję do podążania za rozkładem mocy: W każdym projekcie będą dostępne metody, które są tak ogromnie większe od większości innych metod, że średni rozmiar nigdy się nie zbiega.
Po drugie, jeśli musisz wykonać dziesięć wywołań API w celu wykonania jednego określonego zadania, nie ma sensu przerywać tej sekwencji wywołań na dwie metody tylko po to, aby osiągnąć limit wielkości. Kiedy rozbijacie coś na części, musicie podać dwa imiona (lub nawet trzy) zamiast jednego. musisz udokumentować każdą część itd. Dolna linia: mała jest dobra, ale nie śledź jej ślepo. Najlepszą radą jest próba uczynienia każdej metody spójną (skoncentrowaną).
Z pewnością sprawia to, że kod jest trudniejszy w nawigacji i zrozumieniu, A dzwoni B, dzwoni C, następnie E, potem D itp. Nie jestem pewien, jak wymusza to dobre nazewnictwo, mam wystarczająco dużo problemów wymyślanie dobrych opisowych imion dla moich istniejących metod, nigdy nie myśl o jednym kiedykolwiek 5 liniach.
Powoduje także wydłużenie klasy, ponieważ trzeba podpisać metodę, otworzyć i zamknąć klamrę oraz dodatkową linię do odczytu.
Ponadto większość moich instrukcji linq ma ponad 5 linii.
Pozwól, aby wymagania kodu określały, jak długi jest czas.
Czy naprawdę wolisz, aby Twoi twórcy spędzali czas na pisaniu e-maili niż na tworzeniu bazy kodów?
Czy można zastosować 25 metod jednolinijkowych i jedną metodę 100-liniową? – Yellowfog
Tak długo, jak * musi * być, wielkość/liczba linii nie jest tak ważna, jak funkcja ** ma jedną rzecz **, IMO. –
Osobiście nie sądzę, że istnieje zdefiniowana odpowiedź, która jest "poprawna". Ale pomyślałem, że chciałbyś obejrzeć rozmowę, którą "Wujek Bob" Martin zrobił w QCon London w tym roku, gdzie mówił o tym temacie: http://www.infoq.com/presentations/Robert-C.-Martin-Bad -Code – AdaTheDev