Jak ważne jest zmniejszenie liczby wierszy w kodzie?

85

Jestem programistą, który pracuje na J2SE (core Java).
Często podczas recenzji kodu jesteśmy proszeni o zmniejszenie liczby wierszy w naszym kodzie.

Nie chodzi o usuwanie zbędnego kodu, chodzi o przestrzeganie stylu, który koncentruje się na robieniu tych samych rzeczy przy mniejszej liczbie linii w kodzie, a ja wierzę w przejrzystość kodu, nawet jeśli oznacza to zwiększenie liczby linii.

Jak myślisz, jaki jest właściwy sposób robienia rzeczy?
Jeśli LOC (wiersze kodu) jest małą liczbą, jak wpływa na kod? Jeśli LOC jest większą liczbą, jak wpływa na kod?

przykład ze strony: „javaranch” -

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

VS

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}
Ankit
źródło
63
Mogę przekształcić dowolny plik Java w pojedynczy wiersz kodu ( s/\n/ /g), co nie znaczy, że będzie nawet zdalnie czytelny
maniak ratchet
6
Czy Twoja firma używa LOC do mierzenia produktywności, więc starają się uniemożliwić „granie w system” za pomocą standardów kodowania?
JeffO,
29
To naprawdę by pomogło, gdybyś mógł podać krótki przykład każdego stylu (nie wybrany), więc wszyscy mają jasność co do tego, o czym mówimy. Istnieją skrajności w obu kierunkach; a odpowiedź będzie bardzo zależała od twojego kontekstu.
Daniel B
3
Kiedykolwiek posprzątasz swój pokój, wtedy twoja matka wchodzi i mówi „to nie jest czyste” i wskazuje 10 rzeczy, których nie odłożyłeś. Właśnie to mówią ci w recenzji kodu.
Reactgular
11
Podany przykład jest prawie podręcznikową wersją refaktoryzacji Wprowadzaj zmienną wyjaśniającą , która zwykle zwiększa czytelność i intencję (co jest dobrą rzeczą). Niektórzy twierdzą, że powinieneś przeformułować zmienne na krótkie, jednowierszowe funkcje, ale to prowadzi do skrajności; Powiedziałbym, że twoja wersja jest lepsza od krótkiej zalecanej przez recenzję.
Daniel B

Odpowiedzi:

75

Problem z pomiarami, bez względu na to, jak dobrze są przeznaczone, polega na tym, że sam pomiar przedmiotu powoduje, że jest on ważny, a następstwo, że pomiar przedmiotu nie jest ważny. Konieczne jest zmierzenie tego, co ważne, a nie zmierzenie tego, co nieistotne.

Mierzenie SLOC (co faktycznie robią twoje recenzje), sprawia, że ​​SLOC jest ważny .... Czy SLOC jest ważny? - absolutnie nie, nigdy nie był (poza konkursami zaciemniania programów ), nigdy nie będzie w organizacji komercyjnej.

Zadaj sobie jedno proste pytanie - w jaki sposób „Zmniejszenie SLOC tej procedury” poprawia kod w czyimś kodowaniu. Prawdopodobnie dzieje się w tym przypadku, że SLOC jest używany jako naiwny sposób pomiaru złożoności. Za wszelką cenę należy unikać liczenia łatwych do policzenia ziaren - obiektywnych miar, takich jak SLOC, zamiast liczenia ważnych, ale trudnych do policzenia - np. Czytelności, złożoności itp.

