Dla mnie znalezienie dobrego imienia dla czegoś zawsze wraca do myślenia o nim jako o obiekcie, który musi uzasadniać jego istnienie. Zapytaj siebie:
- Do czego służy klasa / metoda / zmienna, tj. Jaki jest jej szerszy cel i do czego służy?
- Co konkretnie w swoim celu musi się komunikować, tj. Jaka jest zasadnicza część, jaką musi mieć w sobie nazwa?
Większość programistów zgodzi się, że czytelność ma zawsze ogromne znaczenie, jeśli chodzi o nazewnictwo. Nie pisz po prostu kodu, abyś wiedział, co masz na myśli, pisząc go, napisz go tak, aby ktoś, kto zobaczy kod po raz pierwszy w pewnym momencie w przyszłości, wiedział, co masz na myśli, bez zbytniego zastanawiania się. Kod napiszesz tylko raz, ale w trakcie jego trwania najprawdopodobniej będzie musiał być edytowany wiele razy i czytany jeszcze więcej razy.
Kod powinien być samodokumentujący, to znaczy, że twoje nazewnictwo powinno wyraźnie pokazywać, co coś robi. Jeśli musisz wyjaśnić, co robi wiersz kodu w komentarzu, a zmiana nazwy rzeczy nie poprawia go wystarczająco, powinieneś poważnie rozważyć przekształcenie tego wiersza w nową metodę o odpowiednio opisowej nazwie, tak aby po przeczytaniu oryginalnej metody nowe wywołanie metody opisuje, co się dzieje. Nie bój się mieć długich nazwisk; oczywiście nie powinieneś pisać powieści w nazwach klas / metod / zmiennych, ale wolałbym, aby nazwa była za długa i opisowa niż za krótka i muszę dowiedzieć się, co robi, patrząc pod maską. Z wyjątkiem pewnych oczywistych wyjątków, takich jak współrzędne x / y i często używane akronimy, unikaj nazw i skrótów jednoznakowych. Nazywanie czegoś „bkBtn” zamiast „backButton”
O ile pozwala na to Twój język, spraw, aby Twój kod był czytany jak zdanie angielskie. Obiekty używają rzeczowników, metody używają czasowników. Metody boolowskie zwykle zaczynają się od „jest”, ale istnieje wiele innych opcji, które przekazują znaczenie jeszcze lepiej, w zależności od przypadku użycia, takich jak „może”, „powinien” lub „robi”. Oczywiście nie wszystkie języki mogą być w tym języku tak dobre, jak Smalltalk, ale niektóre symbole są ogólnie rozumiane jako części zdania. Dwie konwencje Smalltalk, które osobiście lubię brać pod uwagę w innych językach, na tyle, na ile to możliwe, poprzedzają nazwy parametrów pętli słowem „każdy”, a parametry metody przedrostkiem tekstem „a” (lub „an” lub „niektóre” w przypadku kolekcji) . To może nie być powszechny standard w Javie i każdy może zignorować ten bit, ale uważam, że znacznie poprawia to czytelność kodu. Na przykład (przykład w Javie):
public boolean shouldConsiderAbbreviating(List<String> someNames) {
for (String eachName : someNames) {
if (isTooLong(eachName)) {
return true;
}
}
return false;
}
Powinno to być czytelne dla osób z niewielką znajomością języka Java, takich jak:
Aby ustalić, czy należy rozważyć skrócenie listy niektórych nazw (które są ciągami znaków), iteruj po niektórych nazwach i dla każdej nazwy określ, czy jest ona za długa; jeśli tak, wróć true; jeśli żadna nie jest za długa, wróć false.
Porównaj powyższy kod z samą nazwą argumentu stringsi zmiennej pętli string, szczególnie w bardziej złożonej metodzie. Trzeba było przyjrzeć się bliżej, aby zobaczyć różnicę zamiast oczywistego użycia na pierwszy rzut oka.