Jak ważne jest zmniejszenie liczby wierszy w kodzie?

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.");
    }
}

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.

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ć.

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 .

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.

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.

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”.

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ń.

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.

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”).

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.

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.

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

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.

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).

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. :)

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.

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.

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.

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ą.

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