Могат да се четат код или програмиране като изкуство "

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

Глава 1: Кодът трябва да бъде лесно да се разбере,

Компактен код добре тромави;
Но четим код винаги е по-добре от компактен.

Кодът се чете по-често, отколкото писмено. Колкото по-бързо хората разбират непознат код. така че е по-лесно. Както се разбира от кода лесно да се намери грешки и да ги поправи. без да се скъса с програмата.

С една дума - не винаги по-добре за разбиране:

Затова се стремим към компактност добре. но да се стремим към по-висока четимост по-добре.

Глава 2: Вземете точните имена на променливи. функции и класове

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

Например. в GetPage дума получите неточна функция. Той не обяснява. дали е взето на страницата от кеша или от мрежата. Имена FetchPage или DownloadPage обясни по-добре. какво се случва.

Следващият пример на тялото на функция е ясно. че retval - върнатата стойност.

Въпреки това, не е ясно. че тя съдържа. заради това, просто пропуснете тази грешка:

Вместо абстрактни имена, съдържащи бетон. изостри ситуацията. Такива имена се обясняват. Какво е променлива или функция. Но спецификата помага да се избегне двусмислие.

Представки и наставки изясняват значение. Например. измерване на скоростта на зареждането на уеб страници:

Ако сте запознати с JavaScript. ще забележите грешка - getTime връща резултата в милисекунди. Ето защо, кодът не работи правилно. Ако добавим суфикс _ms. грешката ще се види:

Дължината на името зависи от размера на обхват. Ако променливата е в зависимост от 3 реда. краткото име е подходящ. Но колкото по-обхвата. по-точен името трябва да бъде. Например. days_since_last_update по-добре. от дни.

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

Ако думата не разширява значението на името. по-добре е да го изхвърлите. Например. convert_to_string може да бъде заменен от to_string.

Правилото за избор на име: "Ако един нов член на екипа не може да разбере смисъла на функция или променлива върху името му. това е лошо име. "

Глава 3: Да се избягва двусмислени имена

Името трябва да отразява същността;
Използвайте представки и наставки. За да добавите безсмислен;
Махни от значение.

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

За да се определи точно граница на диапазона. използвате представки или max_ min_. За включително ленти могат да използват представки и first_ last_.

За да използвате булева променлива е префикс. има. може. трябва, и така нататък. д. Действително и функции. които връщат булева стойност.

Глава 4: красив код се чете по-бързо

Използвайте последователен стил. четец използва за това;
Напиши подобен код по подобен начин;
Комбинирайте свързани по смисъла на кодовите битове в блоковете.

Отърви се от несъответствието. Използвайте помощни функции. Например. функция и тест за него:

Две линии не се вместват и скокове към следващата. читателят се заблуди. Това може да се избегне с помощта на комунални функции:

Кодът по себе си е също така да бъде разделен на "точки". Ако една функция се състои от няколко стъпки. Тези стъпки подчертават код празни редове между тях.

Каква е следващата стъпка?