Чист код, глава 2 — Резюме на значимите имена

Разкрийте намерението на кода със смислени имена

Въведение

Това е част от моето лично резюме на книгата — Чист код.

• Чист код, глава 1, резюме

Преди да започнем глава 2, нека се запитаме

Какво означават за вас значимите имена?

• Смислените имена отнасят ли се за нещо, което е ясно и ясно?
• Смислените имена отнасят ли се за нещо, което не повдига въпросителна в главата ви, след като го прочетете?

По-долу са дадени някои дефиниции за това кои смислени имена от книгата резонират най-много с мен.

1. Разкрийте намерение
2. Избягвайте менталното картографиране
3. Използвайте съществително за име на клас и името на метода трябва да има глагол
4. Една дума на понятие

Разкрийте намерение

Едно смислено име трябва да може да разкрие намерението. За този раздел ще предоставя 3 различни сценария в именуване на променливи,

• Лошо именуване на променливи
• Лошо именуване на променливи с описателен коментар
• Добро и ясно именуване на променливи
• Произносимо име

Нека започнем с именуване на променливи.

Лошо именуване на променливи

const d = 24 * 60 * 60;

От горния код ние всъщност нямаме представа какво означава d за нас? Дори авторът на кода може дори да забрави за него след определен период от време. Знаехме, че резултатът е 24 * 60 * 60. Но определено не знаем какво представлява. Поради това не можем да го използваме повторно и поддържаме.

Лошо именуване на променливи с описателен коментар

Въпреки това, някои може да кажат, че можем просто да добавим коментара към кода и това може да преодолее празнината от недоразумения, като кода по-долу.

const d = 24 * 60 * 60; // Day in seconds

Това обаче все още не е най-идеалното решение. Защото всеки път, когато трябва да използвам променлива d, ще трябва да се върна към дефиницията на променливата и да проверя коментара. Това ще изисква превключване на контекста и ще струва умствената ни енергия.

Добро и ясно именуване на променливи

Най-идеалният подход е да се използва правилно име на променлива, което разкрива намерението на променливата. В този случай променливата е именувана като dayInSeconds.

Това е лесно и лесно мога да разбера какво прави dayInSeconds с един поглед.

const dayInSeconds = 24 * 60 * 60;

Това не се отнася само за името на променливата, но трябва да се отнася и за името на функцията, името на класа и всяка възможна част от кода, за да поддържаме нашата кодова база чиста. Опитайте се да си представите същата функция с 2 избора за име на функция, getData и getTransactions.

getTransactions тук определено е по-ясен и ясен, докато getData ви остави пълен простор за въображение като What kind of data?

Произносимо име

Обикновено едно произносимо име е лесно да разкрие намерението. Ако не можете да го произнесете, едва ли можете да го обсъдите с колегата си. Следователно произносимото име винаги е по-добро за предаване на намерение.

Избягвайте менталното картографиране

Това е една от точките, с които съм много съгласен. Много пъти програмистите са склонни да използват имена на променливи, които изискват умствено жонглиране.

Най-лошото именуване на променливи, предоставено от книгата, е имената на променливи с една буква като a и b. Най-често използваме това в for цикъл. Това обикновено все още работи добре в рамките на for цикъл, ако логиката остава проста. Но все пак еднобуквено име на променлива е най-лошият избор през повечето време.

Това е един от великите цитати от книгата.

Разликата между интелигентния програмист и професионалния програмист е, че професионалистът разбира, че яснотата е най-важната. Професионалистите използват своите правомощия за Бог и пишат код, който другите могат да разберат. — Чист код, глава 2

Горният цитат ми служи като добро напомняне. Разбира се, изграждането на функции и писането на код е ежедневна работа за програмиста. Но това не е достатъчно, трябва да бъдем професионалисти по отношение на това. Трябва да пишем код по начин, който другите могат да разберат.

Повечето от проектите обикновено имат повече от 1 разработчик, така че писането на код по начин, който хората могат да разберат, ще направи производителността по-бърза и по-лесна за сътрудничество. В противен случай вярвам, че това може да забави продуктивността, тъй като екипът расте, защото сега всеки пише неща, които разбира само за себе си. Сега членовете на екипа трябва да губят време, за да разберат кода на другия.

Използвайте съществително за име на клас и името на метода трябва да има глагол

Трябва да използваме noun за име на клас като Customer, Product и Transaction. Докато имената на методите трябва да съдържат глаголи като updateAddress. Долният прост пример показва как трябва да напишем името на нашия клас и името на метода.

class Customerclass Customer {
  // Verb "update" in function name
  updateName(firstName, lastName)
}

Една дума на концепция

Използването на една дума за понятие тук е от решаващо значение. Опитайте се да си представите дали имате 2 компонента с подобна роля. Въпреки това, първият компонент е именуван като UserController, докато другият е TransactionManager.

Ако сте новият член на екипа, вие сте объркан. Сега сте изправени пред дилемата и започвате да се питате:

• Каква е разликата между Controller и Manager?
• Защо имат различни видове имена на концепции, когато имат една и съща роля в кодовата база?
• Най-лошото е, че сте си помислили, че това може да е някаква нова концепция за програмиране и сте се опитали да прекарате времето си и да ги потърсите в Google. „Контрольор срещу мениджър“.

Така че не бъркайте себе си и другите. Просто изберете 1 дума на понятие и се придържайте към тях през цялото време.

Заключение

За мен най-важният момент в тази глава всъщност е относно товакак да разкриете намерението на вашия код по ясен и ясен начин. Смислените имена играят най-важна роля тук.

Смислените имена обаче не идват лесно. Понякога отнемаше време и няколко преработки, за да се получи. Така че не бързайте в процеса.

Лесна стъпка за действие

Отворете кодовата си база сега и вижте дали има някаква променлива или функция, която можете да преименувате за по-голяма яснота и разбиране.

Забележете

Тази публикация е част от резюмето за четене, което написах в Gitbook. Можете да прочетете Gitbook тук.

Чувствайте се свободни да ми дадете всякакви конструктивни отзиви и предложения, в случай че пропускам нещо наистина важно от книгата.

Надявам се да ви хареса и благодаря за четенето.