mattnz
źródło
33
Chociaż opis recenzji OP sprawia, że ​​brzmi to trochę bezcelowo, powiedziałbym, że wiersze kodu są często powiązane z trudniejszymi środkami, o których wspominasz. Długie funkcje są często mniej czytelne, a także często mają większą złożoność cykliczną. Tak naprawdę sprowadza się to do tego, czy recenzja naprawdę zaleca przełamanie / skrócenie kodu, który by na tym skorzystał, czy też po prostu zaleca wstawienie wielu legalnych linii.
Daniel B
3
Powiedziałbym, że powodem, dla którego ważne jest zmniejszenie liczby wierszy kodu, jest możliwość wyświetlenia większej liczby funkcji na jednej stronie. Im łatwiej jest wyświetlić metodę lub klasę bez potrzeby przewijania, tym łatwiej jest utrzymać kontekst w głowie.
CLandry
2
@DanielB Długie funkcje są często trudniejsze do obejścia, nie dlatego, że są długie; ale ponieważ próbują robić wiele rzeczy naraz. Na przykład zazwyczaj zaczynają się od sprawdzania poprawności danych wejściowych, a następnie przetwarzania, a następnie sprawdzania alternatywnego przetwarzania, a następnie kolejnego sprawdzania, czy coś niezwiązanego wymaga aktualizacji, a następnie wstawiania procedury, która nie ma nic wspólnego z główną akcją ( jak logika daty, która sprawdza przekroczenie miesiąca i dostosowuje się) i tak dalej. Zanim dotrzesz do końca, nie możesz sobie przypomnieć, na czym polegała klasa.
Edwin Buck,
1
@CLandry: Utrzymanie kontekstu przez dopasowanie go do jednej strony jest bardzo złym powodem do ograniczenia SLOC. Z pewnością łatwiej jest utrzymać kontekst, jeśli kod jest dobrze ułożony i łatwiejszy do odczytania. - Co to jest „strona” 2500 lub 1000 pikseli? Mam monitory 2 * 30 "w portrecie, ale czasami rozwijają się na laptopie.
mattnz
4
Badania, które pokazują (zob. A) LOC === Błędy są dziesiątką. To dobrze znany i akceptowany fakt. To, co nie zostało pokazane (o ile wiem) to (ref b) „Zmniejsz LOC w bazie kodu === Ogranicz liczbę błędów w tej bazie kodu”. Ekstrapolacja (odniesienie a) do roszczenia (odniesienie b) jest nienaukowa. Publikacja artykułu potwierdzającego lub obalającego związek byłaby.
mattnz 17.04.13
84

Zgadzam się z recenzentami kodu, ale z gwiazdką. Każde stwierdzenie, które piszesz w swoim kodzie, jest odpowiedzialnością techniczną - potencjalnym punktem awarii. Jeśli napiszesz metodę z 10 instrukcjami, a twój współpracownik napisze taką, która osiągnie tę samą funkcjonalność z 5 instrukcjami, prawdopodobnie będzie on „lepszy” pod względem prawdopodobieństwa wystąpienia problemów (istnieje dwa razy więcej błędów w kodzie skomplikowane lub problematyczne).

Oto gwiazdka. Nie chodzi o rzeczywistą liczbę wierszy kodu w pomyśle, ponieważ można zmniejszyć liczbę wierszy za pomocą czegoś takiego:

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

To jedna linia kodu, ale jest to miejsce, w którym niesamowita ilość rzeczy może się nie udać. Powiedziałbym więc, że skup się na robieniu jak największej liczby przy najmniejszej liczbie instrukcji - napisz tyle kodu, ile potrzebujesz, aby załatwić sprawę i nic więcej. Przynajmniej myślę, że na tym właśnie polegają Twoi recenzenci kodu.

Osobiście uważam, że trzeba zachować równowagę. Jak powiedziałem, każde napisane przez ciebie oświadczenie jest zobowiązaniem, ale jeśli wyciągnięcie zmiennej lokalnej o nazwie opisowej sprawia, że ​​twoja metoda jest o wiele jaśniejsza i bardziej czytelna, to również należy to uzasadnić. Myślę, że łatwo można wpaść w sytuacje, w których ludzie kłócą się o stosunkowo niewielkie różnice estetyczne, ale ogólnie myślę, że twoi recenzenci mają dobry pomysł - sprzyjają minimalizowaniu liczby rzeczy, które mogą się nie udać.

Erik Dietrich
źródło
4
Zgadzam się - ograniczenie liczby instrukcji może być przydatne do ograniczenia, jednak jeśli przegląd kodu chce zmniejszyć liczbę instrukcji, czy nie powiedzieliby po prostu „mniejszej liczby instrukcji” zamiast „mniejszej liczby wierszy kod".
mattnz
1
@mattnz tylko na pewno, jeśli są pedantyczni.
Dan Neely
2
Z mojego doświadczenia wynika, że ​​ktoś, kto może napisać ten sam algorytm w mniejszej liczbie instrukcji, a) użyje rzeczy, które nie są bardzo powszechne lub niezbyt dobrze zrozumiane, oraz b) wprowadzi więcej przypadków brzegowych, które wymagają testów jednostkowych i mogą wprowadzić błędy. Zakłada to oczywiście, że obaj programiści są w przybliżeniu jednakowo zdolni.
Daniel AA Pelsmaeker,
13
+1 za humorystycznie długi łańcuch wywołań funkcji i podstępny podwójny nawias po violations().
Joe Z.
5
100% +1, więc wiele osób nie rozumie konsekwencji każdego dodatkowego fragmentu kodu, który dodają do bazy kodu, o czym ludzie naprawdę powinni wiedzieć.
Jimmy Hoffa,
32

