Czy poświęcam krótsze nazwy zmiennych dla dłuższego kodu „z kolumnami”?

17

Jestem programistą amatorem na zajęciach CS, próbującym nauczyć się odpowiednich umiejętności programistycznych. Tak wygląda mój kod, jego krawędzie rozciągają się na 103 kolumny.

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }

Zanim miałem te bardzo długie nazwy zmiennych, miałem takie rzeczy jak i, j, k, ale mój profesor nalega , abyśmy nie używali takich zmiennych w „świecie zawodowym” i że nawet skrócone zmienne, takie jak lenWord, są niewystarczające, ponieważ ludzie mogą założyć to skrót od „Lennard's World Literature”. Mówi, aby wybrać znaczące nazwy zmiennych, ale robiąc to, mam wrażenie, że złamałem Złotą Zasadę kodowania, aby utrzymać ją poniżej 80 kolumn. Jak to obejść?

RaulT
źródło
26
Tak trzymaj; dodaj więcej przydatnych nazw. Można myśleć o sposób, aby opisać cipherColumn + (rowSize*nextWord) + nextWordto sprawia, że jasne, co to obliczenie jest za , na przykład? Założę się, że ta nazwa jest krótsza niż obliczenie, więc zyskujesz na czytelności i zmniejszonej długości linii. Nie wyrównuj też przypisań, albo musisz przenieść je wszystkie, jeśli zmienisz nazwę najdłuższej zmiennej.
jonrsharpe
2
Hmm .. więc mówisz, że powinienem utworzyć nową zmienną i zapisać w niej wynik cipherColumn + (rowSize * nextWord) + nextWord, aby móc jej dalej używać? Czy to właśnie robią profesjonaliści? Naprawdę pytam
RaulT
8
Tak, to moja sugestia. Jestem zawodowcem i tak robię, więc ... przynajmniej niektóre z nich.
jonrsharpe
11
złotą zasadą jest pisanie kodu, który można odczytać i zrozumieć. piszemy kod dla innych ludzi (!), nie dla maszyn. dla maszyn jest kod maszynowy. dla niektórych kod, który wygląda tak, jak opisałeś (nazwy jednoliterowe itp.) jest brakiem szacunku dla innych programistów (i ciebie w przyszłości - ponieważ zapomnisz za kilka tygodni lub miesięcy). nie ma powodu, aby trzymać się 80 kolumn, to nie jest MS DOS w latach 80.
rsm
3
@stijn tak, ale to ostatni raz, kiedy tego potrzebowaliśmy. tak jak nie kompiluję mojego kodu c dla 8-bitowego procesora 8086 w przypadku, gdy muszę go przechowywać na kartach dziurkaczy, nie sądzę też, aby 80-kolumnowy złoty stardard miał jakieś znaczenie w 21 wieku. powinniśmy rozciągnąć tę technologię, a nie siedzieć w latach 80. i myśleć, że dzięki temu jesteśmy sprytnymi hakerami. sprytna jest prostota, czytelność i maksymalne wykorzystanie technologii. mamy monitory Full HD, czas z niego skorzystać.
rsm

Odpowiedzi:

24

Zwykle, gdy widzę kod opublikowany tutaj jak twój, edytuję go, ponieważ nienawidzimy przewijania w poziomie. Ale ponieważ jest to część twojego pytania, pokażę ci edycję tutaj:

int extractMessage(char keyWord[25], char cipherText[17424],
                   int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);


    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
}

Że przerwa może być zaskakujące, ale to jest bardziej czytelny niż wersja z poziomego przewijania, i to lepiej niż skrócenie nazwy do i, j, i k.

To nie tak, że nigdy nie powinno się używać i, ji k. Są to dobre nazwy podczas indeksowania 3 zagnieżdżonych forpętli. Ale tutaj nazwy są moją jedyną wskazówką na temat tego, czego się spodziewałeś. Zwłaszcza, że ​​ten kod nic nie robi.

