zasady trzeba mieć

Kod programu to nie „Pan Tadeusz” i pisanie trzynastozgłoskowcem nie sprawdzi się tu mimo, że objętość dzieła może być podobna. Jeśli nie jesteś członkiem programistycznego teamu, który narzuca własne konwencje programistyczne lub nie masz jeszcze zbyt wyrobionego własnego stylu możesz posłużyć się poniższym zbiorem „dobrych rad” ułatwiających życie.

Jak ułatwić sobie życie przy programowaniu?

1. Sposób zapisu nazw zmiennych lokalnych, zmiennych globalnych i stałych

Jest wiele możliwości w jaki sposób nazywać zmienne, dla ułatwienia sobie życia można przyjąć zasadę, że notacja „camelCase” będzie najwłaściwsza. Polega ona na zapisywaniu kolejnych słów w nazwie zmiennej od dużej litery z tym, że pierwsze słowo piszemy od małej litery. Przykłady:

poczatkowyStanKonta
liczbaElementowWadliwych
nazwaUzytkownika

Zmienne globalne niektórzy traktują specjalnie i to traktowanie wyraża się w zapisywaniu nazwy zmiennej DUŻYMI LITERAMI, gdzie kolejne wyrazy oddzielane są znakami podkreślenia „_”:

LICZBA_ZMIAN
POCZATKOWY_STAN_KATA

Stałe zapisujemy podobnie jak zmienne globalne, np.

MAX_RECORDS
THRESHOLD_CAR_SPEED

Starajmy się nie używać w nazwach zmiennych i stałych znaku minus „-” bo może on w niektórych przypadkach prowadzić do pomyłek, możemy mieć wątpliwości czy odejmujemy jedną zmienną od drugiej (i jest błąd w zapisie) czy zapis jest poprawny.

2. Nazewnictwo zmiennych

Nazywanie zmiennych programu literami np. „a” lub „b” jest co prawda bardzo wygodne z punktu widzenia pisania (tylko jeden znak) ale nie niesie ze sobą wartości w postaci autokomentowania kodu. Kto wie co to „a” lub „b”? Jeśli zamiast oszczędnego nazewnictwa skorzystamy z możliwości nazwania zmiennej w sposób bardziej „bogaty”, niosący ze sobą znaczenie zmiennej to będzie to tylko z korzyścią dla nas jak i dla innych. Zmienne nazywać możemy np:

numerKataUzytkownika
liczbaSztukNaZmiane

Standardowo wykorzystywane w pętlach nazwy zmiennych i, j, k (ale nie „l” bo podobne jest do innych znaków) możemy zostawić jeśli zasięg pętli jest lokalny.

3. Spacje przy operatorach

Czytanie złożonych wyrażeń arytmetycznych, gdzie wszystko „zlewa się” w jeden ciąg może być bardzo uciążliwe. Konia z rzędem temu, który od razy jest wstanie ogarnąć wzrokiem poniższe równanie i zobczy o co w nim chodzi.

y=Math.pow(x*x+0.5*x*x*x+0.25*x*x*x*x,2);

Jednak jeśli dodamy spacje pomiędzy operatorami (znakami *, /, +, -, =) od razu zrobi się wszystko znacznie bardziej czytelne.

y = Math.pow(x * x + 0.5 * x * x * x + 0.25 * x * x * x * x,  2);

4. Wcięcia

Nie trzeba nikogo chyba zachęcać do tego by korzystać z wcięć podczas pisania większych bloków programu (pętli warunkowych, funkcji, obsługi błędów itp.). Jeśli nie korzystamy z odpowiedniego edytora (z dodatkami) to musimy sami dbać o to by zapewnić odpowiednie wcięcia. Jedni stosują tabulatory, inni np. 4 spacje a jeszcze inni zadają się na „mądrość” edytorów, które bywają całkiem użyteczne. Przykładowo bardzo ładnie zachowuje się edytor z Visual Studio, w którym można pisać np. skrypty JavaScript, oprócz normalnych programów pisanych w C#, C++ czy VB. Dobry jest też Sublime, który z dodatkami potrafi ułatwić życie.

Blok niesformatowany zawsze będzie mniej czytelny od odpowiednio sformatowanego. Polecam w tym względzie książkę „Czysty kod. Podręcznik dobrego programisty” autor Robert C. Martin.

funkcje:

function przeliczStan(stanAktualny, iloscWydana) {
    return (stanAktualny - iloscWydana);
}

pętle:

for (var i = 0; i < daneOdczytane.length; i++) {
    // statement
    daneOdczytane[i];
}
while (licznik < 10) {
    // statement
    licznik++;
}

instrukcje wyboru:

switch (wybranaOpcja) {
    case 1:
        // wyrażenie 1
        break;
    case 2:
        // wyrażenie 2
        break;
    default:
        // domyślne wyrażenie
    break;
}

5. Komentarze

Podobno dobrze napisany komentuje się sam ale to tylko podobno. W rzeczywistości komentarze są niezbędne z prostej przyczyny – nie pracujemy sami nad danym kodem lub co pewien czas pracujemy nad kodem „z przeszłości”. Trudno pamiętać o co chodziło w kodzie, który pisaliśmy rok, dwa lata temu więc odrobina komentarza może pomóc … i niestety może zaszkodzić jeśli komentarz jest nieaktualny lub błędny. Smutne to ale prawdziwe.

Jeśli już używamy komentarzy to wykorzystujmy rozwiązania specyficzne dla danego języka.

np. C#, C++, Java, JavaScript, PHP:

// treść komentarza liniowego

np. C#, C++, Java, JavaScript, PHP, SQL, CSS

/*
 treść komentarza blokowego
 */

Visual Basic:(znak [’] apostrof)

'treść komentarza

linia kodu 'treść komentarza

HTML:

<!--
 treść komentarza
 -->

Autor: gervee

Pełnoetatowy ojciec małej gromadki, programista(?), "amator" fotograf, "dłubacz" lubiący DIY, miłośnik chmielonego napitku. "Żartowniś" bez poczucia humoru ;).

Dodaj komentarz