Posługiwanie się opiniami recenzentów dosłownie nic nie da, ponieważ oczywistym bezpośrednim rezultatem jest promocja zwięzłych jedno-liniowych (niezależnie od limitu długości linii). Uważam jednak, że lekcją, której można się tutaj nauczyć, jest zminimalizowanie kodu .

Innymi słowy, jest to wezwanie do uproszczenia. Jest dość popularne twierdzenie, że kod jest zobowiązaniem, a nie zasobem , więc zmniejszenie jego kwoty przy jednoczesnym zachowaniu funkcjonalności jest szlachetnym wysiłkiem. Można to osiągnąć poprzez bezpośrednie, bardziej przyziemne podejście, które bezpośrednio rozwiązuje problem i preferuje zwięzłe rozwiązania.

Jak powiedział kiedyś Ken Thompson: Jednym z moich najbardziej produktywnych dni było wyrzucenie 1000 linii kodu .

Xion
źródło
21

Zwykle zgadzam się z twoją pozycją „przejrzystości kodu, nawet jeśli oznacza to zwiększenie liczby wierszy”.

Widziałem zbyt wiele jedno-liniowych, które są dość zwięzłe, ale nie od razu widać, co robią. Czytelność jest najważniejsza, ponieważ inni programiści będą musieli zachować Twój kod.

Twierdziłbym, że lepszym celem jest krótka metoda. Nie krótki ze względu na kilka wierszy kodu, ale krótki, ponieważ robią jedną rzecz.

jhewlett
źródło
12

Obecnie pracuję jako starszy programista aplikacji i analityk biznesowy projektu dla dużej firmy i nigdy nie było centrum zainteresowania mojego rozwoju. Uważam jednak, że im bardziej kod może być skondensowany, tym lepiej, ALE nie kosztem możliwości jego szybkiej analizy i poprawienia (lub uzupełnienia). Dla mnie, gdy jesteś odpowiedzialny za aplikacje o krytycznym znaczeniu dla biznesu, które MUSZĄ mieć szeroki poziom skalowalności i być w stanie modyfikować je w locie w środowisku non-stop, zwięzły, łatwy do odczytania kod jest jednym z najważniejszych elementów w rozwoju . Do kredytu odpowiedzi Erika Dietrich , to:

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

byłoby dla mnie całkowicie nie do przyjęcia, jednak zmieniłem wszystkie istniejące kody firm z:

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

do:

value.prop =  boolean ? option1 : option2;

był doskonałym wyborem do zagęszczania kodu, który nie poświęca czytelności.

O ile wpływa to na kod? Nigdy nie zauważyłem wzrostu lub spadku wydajności z, powiedzmy, 100 linii kodu. Prostym faktem jest to, że jest to bardziej proces, który wykorzystujesz do dojścia do produktu końcowego, niż liczba linii potrzebnych, aby tam dotrzeć. Widziałem niektóre procesy napisane bardzo skondensowane, choć nieefektywne, działające inaczej niż dłuższe kody z lepszym przepływem kodu.

Joshua Volearix
źródło
Masz na myślivalue.prop = boolean ? option1 : option2;
Christoffer Hammarström
Ja robię! ... w każdym razie na „skróconym kodzie”.
Joshua Volearix
2
Twój drugi przykład jest szczególnie dobry, ponieważ jest nie tylko prostszy, ale także wyjaśnia, że ​​jest to przypisanie jednej z dwóch opcji, bez efektów ubocznych. Przesłania if-then-elseto; na przykład, zbyt łatwo jest przypisać do innej zmiennej w każdej gałęzi if(co może, ale nie musi być błędem, ale jest trudne do wykrycia).
Andres F.,
Spotkałem środowiska, w których używanie operatora trójskładnikowego było wyraźnie zabronione. Zwykle były to środowiska przechodzące z PL / SQL lub podobnego do Javy, gdzie ludzie bali się tersity ... Jeśli chodzi o twoje stwierdzenie, że pisanie większej ilości kodu nie ma wpływu na wydajność, może być zależne od tego, jaki jest kod. Jeśli na przykład zastąpisz operatora wywołaniem metody, na pewno będzie to miało wpływ (i może być poważny).
jwenting
9

