Елементи стилю програмування

Багато технічних книг починаються з жахливо нудного і нудного введення. Винятків небагато, і книга «Ідеальний код», про яку я розповів у минулому пості, — одна з тих, запровадження якої варто прочитати.

Ось перші два абзаци:

Я почав працювати програмістом улітку 1982 року. Через кілька тижнів після цього один із системних адміністраторів дав мені почитати книги The Elements of Programming Style, Brian W. Kernighan, PJ Plauger, і Algorithms + Data Structures = Programs, Niklaus Wirth.

Це стало для мене відкриттям. Я вперше дізнався, що програми — щось більше, ніж прості інструкції для комп'ютера. Вони можуть бути елегантними, як найближче оточення президента, витонченими, як підвісний міст, і промовистими, як есе Джорджа Оруелла.

Напевно, про книгу Вірта чули багато. А ось про стару книгу Кернігана — навряд. У мережі з цього приводу глухо є електронна версія перекладу часів СРСР, але вона лежить на буржуазному ресурсі з погодинним доступом, тому скопіювати її за осудний час неможливо.

стилю

"Елементи стилю програмування" це невеликий

150-сторінковий збірник прикладів коду з поясненнями, чому наведений код гівно. Книга дійсно давня, всі приклади написані на Фортрані і PL/1 з великою кількістю принад а'ля 20 goto 10 , але на увагу заслуговують кілька десятків «правил», розкиданих по всій книзі. Безперечно, ці правила важливі як історія становлення філософії UNIX. Дуже схожі правила можна знайти у книзі Реймонда "Мистецтво програмування для UNIX".

Перефразовуючи висловлювання з елементів стилю (Elements of Style by Strunk & White), правила стилю програмування, як і стилю англійської мови, іноді порушують навіть кращі письменники.Втім, коли правило порушується, зазвичай у програмі знаходиться якась компенсуюча якість, яка досягається за рахунок порушення. Якщо ви не впевнені в покращенні, ймовірно, найкраще буде дотримуватися правил.

    Говоріть те, що ви маєте на увазі просто і прямо.

Сама суть філософії UNIX: «Будь простіше, глухий кут».

Пишіть програми просто – не робіть їх надто хитромудрими.

АналогічноПравилу ясності: Ясність краще за розумність.

Найчастіше цим грішать хаскелісти та великі любителі патернів проектування.

  • Використовуйте бібліотечні функції.
  • Уникайте проміжних змінних.
  • Пишіть зрозуміло – не жертвуйте ясністю заради «ефективності».
  • Нехай машина робить брудну роботу.

    • АналогічноПравилу економії: Час програміста дорого; скоротите його за допомогою машинного часу.

    Замінюйте повторювані вирази викликами функцій.

    Ліспери додадуть: заміняйте повторюючі керуючі конструкції макросами.

    Дужки виключають двозначність.

    Велика кількість дужок у правильних місцях позбавить двозначності, підвищить читаність і збільшить розширюваність - ліспери знають про що я (loop & iterate).

  • Вибирайте імена змінних так, щоб вони не призводили до плутанини.
  • Не використовуйте goto, якщо хочете зберегти програму, що читається.

    • Мантра "структурного програмування".

  • Уникайте непотрібних розгалужень.
  • Використовуйте хороші засоби мови та не використовуйте погані.

    • Над цим правилом вже 20 років ламають голову програмісти на С++.

    Як в анекдоті: якщо Рабінович зможе правильно наспівати вашу програму — вона пройшла тест.

    Використовуйте зсув рядків (іденцію) длярозділення блоків коду.

    Якщо пишіть на пітоні, можете проігнорувати це правило.

  • Робіть програми, що читаються зверху вниз.
  • Використовуйте if і else щоб наголосити на необхідності виконання лише однієї з двох дій.
  • Використовуйте if … else if … else для розгалужень за кількома напрямками.
  • Використовуйте основні конструкції потоку управління.
  • Якщо логічний вираз важко зрозуміти, спробуйте його перетворити.
  • Нехай дані визначають структуру програми.

    • АналогічноПравилу поданняРеймонда: Зберігайте знання даних так, щоб логіка програми була тупою і надійною.

    Спочатку напишіть на псевдокоді, потім переведіть машинною мовою.

    Літературне програмування пішло далі в цьому підході — спочатку напишіть псевдокодом, а потім допишіть машинною мовою.

  • Кожен модуль повинен виконувати одну функцію, але добре.
  • Не виправляйте погану програму – перепишіть її.
  • Пишіть та тестуйте програму невеликими частинами.
  • Використовуйте процедури рекурсії для рекурсивних структур даних.

    • Рекурсія не повинна бути затичкою в кожній бочці (як у мові Scheme), з нею потрібно бути дуже обережним - за вбивчою силою вона близька старому доброму goto (якщо вважаєте інакше - спробуйте розібратися в системі хоча б з трьох взаєморекурсивних функцій). У більшості випадків краще віддати перевагу ітеративним конструкціям рекурсивним.