Zmienna składa się z dwóch elementów: etykiety (nazwy) oraz danych, które pod tą etykietą są przechowywane. Etykieta może przybrać prawie dowolną nazw- istnieje kilka zasad, których należy przestrzegać.

Po pierwsze, tworząc nazwę etykiety, nie powinno się stosować polskich znaków. Moim zdaniem plik z kodem źródłowym powinien być zapisywany przy wykorzystaniu kodowania znaków ASCII. Dlaczego? To temat na osobną dyskusję.

Po drugie nie można stosować znaków operatorów (+, -, *, %, etc), ponieważ rozdzielają one nazwy zmiennych i wskazują na wykonanie operacji.

Po trzecie, nazwa zmiennej nie może zaczynać się od cyfry. Może je mieć cyfry w sobie lub na końcu jednak zaczynać się od cyfry nie może. Jest to spowodowane wstępną analizą kodu źródłowego i potencjalnymi dwuznacznościami w interpretacji takiego kodu przez kompilator.

Po czwarte, nazwa zmiennej nie może mieć w sobie białych znaków (spacji, tabulatorów, nowych linii), to znaczy, że nazwę zmiennej piszemy ciągiem. Jeżeli etykieta jest zlepkiem kilku słów można posiłkować się kilkoma technikami, które ułatwiają zarówno pisanie jak i czytanie takich nazw. W zależności od języka programowania lub preferencji programisty, można wybrać pomiędzy tzw. "underscore case" albo "camel case"- są to najbardziej rozpowszechnione zasady tworzenia nazw zmiennych, funkcji, struktur, klas czy w etykiet w ogóle.

underscore case

To podejście zastępuje spacje znakiem _ _ _, po angielsku "podkreślnik" to właśnie "underscore" i stąd pochodzi nazwa tej metody. Zgodnie z tą metodą, aby stworzyć nazwę zmiennej, która symbolizuje np. ilość uczestników, należałoby stworzyć etykietę

ilosc_uczestnikow

.

camelCase

Metoda wielbłądzia, polega na tym, że każde kolejne słowo w etykiecie pisane jest wielką literą. Odwołując się do przykładu ilość uczestników, etykieta camel będzie wyglądać

iloscUczestnikow

.

Najważniejsza zasada w tworzeniu nazwy zmiennej

Kiedy rozpocząłem pracę jako programista, otrzymałem od przełożonego skrypt, który zawierał tzw. "do’s and don't's", czyli listę rzeczy, które należy robić, a których kategorycznie nie wolno. Zaczynał się od złotej zasady: Każda nazwa zmiennej jest znacząca.

Chodzi tu o to, że nazywając jakąś zmienną tworzymy ją w jednym konkretnym celu. Tylko w tym celu ją wykorzystujemy, nie w żadnym innym. Ten konkretny cel jest ściśle określony przez jej nazwę. To znaczy, że gdy chcemy przechować wartość prędkości pojazdu, tworzymy nazwę zmiennej odpowiadającej temu, co ona przechowuje, np.

predkosc_pojazdu

albo (lepiej)

vehicle_speed

. Nie stosujemy skrótów typu pp (czy adekwatnie vs), nie idziemy na skróty, np. predkosc czy tym podobne rzeczy. Tak samo w przypadku, gdy potrzebujemy "tymczasowej" zmiennej, która na chwilę przechowuje wynik cząstkowy algorytmu. Kuszące są tutaj nazwy typu temp, tmp czy jeszcze gorzej a, z, x, etc. Gdy ktoś obcy będzie czytać taki kod, bądź my sami po jakimś czasie, stracimy niepotrzebnie czas na odszyfrowywanie znaczenia tej zmiennej aby móc pojąć sens całego algorytmu.

Po drugie, absolutnie niedopuszczalne jest tworzenie zmiennej o nazwie

temperatura

i umieszczenia w niej (chociażby "na chwilę") wartości, którą zwraca funkcja np.

predkosc_statku()

. W początkowych etapach nauki programowania wiele osób ma takie pokusy, najczęściej dyktowane lenistwem lub chęcią "oszczędzenia pamięci":

• "Po co deklarować nową zmienną, skoro mogę wykorzystać już istniejącą, przecież i tak jej teraz nie używam."
• "Mam już tyle zmiennych, zaoszczędzę trochę pamięci, program będzie mniejszy, gdy na chwilę wynik działania tej funkcji przypiszę do tej zmiennej."

Jakie są konsekwencje takiego działania? Po jakimś czasie, gdy zechcemy modyfikować nasz kod, doprowadzimy do sytuacji, że uzyskujemy nieoczekiwane wyniki, ponieważ gdzieś w środku algorytm polega na wartości zmiennej, która "akurat gdzieś niżej" jest wykorzystywana do czegoś innego. Tak traci się godziny na odpluskwianie kodu, nie wspominając już o demotywacji do dalszego działania.