Czy powinienem dzielić długie funkcje na mniejsze, nawet jeżeli jestem prawie pewien, że nigdy nie zostaną wykorzystane ponownie?

Właśnie obejrzałem filmik gościa z funfunfunction Straight-line code over functions i mam mieszane uczucia. Do tej pory napotykałem rzeczy typu:

• keep the methods (functions, procedures, …) in your code short and have each of them do only one thing
• A comment is an apology. A comment is an apology for not choosing a more clear name, or a more reasonable set of parameters, or for the failure to use explanatory variables and explanatory

Jak ktoś czytał wujka Boba i spółkę to wiecie o co chodzi.

Jak mam być szczery to dla mnie dużo czytelniejsze są mniejsze funkcje po kilka linijek niż jeden wielki okomentowany kloc. Jest to mniej przytłaczające jak człowiek na to patrzy. Zamiast 200 linijek jest mała, słodka, niewinna funkcja na 5 linii z innymi wywołaniami. Poza tym jak patrze na taki kod, to nie musze czytać wszystkiego. Wchodzę tylko do tych funkcji, które mnie interesują.

Co o tym myślicie? Jakie macie przemyślenia po obejrzeniu tego?

Chyba, że źle zrozumiałem ten filmik, to proszę o sprostowanie.

Wydaje mi się, że gość w tym filmiku rozwiązuje niewłaściwy problem - owszem sztuczne rozbijanie na funkcje splątanego kodu nic nie wnosi, ale nie o to chodzi w dzieleniu na funkcje wg mnie. Takiemu dzieleniu powinien towarzyszyć refactor. Wydaje mi się, że cała rozkmina wynika z tego, że kod jest do bólu imperatywny i ma dużo efektów ubocznych. Spróbuj przetestować to jednostkowo ;) Jak masz deklaratywny kod (jakiś React czy coś) to nie masz takich problemów.

Także intuicja Cię nie zawodzi - rozbijanie na funkcje jest ogólnie dobre, ale nie jest celem samym w sobie (tu się z autorem filmiku zgadzam), tyle, że autor pomija tu zalety prawidłowego rozbicia na funkcje - przede wszystkim testowalność i reużywalność (no i jak nie może myśleś o funkcji w oderwaniu od reszty, to powinien ją do takiego stanu doprowadzić).

Funkcja ma robić jedna rzecz, nieważne czy jest wielokrotnie używana czy nie.