Cześć ostatnio przerobilem pewien kod na nowy. Wcześniej był tylko w dwóch plikach i miał około 3000 linii kodu A drugi koło 1000. Teraz porozdzielalem kod po kilku folderach i plikach i rozwiązania które przerobilem z tego co widzę do wersji finałowej mogą przekroczyć linię kodu ze starej wersji, coprawda teraz każdą metodą jest komentowana, wtedy nie, więc to też ma znaczenie. Ale ogólnie, czy to że kod jest dłuższy ale porozdzielany na mniejsze fragmenty w różnych plikach też jest dobre ?
0
3
Nie wiem jak ten kod wyglądał, ale sądząc po tym, że dodałeś komentarze do każdej metody, to zgaduję, że niezbyt się udał ten refaktor...
0
Generalnie ja bym się ilością linii kodu raczej nie sugerował (jako całością), bo jeśli faktycznie coś ma być uproszczone kosztem jakości to to też sensu nie ma.
Najpierw sprawdziłbym czy Twoje klasy spełniają zasady solid i czy są np. single responsibility itp. Jeśli tak to to że wyszło tego więcej niż pierwotnie wcale nie oznacza że jest to gorsze czy złe samo w sobie. Inna kwestia to że martwią mnie te komentarze do metod. Mówisz o dokumentacji JavaDoc czy to są po prostu jakieś komentarze dla "ułatwienia" zrozumienia kodu?
5
Dobry kod nie musi być krótki (w sensie całości kodu) tylko czytelny.
Zwykle refaktor takich gigantycznych klocków powoduje wzrost ilości kodu, ale kod jest lepszy. O ile nie damy się zwariować to zwykle krótsze metody / klasy / pliki są lepsze, bo wiadomo gdzie dokładnie coś jest. Otwierasz dany plik i masz tam niewiele kodu, ale jest on mocno spójny (dotyczy tego samego). Tak samo czytając krótką metodę łatwo zrozumieć co ona robi.
1
Ilość znaczących linii kodu możesz łatwo policzyć za pomocą: https://github.com/AlDanial/cloc
0
Nie wiem jak ten kod wyglądał, ale sądząc po tym, że dodałeś komentarze do każdej metody, to zgaduję, że niezbyt się udał ten refaktor
tzn. nie do wszystkich, sa to tylko komentarze jsdoc, bo pisze to w jsie. do niektoych jest napisana dluzsza puenta jak co dziala i do czego sie stosuje, w takich bardziej rzeczowych metodach. Generalnie metod powstalo dosc sporo takich krotkich bo wepchnalem tam niektore warunki, ktore wczesniej lataly sobie po calym kodzie, teraz jest to w metodzie z nazwa.
Moze podam taki psedo przyklad co na przyklad zmienilem i to jest dluzsze rozwiazanie, ale czytelniejsze (tak mi sie wydaje). Wczesniej byla jedna funkcja opdowiadajaca za jakas tam rzecz, bylo to dosc niewielkie. Niestety "byznes" i czas pokazal, ze ta metoda jest niedokonca dobra, doszlo kilka trybow napisanych w nested if's. Teraz natomiast mam pewna fasade, ktora udostepnia jakies tam operacje dla roznych trybow. Teraz kazdy tryb to osobna aplikacja (klasa / metoda), jak kto woli, bo mimo podobienstw, sa znaczace roznice i robienie if / else if wydawalo mi sie dosc slabe.
2
Zależy od języka. Są języki bardziej zwięzłe i są takie które są bardzo "rozgadane" (Delphi, Java, ASM). Porównaj sobie rozwiązania na Rosetta Code.
Długość całego kodu nie przekłada się na jakość.
Długość pojedynczych funkcji - tak. Zwykle długa funkcja (>50 linii) oznacza nieczytelność kodu.
Długość klas - też. Im więcej kodu w jednej klasie tym gorzej. Poczytaj o "Spójności oprogramowania" (Cohesion).
Zwykle jeśli musisz dodać komentarz oznacza to że:
a) nazwa klasy / funkcji / parametru jest nieczytelna
b) struktura klasy jest nieczytelna
c) jednostka funkcyjna (np. klasa, funkcja) jest za długa
d) wyciągasz dane wejściowe do funkcji gdzieś bokiem lub robisz jakiś nieoczywisty efekt uboczny
Brak komentarzy może oznaczać:
a) że nie będziesz wspierał w przyszłości własnego kodu
b) Twój kod jest tak dobry że inni mogą spędzić parę godzin na jego analizie żeby się czegoś nauczyć
c) Twój kod rzeczywiście jest dobry i nie wymaga wyjaśnień
0
50 linii to taki limit przy którym da się żyć, niestety w kodzie z którym pracuję to raczej "nice to have". W zasadzie to się z Tobą zgadzam - niewazne jaki system by to nie byl uwazasz ze metoda na ponad 50 linii kodu to zle zaprojektowana klasa / metoda / whatever ?