IMO, to zły pomysł, aby mierzyć efektywność kodu przez trywialną liczbę LOC. Jest o wiele więcej tego, co sprawia, że ​​odpowiednio zaprojektowany i skuteczny kod.

Z mojego doświadczenia wynika, że ​​skuteczny kod:

  • nie łamie żadnej z SOLIDNYCH zasad
  • jest czytelny i zrozumiały
  • przechodzi test prostoty Alberta Einsteina: „Wszystko powinno być tak proste, jak to możliwe, ale nie prostsze”.
Dino Octavian
źródło
1
+1 za cytat Einsteina.
Justsalt,
6

Istnieje wiele odpowiedzi, które dotyczą technicznych zalet i wad utrzymywania LOC na niskim poziomie i czy jest to miara jakości oprogramowania o znaczącej jakości. Nie o to chodzi w tym pytaniu. Chodzi o to, jak radzić sobie z zarządzaniem, które kładzie nacisk na naiwne dogmatyczne przestrzeganie określonej ogólnej zasady kodowania.

Niestety, dość często ludzie chwytają się rzeczy, które są dobrą radą, gdy są stosowane we właściwym kontekście i stosowane w sposób pragmatyczny, wyciągają je z tego kontekstu i stosują je dogmatycznie, nie doceniając problemów, które rada ma przede wszystkim złagodzić .

Porady dotyczące utrzymywania LOC na niskim poziomie mają na celu uniknięcie tworzenia metod, które próbują zrobić zbyt wiele za jednym razem, oraz zniechęcenie do tworzenia „klas boga”, które wiedzą zbyt wiele o aspektach projektu, które nie są ich bezpośrednia odpowiedzialność i od których zależą wszystkie pozostałe klasy w systemie. Kolejną zaletą krótszego kodu jest to, że jest on bardziej czytelny, chociaż, jak zauważyłeś, możesz go przesadzić do tego stopnia, że ​​czytelność faktycznie zaczyna cierpieć.

Niska liczba LOC ma oczywiste zalety (małe metody pasują do twojej głowy łatwiej niż duże, mniej rzeczy w kodzie oznacza mniej rzeczy do popełnienia błędu itp.), Ale podlega ona również zasadzie malejących zwrotów. Refaktoryzacja metody 150-liniowej na szereg 20-liniowych to znacznie większa wygrana niż refaktoryzacja metody 10-liniowej na metodę 7-liniową.

Kiedy takie refaktoryzacja odbywa się kosztem jakiegoś innego aspektu dobrego projektowania oprogramowania (takiego jak czytelność), osiągnąłeś punkt, w którym możesz uzasadnić, że tego nie robisz. Usunięcie zmiennych, które nadają kontekst znaczeniu kodu i zastąpienie ich literałami, które tego nie robią, jest bardzo złą rzeczą. Dobry kod prawie nie zawiera literałów. Jednak te zmienne (i nazwane stałe) są wierszami kodu, które nie przyczyniają się bezpośrednio do programu, więc jeśli LOC jest czczony jako jakiś bóg, wówczas takie linie wyjaśniające są na wielkim niebezpieczeństwie, że zostaną przycięte do szybkiej wygranej i niektóre błędne pochwały ze strony kierownictwa.

Uważam, że jesteś wystarczająco mądry, aby to zrozumieć, w rzeczywistości jest to sedno twojego pierwotnego pytania. Problemem nie jest twoje zrozumienie, kiedy redukcja kodu jest dobra, a kiedy nie, problemem jest dogmatyzm w stosowaniu tego, co zwykle jest rozsądną praktyką w sposób bezkrytyczny.

Radzę poświęcić czas na rozmowę z kierownictwem, wyjaśniając swoje stanowisko i dlaczego uważasz, że to, o co jesteś proszony, szkodzi kodowi, a nie pomaga. Staraj się unikać konfrontacji, ale staraj się zachować racjonalność i spokój podczas takiej dyskusji. Ważne jest, aby kierownictwo rozumiało, że programowanie jest działaniem pragmatycznym, a porady dotyczące najlepszych praktyk są przydatne tylko wtedy, gdy są stosowane w sposób pragmatyczny. Najlepsza praktyka jest napisana w książce, nie wyryta w kamieniu, a kiedy jest ona sprzeczna (krótki kod z kodem czytelnym), to do programisty należy decyzja, którą z najlepszych praktyk zastosować. Mamy nadzieję, że są to rozsądni ludzie, którzy doceniają wkład taki jak ten.

