Каква е голямата работа с именуването? И защо изобщо трябва да ни интересува? Това е просто име.
На именуването на променливи, методи, класове, пакети и т.н. често се обръща по-малко внимание, отколкото заслужава. Много често срещаме имена като i,j,k или безсмислени имена като customerServicingProfileObjectUtil. Не смятаме, че е важно да отделим няколко минути, за да измислим по-добри имена за нашите програмни компоненти. В крайна сметка това е само име. Ако не разбираме какво прави, винаги можем просто да прочетем кода и да го разберем.
Наименуването може да означава повече, отколкото си мислим. Ако не можем да измислим добро име за компонент, това може да означава някое от следните
- Не разбираме отговорностите на този компонент
- Има повече от една отговорност
Така че, като измислим добро име, можем да видим ясно проблемите и да преработим кода за по-чист код. Това също помага за четливостта на нашия код. Ако видим метод с име, разкриващо намерение, не е нужно да ровим в този метод, опитвайки се да разберем какво прави, като по този начин ускоряваме разбирането на кода. В крайна сметка ние пишем кода, за да накараме другите хора да го разберат.
Друга миризма на лош код е, когато трябва да използваме коментари, за да опишем компонент, вместо да използваме името му. Вместо това можем просто да преименуваме компонента със смислено име, за да избегнем необходимостта от този коментар.
Пример от Robert C Marting в неговата книга с чисти кодове:
Вместо int d; // elapsed time in days използвайте int elapsedTimeInDays
Когато именуваме правилно компонентите, ние ги разбираме по-добре, разбираме, че може да принадлежат на различни места. По принцип ние преработваме кода по-добре.