Najlepszą regułą dotyczącą długości nazwy zmiennej jest zakres. Im dłużej żyje zmienna, tym więcej innych zmiennych musi konkurować z jej nazwą. Nazwa CandiedOrange jest unikalna pod względem wymiany stosów. Gdybyśmy byli na czacie, możesz po prostu nazwać mnie „Candy”. Ale teraz jesteś w zasięgu, w którym ta nazwa mogłaby być mylona Candide , Candy Chiu lub Candyfloss . Im dłuższy zakres, tym dłuższa powinna być nazwa. Im krótszy zakres, tym krótsza może być nazwa.

Długość linii nigdy nie powinna dyktować długości nazwy. Jeśli masz na to ochotę, znajdź inny sposób ułożenia kodu. Mamy wiele narzędzi, które Ci w tym pomogą.

Jedną z pierwszych rzeczy, których szukam, jest niepotrzebny hałas do pozbycia się. Niestety ten przykład nic nie robi, więc to wszystko niepotrzebny hałas. Potrzebuję czegoś do pracy, więc najpierw zróbmy coś.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    int lengthOfWord   = 0;
    int lengthOfCipher = 0;

    lengthOfWord = length(keyWord);
    lengthOfCipher = length(cipherText);

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
            continue;
        }
    }
    return cipherColumn;
}

Tam, teraz coś robi.

Teraz, gdy coś robi, widzę, czego mogę się pozbyć. Ta długość nie jest nawet używana. To też continuenic nie robi.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Dokonajmy drobnych poprawek w białej przestrzeni, ponieważ żyjemy w świecie kontroli źródła i jest to miłe, gdy jedynym powodem, dla którego linia jest zgłaszana jako zmieniona, jest to, że robi coś innego, a nie dlatego, że część z niej musiała ustawiać się w kolumnie.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn = 0;
    int cipherColumn = 0;
    int offset = 1;
    int nextWord = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Tak, wiem, że jest to nieco mniej czytelne, ale w przeciwnym razie doprowadzisz ludzi do szaleństwa, którzy używają narzędzi vdiff do wykrywania zmian.

Teraz naprawmy te głupie podziały linii, które mamy, ponieważ staramy się trzymać poniżej limitów długości linii.