Musisz także być trochę odważny, ponieważ jeśli jesteś zmuszany do zmniejszenia LOC tam, gdzie uważasz, że jest to niepotrzebne lub niewłaściwe, to naturalne, że i tak dokonasz zmiany ze względu na spokojne życie. Musisz się temu oprzeć i musisz podjąć decyzję. W sytuacji, gdy kierownictwo jest rozsądne, nie powinieneś dokładnie przestrzegać ich wytycznych, ale powinieneś być w stanie uzasadnić wszelkie okoliczności, w których nie postępujesz.

Niestety, ludzie mogą być irracjonalni, szczególnie jeśli chodzi o ludzi o niższej pozycji w hierarchii, kwestionujących ich decyzje i zasady, które narzucili tobie. Mogą zdecydować, że nie będą rozsądni. Musisz być na to przygotowany. Jeśli potrafisz zademonstrować przypadki, w których najlepsza praktyka LOC wchodzi w bezpośredni konflikt z innymi najlepszymi praktykami i dlaczego szkodzi to produktowi, i jeśli możesz to zrobić w częściach bazy kodu, dla których mieli niewielki lub żaden osobisty udział (więc nie robi tego nie wydają się osobistym atakiem na ich pracę lub pracę, którą nadzorują), to może pomóc wzmocnić twoją argumentację. Ponownie, musisz być przygotowany na usprawiedliwienie się w spokojny, racjonalny sposób i być w stanie „posiadać” argumenty, które wysyłasz.

Jeśli twoje kierownictwo jest rozsądnymi ludźmi, muszą docenić to, co mówisz, ma sens, jeśli możesz przedstawić dowody na poparcie swoich roszczeń.

GordonM
źródło
2

Myślę, że powinieneś naprawdę dążyć do posiadania funkcji z niewielką liczbą SLOC.

Jeśli LOC (wiersze kodu) jest małą liczbą, w jaki sposób wpływa na kod, a jeśli LOC jest większą liczbą, w jaki sposób wpływa na kod?

Idealnie byłoby łatwiej zrozumieć 8 linii kodu na pierwszy rzut oka, niż powinno być zrozumiałe 30.

Nie oznacza to, że 30 LOC skompresowanych w 8 liniach będzie łatwiejszych do zrozumienia.

Jak myślisz, co jest właściwym sposobem robienia rzeczy.

Zwykle w funkcji próbuję pogrupować ją według poziomów abstrakcji („kod IO tutaj”, „weryfikacja tutaj”, „obliczenia tutaj” i tak dalej).

Następnie podzielę go na bloki, oddzielone pustą linią. Jeśli kod ma więcej niż około dziesięciu wierszy, wyodrębniam każdy blok do innej funkcji (robię to i tak dla kodu, który pojawia się więcej niż jeden raz). Słyszałem argument o zerwaniu wydajności w ten sposób (niepotrzebne wywołania funkcji), ale w praktyce nigdy nie miałem z tego powodu wąskiego gardła wydajności.

To powiedziawszy, wykonałem funkcje z tą ekstrakcją, a po niej funkcja miała ~ 40 linii długości (kod C). Jeśli kod jest tak zgrupowany, jak to możliwe, nie widzę problemu z dłuższymi funkcjami.

utnapistim
źródło
2

Myślę, że ważniejsze jest skupienie się na czystym, automatycznie dokumentowanym kodzie niż LOC. Jednak nie podoba mi się twój przykład, ponieważ wyjaśnia on, co robi kod, bez podania przyczyny. Na przykład:

boolean sweet_sixteen = (wiek == 16);

jest dość zbędny. Każdy, kto czyta „wiek == 16”, wie o tym. Wolę napisać kod w ten sposób:

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

Logika decydowania o tym, kiedy rzucić drużynę, jest inna niż System.out, można ją przetestować i jest łatwa do zrozumienia. Co ważniejsze, ktoś czytający kod może zrozumieć powód, dla którego został napisany w ten sposób („firma chce zorganizować wielką imprezę dla niektórych osób”).

Eduardo Scoz
źródło
2
Znaczenie słodkiej szesnastki (i 21 lat) jest specyficzne dla kultury. Wyrażenie „słodka szesnastka” jest łatwiejsze do wyszukiwania niż „wiek == 16”. Z tego powodu przydatne może być nadawanie nazw niektórym booleanom. Zgadzam się jednak z twoim ogólnym sentymentem: nie trać czasu na wyjaśnianie kodu, który nie wymaga wyjaśnień.
Jonas Kölker,
1

