Изкуството на разбираемия код

Лесни и практически техники за писане на по-добър код. Като програмисти всички сме виждали сорс код, който е толкова неразбираем и изпълнен с грешки, че ни докарва главоболие. През последните пет години авторите Дъстин Босуел и Тревор Фучър успяха да съберат и анализираха стотици примери за "лош програмен ход" (голяма част от които са написани от самите тях). В резултат на тези изследвания те установиха какви са причините един код да бъде "лош" и създадоха техники за неговото подобряване. какви са техните изводи? Трябва да пишете програмите си така, че времето, необходимо някой да разбере кода ви, да бъде минимално - дори ако този "някой" сте вие.

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

С книгата ще научите как да:

• опростявате именуването, коментираното и форматирането с помощта на съвети, които са приложими за всеки програмен ред
• преработвате циклите, логиката и променливите в програмата си, за да намалите сложността им и вероятността от объркване
• решавате проблеми на функционално ниво, като реорганизирате блоковете с код така, че да изпълняват задачите една по една
• Пишете ефективни тестове, които са изчерпателни и в същото време кратки - и разбира се, четивни

Дъстин Босуел е завършил университета CalTech и в продължение на пет години е работил за Google върху инфраструктурата за търсене на уеб страници и програмите за реклама. Той е създал уеб сайта и обожава да работи с "големи данни" и в областта на машинното обучение.

Тревор Фучър е прекарал миналия век в Microsoft като инженер, мениджър и технически ръководител на разработки на продукти за Windows и продукти, касаещи сигурността. Освен това е работил за Google върху програмите за реклами и инфраструктурата за търсене.

Предговор
Програмният код трябва да бъде лесно разбираем

• Какво прави един програмен код "по-добър"?
• Основна теорема на разбираемостта
• По-малкото винаги ли е по-добро?
• Времето за разбиране противоречи ли на други цели?
• Трудната част

Козметични подобрения

• Добавяне на информация към имена
• Избор на специфични думи
• Откриване на "по-оригинални" имена
• Избягване на универсални имена като tmp и retval
• Използвайте конкретни имена, вместо абстрактни
• Добавяне на допълнителна информация към име
• Колко дълго трябва да бъде едно име?
• Използвайте форматиране на имената, за да изразите някакво значение
• Резюме
• Имената не трябва да бъдат подвеждащи
• Пример: Filter()
• Пример: Clip(text, length)
• Избирайте min и max за граници (включващи минимума или максимума)
• Избирайте first (първи) и last (последен) при използване на диапазони,
• включващи долната и горната граница
• Използвайте begin (начало) и end (край) за диапазони,
• които включват началото, но изключват края на диапазона
• Именуване на променливи, съдържащи логическа стойност
• Съответствие с очакванията на потребителите
• Пример: избор на име от няколко възможни решения
• Резюме
• Естетика
• Защо естетиката има значение?
• Пренареждайте новите редове, за да осигурите консистентност и компактност
• Използвайте методи, за да отстраните безпорядъка
• При необходимост използвайте подравняване в колони
• Избирайте логическа последователност и я използвайте закономерно
• Организирайте декларациите в блокове
• Разделете кода си на "параграфи"
• Собствен стил срещу консистентност
• Резюме
• Къде трябва да се поставят коментари
• Къде НЕ трябва да поставяте коментари
• Записвайте идеите си
• Поставяйте се на мястото на читателя
• Последни размисли - преодоляване на "творческата криза" на писателя
• Резюме
• Писане на прецизни и компактни коментари
• Придържайте се към писане на компактни коментари
• Избягвайте двусмислените местоимения
• Изпипвайте добре изреченията
• Прецизно описвайте поведението на функциите
• Използвайте примери за входяща/изходяща информация,
• която илюстрира особените случаи
• Упоменавайте предназначението на кода си
• Коментари за именувани параметри на функции
• Използвайте специфични, информационни думи
• Резюме

Опростяване на циклични структури и логика

• По-разбираемо управление на изпълнението
• Подредба на аргументите в условни изрази
• Подредба на блоковете if/else
• Условен израз ?: (наричан още „Троичен оператор“)
• Избягвайте цикли do/while
• Преждевременно излизане от функция
• Скандалният оператор goto
• По-малко влагане
• Можете ли да проследите изпълнението на програмата?
• Резюме
• Раздробяване на огромни изрази
• Поясняващи променливи
• Обобщаващи променливи
• Използване на законите на Де Морган
• Злоупотреба със short-circuit логиката
• Пример: справяне със сложна логика
• Раздробяване на огромни изрази
• Друг креативен начин за опростяване на изрази
• Резюме
• Променливи и четивност
• Премахване на променливи
• Намалете областта на действие на своите променливи
• Използвайте променливи с постоянна стойност
• Последен пример
• Резюме

Реорганизиране на кода

• Отделяне на второстепенни проблеми
• Въвеждащ пример: findClosestLocation()
• Изцяло помощен код
• Друг код с общо предназначение
• Създавайте много код с общо предназначение
• Функционалност, специфична за проекта
• Опростяване на съществуващ интерфейс
• Преобразуване на интерфейс в съответствие с вашите нужди
• Твърде сериозно приемане на нещата
• Резюме
• Изпълнявайте задачите една по една
• Задачите могат да бъдат малки
• Извличане на стойности от обект
• По-голям пример
• Резюме
• Превръщане на мисли в код
• Обясняване на логиката на разбираем език
• Познаването на библиотеките помага
• Прилагане на метода за решаване на по-големи проблеми
• Резюме
• Писане на по-малко код
• Не имплементирайте този елемент - той не ви е необходим
• Оспорвайте и намалявайте изискванията си
• Поддържане на малък обем на кода
• Разучете библиотеките си
• Пример: използване на инструменти на Unix вместо писане на код
• Резюме

Избрани теми

• Тестване и четивност
• Разработвайте тестове, които са лесни за четене и поддръжка
• Къде е проблемът в този тест?
• Подобряване четивността на теста
• Подобряване четивността на съобщенията за грешки
• Избор на подходящи входни данни за тестване
• Именуване на тестови функции
• Какви бяха грешките в този тест?
• Разработки, подходящи за тестване
• Твърде сериозно приемане на нещата
• Резюме
• Проектиране и имплементиране на "брояч минута / час
• Задачата
• Дефиниране на класа за интерфейса
• Първи опит: просто решение
• Втори опит: конвейерен дизайн
• Трети опит: дизайн с ограничени времеви групи
• Сравняване на трите решения
• Резюме
Допълнително четиво
Индекс