Чи є мета, що стоїть за кодом, «ідіоматичною», щоб зменшити когнітивні накладні витрати?

Я намагаюся пояснити комусь, що те, як вони написали код, робить його важким для розуміння, і якщо ви переробляєте його, то читати його простіше. Цей стиль коду, за яким я воджу, зазвичай називають "ідіоматичним" кодом.

Але словосполучення ідіоматичний код приносить із собою багаж моральної коректності , що не є великим мотиватором змусити людей змінити стиль кодування. Більш позитивний спосіб сказати це - код, який слід загальноприйнятому стилю, але критичному мислителю, який зустрічається як міркування ментального стада.

Я пояснив цю ідею так, що мотивує людей змінювати код:

• написання коду таким чином, що воно зменшує когнітивні накладні витрати читача (наприклад, я не можу пригадати, чи це вектор першого типу - або 5-й вид вектора)
• код, який полегшує розуміння наміру (наприклад, для чого цей вектор?)

(Як осторонь, я знаю, що книга "Радість Клуджура" до її першого видання мала назву проекту "Ідіоматична кложур". Тому, здавалося б, причина для того, щоб зробити код "ідіоматичним", щоб "приносити радість читачеві" ).

Моє запитання: чи є мета, що стоїть за кодом, "ідіоматичним", щоб зменшити когнітивні накладні витрати?

По-перше, я не впевнений, що в терміні "ідіоматичний" є якась "моральна коректність". Визначення простого словника просто

властиві або характерні для певної мови чи діалекту: ідіоматична французька.

Так, ідіоматичний код, як правило, зменшує когнітивні накладні витрати, особливо при визначенні інтерфейсу, де стандартні бібліотеки та будь-які сторонні бібліотеки, для яких потрібен проект, є практично ідіоматичними.

Як торгове місце, я хотів би зосередитись на тому, що зменшує когнітивний накладний розцінок для вас. Програмістам полегшує виявлення помилок, оскільки вони не намагаються розгадати код, написаний в унікальному стилі, щоб зрозуміти, де він тонко вимикається одним або неправильно обробляє крайовий регістр. Це полегшує перегляд коду інших людей, що робить більш імовірним, що команда зробить реальні огляди, що визначають реальні проблеми, а не сперечається про синтаксис.

Крім зниження когнітивних накладних витрат, ідіоматичний код, як правило, є більш ефективним кодом. Більшість ідіом у певній мові розвиваються тому, що мова створена для певного підходу до проблем. Компілятори чи інтерпретатори, які ви використовуєте, зосереджують свої оптимізації на ідіоматичному коді. Якщо ви використовуєте мову, де рекурсія є ідіоматичним способом структурування фрагмента коду, наприклад, ви можете бути впевнені, що ваш компілятор реалізує хвостову рекурсію. Якщо ви використовуєте мову, де рекурсія не є ідіоматичною, це набагато рідше. Малоймовірно, що хвостова рекурсія не може бути реалізована скрізь, але більшість авторів-компіляторів не будуть зосереджені на речах, які трапляються не так часто.

Я не впевнений, звідки ви розумієте, що ідіоми мають якісь моральні конотації. Ідіоми - це лише спосіб виразити речі. Вони є візерунками в масштабі більше, ніж окремі слова чи фрази.

Якби я сказав вам, що треба вити з вовками, ви б не знали, що я маю на увазі, хоча це добре відома німецька ідіома. Якщо, OTOH, я вам казав, коли в Римі робіть так, як роблять римляни, ви відразу зрозуміли б, про що я говорю, бо я застосував належну англійську ідіому.

Мови комп'ютерів не відрізняються.

Власне, альтернативна назва "ідіоми" у світі програмування - "модель реалізації". Це пов'язує ідею з ідеєю шаблонів, яка походить від архітектора (цегла-міномет не біт-байтів) Крістофера Олександра. Більшість програмістів знають про шаблони дизайну, деякі знають про шаблони архітектури, які є візерунками в масштабі більше, ніж шаблони дизайну. Ідіоми - це візерунки в масштабі, меншому, ніж у дизайні.

Більшість мов навмисно піддаються певному стилю. Код, написаний у цьому стилі, є тим, що є ідіоматичним. Якщо ви озираєтесь навпроти того, що вибір середовища виконання звужує ваш доступний вибір мов, ви повинні вибрати мови, оскільки проблема, яку ви можете знайти, легко виразити в конкретних ідіомах мови.

Більшість людей цього не розуміють. Наприклад, багато Java-програмісти намагаються зберегти той самий стиль, коли їм доводиться писати JavaScript (вони могли писати Java і перекладати це наскрізь, майте на увазі) і до певної міри досягають успіху - написання коду, який є Java-ідіоматичним в JavaScript - але вони завжди матимуть відчуття боротьби з JavaScript. Не вистачає певних особливостей або важко наслідувати їх.

Ідіоматичний код хороший. Стороннім важко, але вони можуть навчитися. Зрештою, код потрібно підтримувати роками, тож якщо ви зможете знайти мову, в межах ідіом якої основна програма може бути висловлена ​​чітко, це вам слід зробити.

Дозвольте мені лише уточнити, що напевно є таке поняття, як надмірне використання ідіом (або основні мовні особливості). Якщо ви використовуєте шаблони C ++ для виконання значних частин логіки програми під час компіляції або якщо ваша повна програма Lisp - це виклик деякого макросу, який розгортається до фактичної речі практично непередбачуваними способами, якщо ваше вирішення простої проблеми на Java надувається пропорції FizzBuzzEnterpriseEdition ... ти робиш це неправильно.

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