Myślę, że mniej linii kodu = kod bardziej czytelny

Ale oczywiście istnieje pewien limit, kiedy zaczynasz minimalizować / zasłaniać kod, aby uzyskać mniej wierszy.

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

To jest minimalizacja, logika pozostaje taka sama, tylko mniej czytelna. Nie powinno to być wykonywane przez ludzi, ta minimalizacja jest wykonywana przez maszynę do odczytu przez maszynę.

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

Jeśli możesz usunąć część kodu, a algorytm nadal robi to, co powinien, okej. Tylko nie pomniejszaj swojego kodu, są na to lepsze narzędzia.

Vitim.us
źródło
1

Nie sądzę, że mniej wierszy kodu == bardziej czytelny kod. Jednak rzeczywistość, która bardzo różni się od teorii, jest taka, że ​​kod z dużą liczbą wierszy jest często pisany bez odpowiedniego projektu. W związku z tym wymaganie mniejszej liczby linii MOŻE zmusić niektórych programistów do opracowania lepszego projektu, jeśli są w stanie. Rzecz w tym, że wielu programistów nie jest, więc wymaganie niewiele pomaga.

zhouji
źródło
1

W normalnych okolicznościach nie widziałbym liczby linii jako problemu, ale może wskazywać na problemy. Jeśli ktoś pokaże Ci klasę z 1000 liniami kodu, oznacza to, że coś musi być nie tak ze sposobem, w jaki klasa została wykonana lub zaprojektowana.

Twój przykład wskazuje na przypadek, w którym sensowna jest większa liczba wierszy kodu. Ale to jest ten przykład. Codziennie widzę przykłady, w których liczba linii jest związana z brakiem planowania

IvoC
źródło
0

Myślę, że LOC jest o wiele bardziej użytecznym miernikiem na początku projektu niż podczas faktycznej realizacji. Znajomość LOC według punktu funkcji pozwala oszacować wysiłek projektu, a na podstawie tego, ile czasu zajmie projekt i optymalnej liczby programistów.

Może również wpływać na projekt i wybór języka: zmniejszenie liczby punktów funkcyjnych lub przejście na język o niższym LOC / FP powinien zmniejszyć wysiłek związany z projektem, a wszystko inne jest równe.

James Jensen
źródło
0

Same linie kodu nie są bardzo ważne. Jednym ze sposobów na to jest porównanie go z prozą. Pierwszą realizacją jest to, że ważną właściwością zarówno kodu, jak i prozy (przy założeniu poprawności) jest czytelność. Czytelność (i zrozumiałość) pomaga w przypadku innych właściwości, takich jak łatwość konserwacji i poprawność.

Korzyści z możliwości dopasowania funkcji do niewielkiej liczby linii. Ale posiadanie tekstu bez akapitów zmniejsza jego czytelność. Używanie trudnych pojęć, trudnych (rzadkich) słów i złożonych sposobów wyrażania się ogólnie zmniejsza liczbę słów potrzebnych do wyrażenia pomysłu, ale jednocześnie przenosi poziom czytania tekstu z poziomu szkoły średniej do profesjonalnych nauczycieli akademickich (w przypadek prozy).

Zasadniczo pomocne jest dodawanie abstrakcji w kodzie i używanie pomocników itp., Ale znowu te abstrakty mogą być zbyt liczne. To, co może się zdarzyć, to przeniesienie złożoności do innej części kodu. Czasami, na przykład, gdy jako ekspert projektujesz platformę / bibliotekę do wykorzystania przez młodszych programistów (lub studentów), warto to zrobić. Ale nie oczekuj, że juniorzy będą w stanie zrozumieć, w jaki sposób działa Twój kod, po prostu utrudnij im nieprawidłowe użycie go.

Pisząc kod, szczególnie nie wahaj się dodawać pustych linii w kodzie. Działają jako akapity i pomagają rozdzielić różne części funkcji (nawet jeśli nie należy ich jeszcze umieszczać w pomocnikach).

Paul de Vrieze
źródło
-1

Ogromnym problemem związanym z każdą formalną metodą oceny kodu jest to, że na pewno zawiedzie on w przypadku jakiegoś kodu. Wynika to z faktu, że programowanie jest rodzajem sztuki i jako takie nie mogą istnieć jasne standardy oceny. Oczywiście istnieją różne rodzaje sztuki - istnieje również masowa produkcja obrazów, i być może w tym biznesie ważne jest, ile farby wydaje się na jeden obraz. :)

