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

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ść?

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.

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.

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.

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.

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 ksą cał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.

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)