Jaka jest dobra praktyka kodowania, kiedy należy utworzyć funkcję / metodę dla małych powtarzalnych segmentów kodu?

Wiele razy podczas pisania większych programów pytałem o to, ile kopii i past ma sens, aby umieścić kod w funkcji lub metodzie i jaka jest dobra zasada? Korzystam z praktycznej reguły składającej się z czterech lub więcej linii i pojawiają się więcej niż dwa razy, a następnie tworzę prostą funkcję / metodę zawierającą ten kod. Czy możesz wymyślić lepszą praktykę lub zaoferować jakieś wskazówki? Jest to raczej ogólne pytanie dotyczące wzoru niż pytanie dotyczące konkretnego języka.

Używam funkcji częściowo jako sposobu na udokumentowanie kodu. Wywołanie funkcji o znaczącej nazwie ułatwia zrozumienie kodu. W niektórych przypadkach nawet funkcja z jedną linią ma sens.

Na przykład w „Czystym kodzie” Robert C. Martin podaje następujący przykład: Który wolisz zobaczyć? To:

// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
    (employee.age > 65))

Albo to?

if (employee.isEligibleForFullBenefits())

Nie zawsze się z nim zgadzam, ale w tym przypadku się zgadzam. Kod powinien być czytelny nie tylko wtedy, gdy go napiszesz i znasz każdy szczegół, ale także o 21:00, kiedy musisz naprawić błędy w cudzym kodzie. Wpatrywanie się w długi stan i próba wykrycia wszystkich podwójnych negatywów nie jest zalecane. Jeśli możesz po prostu nadać mu nazwę (nie tylko warunki, ale każdy napisany kod), staje się to o wiele prostsze.

Nigdy nie żałowałem, że wprowadziłem coś w funkcję, a jeśli martwisz się wydajnością, najpierw profil.

Istnieje powszechne nieporozumienie, że wywołania funkcji należy wykonywać tylko w celu uniknięcia powtarzających się segmentów kodu. Zasadą ogólną jest to, że każda logiczna jednostka pracy powinna zostać przekształcona w funkcję, nawet jeśli jest używana tylko w jednym miejscu. Zwykle prowadzi to do lepszej czytelności i pozwala napisać kod samodokumentujący, w którym nazwy funkcji zastępują komentarze i nie trzeba pisać dodatkowych komentarzy wyjaśniających, co robisz.

Jeśli jest używany w więcej niż jednym miejscu, i

• może się zmienić, lub
• trudno jest to naprawić

następnie uczyń to funkcją lub metodą. Długie fragmenty powtarzającego się kodu, z mojego doświadczenia, naturalnie będą należeć do jednej z tych kategorii (zwykle pierwszej, ale potem kategorie bardzo często się pokrywają;). Oczywiście wszystko, co musi znajdować się w interfejsie, jest również funkcją / metodą samą w sobie.

Niemal zawsze, szczególnie jeśli każdy duplikat reprezentuje tę samą operację z koncepcyjnego punktu widzenia. Jeśli jest wykonywany w ten sam sposób, ale na różnych typach, wykonaj ogólną implementację.

Jedynym powodem, dla którego nie mogę tego wymyślić, jest konserwacja: czasem wygodniej byłoby uniknąć tworzenia zależności między oddzielnymi rzeczami, nawet kosztem pewnego powielania.

Poszukiwanie „ refaktoryzacji ” doprowadzi cię do wielu zasobów dla „najlepszych praktyk” branży dla tego bardzo powszechnego procesu. Dość sławny artykuł „ Raz i tylko raz” jest świetnym odniesieniem historycznym wyjaśniającym, co niektórzy uważają za „najlepsze praktyki” w związku z wątpliwościami wynikającymi z pytania. Ponadto, nawet bardziej ogólna koncepcja jest znana jako Don't Repeat Yourself (DRY) . Aby uzyskać naprawdę dogłębny zestaw odpowiedzi na twoje pytanie, przeczytaj świetny klasyk Martina Fowlera Refactoring: Improving Design of Existing Code , który zawiera jedne z najbardziej znanych porad dotyczących refaktoryzacji , które intuicyjnie próbujesz osiągnąć !

Jeśli kod zostanie dokładnie powtórzony w więcej niż jednym miejscu, a powtarzająca się sekcja nie zmieni się w najbliższej przyszłości, wówczas podzielę go na funkcję.

Zależy to od charakteru spójności powtarzanego kodu. Jeśli powtarzająca się sekcja kodu wykonuje określoną funkcję, to jest doskonałym kandydatem do przekształcenia w metodę, częściowo z powodu zasady DRY , częściowo dlatego, że jeśli funkcja wymaga optymalizacji lub korekty, to jest tylko jedna sekcja kodu do obsługi.

Jeśli skojarzenie jest przypadkowe, lepiej jest powtórzyć kod niż przekształcić go w metodę. Jeśli musisz dodać coś na środku jednej z sekwencji kodu, aby zaspokoić jedno z zastosowań tego fragmentu kodu, jeśli jest to metoda, wprowadzona zmiana może wpłynąć na inne zastosowania tej metody.

Zobacz artykuł w Wikipedii na temat spójności kodu .

Musisz rozróżnić funkcje w sensie programowania strukturalnego i metody klasy.

W twoim przykładzie pokazałeś metodę, która jako taka nie powinna być kodowana w linii.

może być konieczne sprawdzenie poprawności ciągu, aby sprawdzić, czy jest to liczba, czy nie, w tym przypadku używasz funkcji i zastosowanie ma większość poprzednich odpowiedzi.

To rozróżnienie jest ważne szczególnie w dużych projektach.

W miarę możliwości staraj się oddzielać reguły biznesowe (czyli metody) od algorytmów obliczeniowych (które są czysto funkcjami programowania).