johnfound
źródło
-1

Mówiąc szczerze, nie przejmuję się pomiarem LOC. Jasne, miło jest, aby funkcja lub procedura była możliwie jak najkrótsza, ale za każdym razem dobieram czytelny kod w krótkim czasie.

Vladimir Kocjancic
źródło
-2

Zgadzam się, że zawsze wymaganie zmniejszenia LOC prowadziłoby do trudnego do odczytania kodu.

Być może jednak Twój styl kodowania jest zbyt szczegółowy i twój recenzent uważa, że ​​bardziej zwięzły sposób jest lepszy. Na przykład komentarz, który wyjaśnia tylko jedno stwierdzenie, które jest dość oczywiste dzięki jasnemu wyborowi nazw zmiennych, jest bezużyteczny.

MatthieuW
źródło
5
O ile mi wiadomo, komentarze nie liczą się do LOC.
mrs
1
To się nie liczy lub się liczy, zgodnie z definicją, której używasz.
MatthieuW,
1
Komentarze są komentarzami. Nie są kodem. Dlatego nie dotyczą one LOC. Chociaż kod samodokumentujący jest lepszy niż kod dobrze skomentowany, usuwanie mniej oczywistych komentarzy z kodu nie jest pomocne dla nikogo.
GordonM,
-2

Jest tylko jedna rzecz, którą mierzą wiersze kodu i jest to liczba wierszy kodu. Cała reszta to gorące powietrze, spekulacje i uprzedzenia.

Istnieje wiele świetnych przykładów w innych odpowiedziach, w jaki sposób posiadanie mniejszej liczby wierszy kodu może pogorszyć, a nie poprawić, ale wydaje się, że jeden podstawowy punkt został pominięty, i to: ile wierszy faktycznie potrzebujesz do wykonania tej pracy ?

Jeśli wykonanie zadania wymaga 10 wierszy kodu, niech tak będzie, robisz to w 10 wierszach. Jeśli osiągnięcie tego wymaga 10 000 linii, to niech tak będzie, zrób to w 10 000 linii. Kult „mniejszej liczby wierszy kodu” nie poprawi tego drugiego przykładu, jeśli zrobisz to w 1000, 2000, czy cokolwiek innego. Zadanie wymagało 10 000 wierszy, a te 10 000 wierszy mogą obejmować warstwy sprawdzania poprawności, sprawdzania błędów, zabezpieczeń itp., Których można by pominąć , gdybyś zrobił to mniej.

Edytować

Ponieważ zyskało to kilka głosów negatywnych, myślę, że muszę bardziej szczegółowo powiedzieć, co tu mówię. Pierwszą rzeczą, którą każdy powinien zrobić, jest przeczytanie tego - chodzi o to, aby oderwać się od tego, że kod wysokiego poziomu, który piszesz, może w niewielkim stopniu lub wcale nie przypominać kodu maszynowego, który faktycznie zostanie wykonany. Znaczenie tego punktu polega na tym, że skupienie się na kodzie wysokiego poziomu bez zrozumienia tego, co naprawdę dzieje się pod spodem, jest błędne.

Teraz rozważ następujące kwestie:

  • Możliwe jest napisanie naprawdę złego, wolnego kodu za pomocą tylko jednego wiersza - zwróć uwagę na komentarz operatora trójskładnikowego na końcu podanego linku.

  • Jeśli wiersz kodu wywołuje wywołanie API (lub inne wywołanie do biblioteki zewnętrznej), z definicji masz niewiele możliwości bezpośredniej kontroli nad tym, co zostanie wykonane lub jak jest ono wydajne.

  • Sprawdzanie błędów, czyszczenie, itp wszystko dodać dodatkowe linie kodu i jestem pewien, że nawet najbardziej zagorzały fan mniejszej liczby linii kodu nie będzie argumentować przeciwko tym .

Więc - wiersze kodu to zepsuta metryka. Mniej wierszy kodu nie gwarantuje dodatkowej wydajności - to wywołanie API lub biblioteki to jedna linia i może być poza twoją kontrolą. Mniej linii kodu nie gwarantuje dodatkowej niezawodności - sprawdzanie błędów i czyszczenie zawsze będzie wymagało dodatkowych linii. Mniej wierszy kodu nawet nie gwarantuje dodatkowej czytelności ani łatwości konserwacji - wystarczy spojrzeć na IOCCC, aby to wiedzieć.