int calcCipherColumn(
        char keyWord[25], 
        char cipherText[17424],
        int rowSize, 
        char message[388]
) {
    int keyColumn = 0;
    int keyOffset = 1;

    int nextWord = 1;
    int cipherColumn = 0;
    int cipherOffset = (rowSize * nextWord) + nextWord;

    char key = keyWord[keyColumn];
    char keyNext = keyWord[keyColumn + keyOffset];

    while (key != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyNext != cipherText[cipherColumn + cipherOffset]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Tam, teraz logika w pętli koncentruje się na zmianach w pętli. W rzeczywistości wszystko oprócz cipherColumnmożna oznaczyć final. I hej! Spójrz na to. Teraz mamy na to miejsce.

Wszystko, co zrobiłem, to dodać 3 kolejne zmienne, zmienić nazwę na jedną i trochę zmienić ich kolejność. Rezultatem było to, że linie były wystarczająco krótkie, aby zmieściły się bez głupiego łamania linii !=.

Pewnie nazwiska keyikeyNext nie są tak opisowe, ale każdy tylko przyzwyczaić się raz, nie mieszkają tak długo, a co najważniejsze nie robią niczego, co ciekawe w pętli. Więc nie muszą tak być. Wprowadzając dodatkowe zmienne, mamy teraz możliwość, aby ich nazwy były długie, jeśli zajdzie taka potrzeba. Rzeczy się zmieniają, więc w końcu możemy potrzebować. Jeśli tak, to fajnie, że mamy pokój do oddychania.

Pozwoliłem sobie również na pokazanie ci wariantu 6 stylu Jeffa Grigga, który określa parametry wejściowe w celu przestrzegania ograniczeń długości linii.

candied_orange
źródło
Wow, to opisowe! Tak, wiem, że kod tak naprawdę nic nie robi, prawdopodobnie powinienem był opublikować więcej niż mały fragment, ale myślę, że próbowałem uzyskać ogólne pojęcie o tym, co robią profesjonaliści w odniesieniu do długości kolumny kodu i nazw zmiennych, ale twoja odpowiedź pokazała kilka bardzo słodkich zmian, które z pewnością zaimplementuję w moich kodach od teraz! Mam jeszcze jedno pytanie: gdzie uważasz, że należy dokonywać łamania linii? Przed operatorami? Czy istnieje akceptowany „standard”?
RaulT,
1
@RaulT poświęć trochę czasu na przeczytanie dowolnej bazy kodu, w której pracujesz. Podpowie ci, czego możesz użyć, co nie zaskoczy innych programistów. Postępuj zgodnie ze standardowym dokumentem, jeśli go posiadasz. Ale najlepiej jest zapytać innych programistów i zapytać, jak czytelne są twoje rzeczy. Aha i sprawdź codereview.stackexchange.com
candied_orange
Chciałbym dodać komentarz poniżej cipherOffset i wyjaśnić obliczenia, ponieważ ta formuła nie jest oczywista. Zapomnisz dlaczego za trzy tygodnie.
Nelson
15

Inni przedstawili już kilka użytecznych sugestii, pozwól, że podsumuję:

  • 80 znaków w wierszu mogło być złotą regułą w latach 80. W dzisiejszych czasach większość ludzi zgadza się, że od 100 do 130 znaków jest w porządku.
  • Używaj podziałów linii w wyrażeniach.
  • Podziel długie wyrażenia, wprowadzając wyniki pośrednie.

Chciałbym dodać kolejną rekomendację: nie bądź dogmatyczny w kwestii długich nazwisk! Im większy zakres zmiennej, tym więcej informacji należy podać w jej nazwie. Ogólnie rzecz biorąc, dobrym pomysłem jest utrzymanie małego zakresu zmiennych.

Na przykład, jeśli masz zmienną dla kolumny tabeli szyfrowania słów kluczowych i jasne jest, że tylko jedna tabela jest używana w zakresie zmiennej, możesz ją wywołać, columna nawet col. Jeśli zakres jest większy i w grę wchodzi wiele tabel, warto go wywołać keyWordEncryptionTableColumn.

Kolejny przykład: jeśli masz pętlę z ciałem obejmującym dwie lub trzy linie i musisz użyć indeksu do uzyskania dostępu do elementów tablicy, to nie ma nic złego w wywołaniu indeksu i. W tym kontekście jest on znacznie bardziej czytelny (przynajmniej dla większości ludzi) niż, powiedzmy arrayIndexOfMyVerySpecialDataSet.

Frank Puffer
źródło
1
Zgadzam się z tobą odpowiedź. W pracy używamy 80 znaków / linii dla c / c ++ ze starszego powodu i dlatego, że używamy przeglądarki. W przypadku znaków C # 100 / linię czasami łamię zasadę i przechodzę nieco ponad 100, aby zachować czytelność.
peval27
Wow, co za świetna odpowiedź !! Wszyscy ci odpowiedzialni byli wspaniali, dziękuję za pomoc, którą doceniam!
RaulT
Zdecydowanie zgadzam się z ideą, że 80 linii znaków jest przestarzała. Nadal stosuje się do niektórych projektów i miejsc (głównie dla spójności), ale dla wielu jest to po prostu niepotrzebne. Wielu programistów używa czegoś takiego jak Visual Studio lub IntelliJ na pełnym monitorze i ma drugi monitor do innych rzeczy (dokumentacja itp.). W ten sposób mają wiele nieruchomości ekranowych dla swojego kodu. Jeśli używasz tylko 80 znaków w wierszu, prawdopodobnie masz mnóstwo niewykorzystanego miejsca. A limit 80 znaków cię boli! Zwłaszcza gdy weźmiesz pod uwagę, że standardowa biblioteka lib może wymuszać długie nazwy tyłków.
Kat
1
Chodzi mi o to, że w niektórych językach tak naprawdę nie można uniknąć faktu, że 80 znaków jest dużym ograniczeniem. Dlaczego więc to niepotrzebnie? Pragnie również wspomnieć, że prawie wszystkie wielkie nazwiska edytorów i IDE mają obecnie doskonałe inteligentne zawijanie wyrazów, co pozwala wcale nie ograniczać długości linii. Możesz pozwolić, aby długość linii była dowolna, co czytelnik może zobaczyć. Mogą zmienić rozmiar okna, aby uzyskać bardziej optymalny wynik. Czasami osobiście uważałem to podejście za idealne. I jeszcze nie zawiodłem się, jak działa ten miękki okład.
Kat
Ilekroć używasz prostych nazw zmiennych, MUSISZ być w 100% pewien zakresu. Spędziłem trzy godziny, aby dowiedzieć się o zamknięciu JavaScript.
Nelson
3

Generalnie zgadzam się z tobą nauczycielu. Jeśli jednak masz zmienną, której zamierzasz często używać w sporym kawałku kodu, lepiej jest użyć skróconej formy po wyraźnym wyjaśnieniu jej znaczenia. Podobnie jak w przypadku wielu złożonych wyrażeń arytmetycznych i przydziałów, te nie czytają tak dobrze przy długich nazwach zmiennych.

O konspekcie:

ExtractMessage(char keyWord[25], char cipherText[17424],
               int rowSize, char message[388]) 

To nie ma sensu, samo ograniczenie długości linii nie czyni jej bardziej czytelną. Jeśli chcesz, aby było to czytelne, wykonaj następujące czynności:

ExtractMessage(
  char keyWord[25],
  char cipherText[17424],
  int rowSize,
  char message[388]
  )
{

A potem możesz nawet wyrównać identyfikatory typu (dodać spację po int). Zachowaj jednak ostrożność / ograniczaj nakreślanie inicjalizacji lub list argumentów w następujący sposób:

int keyColumn    = 0;
int cipherColumn = 0;
int offset       = 1;
int nextWord     = 1;

Problem polega na tym, że kiedy zmieniasz nazwę lub dodajesz zmienną, może być konieczne przeformatowanie całego bloku, aby zachować ładny wygląd. To nie tyle praca, ile wprowadzonych bezsensownych zmian, wyglądałaby okropnie w systemie kontroli wersji. Twój współpracownik zobaczyłby, że zmieniłeś plik i zrobiłeś różnicę z poprzednią wersją, aby zobaczyć, co zrobiłeś. Następnie każda linia świeciłaby jak zmieniona, zasłaniając prawdziwą zmianę. Zależałoby to nieco od jakości użytego narzędzia porównującego, ale w rzeczywistości nie jest dobrym pomysłem, aby kod był zbyt osobisty i / lub formatowanie jednej linii zależało od drugiej.

Czasami konturowanie może mieć jakiś cel, jeśli masz dziesiątki następujących po sobie linii, które są prawie takie same, łatwo będzie zauważyć, gdzie się różnią, jeśli je obrysujesz.

Pamiętaj, że w miejscu pracy może działać automatyczne formatowanie, które po prostu wyeliminuje wszelkie wymyślne formatowanie kodu przed przesłaniem go do systemu kontroli wersji.

Martin Maat
źródło
1
Osobiście pierwszy blok kodu w twojej odpowiedzi jest dla mnie znacznie bardziej czytelny niż drugi.
Miles Rout
1
nigdy nie rób trzeciego, utrzymywanie go w ten sposób to koszmar serwisowy.
jwenting
3

Oświadczenie: trochę przesadzam tutaj, aby wyjaśnić mój punkt widzenia. Więc weź jakikolwiek superlatyw z odrobiną soli.

Twój nauczyciel ma 100% racji: nie ma już „złotej reguły” około 80 znaków (chyba że piszesz kod linux). Zasada ta została ustanowiona ze względu na wielkość terminali w tamtym czasie, ale obecnie łatwo wcisnąć ponad 150 znaków w oknie enditora. Nawet jeśli przekroczysz ten limit, Twój edytor ma nadzieję owinąć linię miękko, abyś nie musiał przewijać. Jedynym powodem, aby nie przekraczać 80 znaków, była potrzeba przewijania .

To powiedziawszy, rzeczywiście istnieje potrzeba, aby twoje linie nie rosły w nieskończoność. Im dłuższa linia, tym trudniej jest człowiekowi analizować. Ale krótkie nazwy zmiennych nie są rozwiązaniem problemu długich linii .

Rozwiązaniem jest logiczne podzielenie wyrażeń poprzez wprowadzenie jeszcze bardziej poprawnie nazwanych zmiennych . Nie próbuj być sprytny z białymi spacjami. Wystarczy zidentyfikować dowolne podwyrażenie, które można odpowiednio nazwać, i utwórz dla niego zmienną. Upraszcza to zarówno kod obliczający zmienną, jak i kod używający tej zmiennej .


Nie jest to część twojego pytania, ale i tak chciałbym je skomentować: bardzo kiepskim pomysłem jest ustawienie =operatorów w pionie .

Są tego trzy przyczyny:

  1. Edycja bloku zawierającego pionowo wyrównane operatory to PITA. Ilekroć zmienia się długość największej zmiennej (zmiana nazwy, dodawanie, usuwanie), musisz wyretuszować wszystkie linie w bloku, aby odzyskać swój „ładny” układ.

    Oczywiście ten problem można nieco zmniejszyć, używając kompetentnego edytora, więc jest to niewielki powód. Prawdziwy powód to drugi:

  2. Te fałszywe zmiany białych znaków wprowadzone przez ponowne wyrównanie nie działają dobrze z nowoczesnymi systemami kontroli wersji, takimi jak git. Mają tendencję do tworzenia znacznych ilości konfliktów scalania, w których nie doszło do prawdziwego konfliktu i gdzie konflikt nie byłby sygnalizowany, gdyby nie zastosowano wyrównania. Każdy z tych fałszywych konfliktów kosztuje nic cennego czasu .

  3. Wyrównanie ma zerowe znaczenie semantyczne . To bezcelowe. Nic nie można lepiej zrozumieć dzięki wyrównaniu. Każda linia w bloku musi sama czytać, aby zrozumieć, co robi, połączenie z liniami powyżej i poniżej ma charakter czysto syntaktyczny.

Ponieważ wyrównanie nie ma żadnego znaczenia semantycznego, ale powoduje znaczne koszty, powinieneś oduczyć się nawyku, zanim będzie to kosztowało więcej czasu.


Jeśli podoba ci się limit 80 znaków, spróbuj programowania w fortran. To prawda, że ​​nowsze standardy podniosły limit linii fortranowej do 132 znaków, ale nadal obowiązuje, jak zawsze, osłabiając kompilację każdego programu, który przekracza limit. Jeśli jesteś dobry w programowaniu, wkrótce zaczniesz nienawidzić fortran, w tym jego ograniczenia długości linii. Następnie zostaniesz uzdrowiony do końca życia.

Sam musiałem profesjonalnie programować fortran i mówię wam, że nauczyłem mnie nienawidzić tego limitu długości linii najbardziej. Nie ma absolutnie nic bardziej frustrującego niż konieczność podzielenia prostej i czytelnej linii na części tylko dlatego, że kompilator nie kompiluje jej już poprawnie. Zdecydowanie istnieją wiersze kodu, które są najprostsze, gdy są wyrażone jako pojedynczy wiersz.

cmaster - przywróć monikę
źródło
3

Z biegiem lat pojawiło się wiele konwencji stylistycznych (nie reguł!) Z powodu ograniczeń w środowiskach programistycznych. Dawno temu, w czasach kart dziurkowanych, miałeś sztywny limit liczby znaków, które mogą pojawić się w fizycznej linii źródłowej (dlatego Fortran zarezerwował kolumnę 6 na znaki kontynuacji linii). Nie tak wiele dekad temu pracowałem nad terminalem VT220 w kolorze bursztynowo-czarnym 80x24; podczas gdy stosowane przeze mnie edytory nie ograniczały linii do 80 znaków, życie było o wiele łatwiejsze, jeśli starałeś się unikać przewijania w poziomie.

W starszych wersjach Fortran (do I77, IINM) nie można było nawet mieć identyfikatorów o długości od 6 do 8 znaków. Jeszcze w latach 80. C gwarantowałoby tylko, że pierwsze 8 znaków w nazwach zewnętrznych miało znaczenie (dlatego niektóre funkcje biblioteki mają cudownie opisowe nazwy, takie jak strpbrk).

Oczywiście, dwie dekady do XXI wieku, nie mamy już tych ograniczeń. Nie ma powodu, aby nie używać bardziej opisowych identyfikatorów.

Rzecz w tym, w odpowiednich kontekstach, ia ji kcałkowicie uzasadnione, sensowne nazwy . Jeśli iteruję przez tablicę lub wektor w pętli i potrzebuję tylko czegoś, aby zidentyfikować bieżący element, idziała doskonale. Nie użyłbym takiej nazwy currentElement- w tym kontekście nie ma to już większego znaczenia , a jedynie dodaje wizualnego bałaganu.

To powiedziawszy, twój nauczyciel nie myli się, zmuszając cię do myślenia w kategoriach dłuższych, bardziej opisowych nazw wszystkiego - życie stanie się dla ciebie łatwiejsze, jeśli najpierw przyzwyczaisz się do tego nawyku, a następnie naucz się, gdzie oszczędzać, jeśli to konieczne. Jako ktoś, kto był kiedyś zmuszony zmieścić wszystko w 8 lub mniej znaków, zdecydowanie lepiej jest pomylić się po stronie większej ilości informacji niż mniej. W miarę zdobywania doświadczenia dowiesz się, gdzie możesz zaoszczędzić na długości identyfikatora, i gdzie musisz być bardziej opisowy.

John Bode
źródło
-1

Nie jestem pewien, czy to działa dla c czy nie, ale czy istnieje sposób na podzielenie formuł na wiele linii? Wiem, że coś takiego istnieje dla Pythona.

Sprawdź, czy możesz zacząć + (rowSize * nextWord) + nextWord]) {w nowej linii. (Na przykład naciśnij Enter w IDE i sprawdź, czy to wcina, aby C wiedział, że poprzednie wyrażenie jest uzupełniane w bieżącym wierszu)

Krio
źródło
1
Tak, to zdecydowanie możliwe. C rozpoznaje wiersze i wiersze kodu, dopóki nie dodasz czegoś w rodzaju średnika. Problem polega na tym, że nasze funkcje nie mogą przekraczać 50 linii i chociaż mój przykładowy kod nie ma 50 linii, to tylko ułamek całej mojej funkcji. Czuję się mocno zmuszony do pisania w polu 50 na 80, algorytmów ze znaczącymi zmiennymi, które mogą wykonywać funkcje, których również potrzebuję. Mógłbym przechowywać te długie fragmenty kodu w nowych funkcjach, ale czuję, że skończę tyle wywołań funkcji, że ludzie zgubią się podczas czytania kodu.
RaulT
5
„Czuję, że skończę z tyloma wywołaniami funkcji, że ludzie zgubią się czytając kod”.Wręcz przeciwnie! Wyodrębnianie kodu do oddzielnych metod pozwala nadać im opisowe nazwy zwiększające czytelność (szczególnie metody, z której wyodrębniasz). Jeśli skończysz ze zbyt wieloma metodami, twoja klasa może robić za dużo (zasada pojedynczej odpowiedzialności). Ponowne wyodrębnienie metod do osobnej klasy pozwala nadać temu rzeczowi opisową nazwę.
Roman Reiner
Każda funkcja, która zbliża się do 50 wierszy, jest prawdopodobnie zbyt długa i zbyt złożona (z możliwym wyjątkiem inicjalizacji danych ze złożonością 1), ale zwykle, gdy omawiane są takie ograniczenia, są to wiersze kodu, a nie wiersze tekstu, więc dzielenie pojedynczego wiersz kodu, tj. do średnika często nie będzie liczony jako dodatkowy wiersz, sprawdź w Prof!
Steve Barnes