Co więc gwarantuje mniej wierszy kodu? Mniej linii kodu, to wszystko.

Głęboko błędem jest skupianie się na wykonywaniu tej samej pracy w 2000 liniach w porównaniu do 10 000. Zamiast tego skup się na kodzie, który działa, który jest solidny, który działa w ramach akceptowanych tolerancji, i który jest łatwiejszy do odczytania i kontynuowania. Czasami oznacza to, że możesz to zrobić przy niskiej liczbie LoC, czasem oznacza to, że musisz to zrobić przy wyższej liczbie LoC, ale liczba LoC nie powinna być tutaj istotna.

mh01
źródło
1
Z definicji , jeśli zadanie bezwzględnie wymaga wykonania N linii kodu (co w pierwszej kolejności jest trudne do ustalenia), to nie można tego zrobić w mniej niż N linii. Twoje zadanie na 10.000 linii nie może być wykonane w 2000, kropka. Wydaje mi się, że OP mówi o przypadkach, w których istnieje pewna swoboda, tzn. „Wymaganie można w pełni zrealizować w obu kierunkach, więc który z nich jest lepszy?”
Andres F.,
-3

Jak ważne jest zmniejszenie liczby wierszy w kodzie? W większości przypadków wcale nie. W rzeczywistości w większości przypadków ważniejsze jest zwiększenie liczby wierszy kodu przez podzielenie złożonych operacji na bardziej czytelne kroki i komentowanie każdego kroku, a także dodawanie komentarzy w ogólności, aby kod był bardziej czytelny i rozszerzalny przez inne programiści, którzy cię ścigają.

Infin8Loop
źródło
1
Dlaczego wszystkie opinie?
Marko,
Tak, dlaczego odrzucono całkowicie rozsądną odpowiedź? Dlaczego inne całkowicie rozsądne odpowiedzi, z których wszystkie podważają ideę, że zmniejszone linie kodu są celem samym w sobie, również odrzucone?
Maximus Minimus
1
@ mh01 Zgaduję, ponieważ większość tego jest błędna? W szczególności in most cases, it is more important to increase the number of lines of code by breaking out complex operations into more readable stepsnie jest to moje doświadczenie. Skomplikowany kod można częściej uczynić bardziej czytelnym i mniej niepoprawnym, czyniąc go mniejszym i prostszym, ponieważ musi być skomplikowany od napisania przez kogoś, kto był nowy w języku / nowy w problemie / nie jestem pewien, co robią.
Izkata,
-5

We wcześniejszym okresie założono, że jeśli liczba wierszy kodu, który jest loc, jest duża, to kod jest skuteczny i wykonuje wszystkie zadania, do których jest wykorzystywany, ale po pewnym czasie okazało się, że im mniej, tym więcej loc ma wydajność, ponieważ koszt poniesiony przez system przy wykonywaniu kodu jest znacznie mniejszy. Dlatego dla poprawy systemu loc trzeba było zmniejszyć. Od tego czasu założono, że loc powinien być mniejszy. Aby go zmniejszyć, następujące czynniki należy wziąć pod uwagę.

  1. Zrób schemat blokowy swojego problemu
  2. Spróbuj użyć mniejszej liczby pętli, jak możesz
  3. Wywołania funkcji nie powinny być duże
  4. W przypadku przechowywania stosu lub kolejki do przechowywania odpowiednich informacji należy zastosować nowe struktury danych, takie jak TRIE.
  5. I spróbuj rozwiązać problem za pomocą realistycznego podejścia, a nie wyobraźni, w którym przechowujesz ogromną liczbę liczb w bardzo dużej tablicy, a następnie próbujesz uzyskać do niej dostęp przez tablicę.]
  6. Używaj jak największej liczby makr. Dalsze podejście do używania zależy również od problemu. Jeśli jest naprawdę skomplikowane, to czasami użycie prostego podejścia jest również równoważne złożonemu
Vibhu Tiwari
źródło
5
-1: Łał! Myślę, że musisz zmniejszyć LOC w swojej odpowiedzi! Boli mnie oczy, żeby to przeczytać!
Jim G.
1
@JimG .: Zgadzam się, że odpowiedź rani mnie w oczy, ale myślę, że najlepiej to rozwiązać poprzez zwiększenie LOC (np. Poprzez zastosowanie osobnej linii dla każdego ponumerowanego elementu).
Brian
To była wina autoformatowania, wstawienia pojedynczej pustej linii, zanim lista wyleczyła sytuację
Balog Pal