Является ли цель кода «идиоматической» для снижения когнитивных издержек?

Я пытаюсь объяснить кому-то, что из-за того, как они написали код, это трудно понять, и если вы сделаете его рефакторинг, его будет легче читать. Этот стиль кода, на котором я работаю, обычно называют «идиоматическим» кодом.

Но фраза « идиоматический код» несет в себе багаж моральной корректности , который не является хорошим стимулом для того, чтобы заставить людей изменить свой стиль кодирования. Более позитивный способ сказать, что это кодекс, который следует общему стилю - но критическому мыслителю, который воспринимается как логика мышления стада.

Я объяснил эту идею способом, который побуждает людей менять свой код:

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

(Кроме того, я знаю, что книга «Радость Clojure», до ее первой публикации, имела черновой вариант «Идиоматическое Clojure». Так что, казалось бы, причина сделать код «идиоматическим», «доставить радость» читателю ).

Мой вопрос: является ли цель кода «идиоматической» для снижения когнитивных издержек?

Во-первых, я не уверен, что в термине «идиоматический» есть какая-то «моральная корректность». Равнину словарное определение просто

свойственный или характерный для определенного языка или диалекта: идиоматический французский.

Да, идиоматический код обычно уменьшает когнитивные издержки, особенно в определениях интерфейсов, где стандартные библиотеки и любые сторонние библиотеки, в которых нуждается проект (практически), являются идиоматическими.

Тем не менее, я бы хотел сосредоточиться на том, что сокращение когнитивных издержек может сделать для вас. Программистам легче выявлять ошибки, потому что они не пытаются разгадать код, написанный в уникальном стиле, чтобы выяснить, где он скрыт, или неправильно обрабатывать крайний случай. Это облегчает просмотр кода других людей, что повышает вероятность того, что команда сделает реальные проверки, которые идентифицируют реальные проблемы, а не спорят о синтаксисе.

Помимо сокращения когнитивных издержек, идиоматический код, как правило, является более эффективным кодом. Большинство идиом в конкретном языке эволюционируют, потому что язык предназначен для решения проблем определенным образом. Компиляторы или интерпретаторы, которые вы используете, сосредоточат свои оптимизации на идиоматическом коде. Например, если вы используете язык, в котором рекурсия является идиоматическим способом структурирования фрагмента кода, вы можете быть почти уверены, что ваш компилятор реализует хвостовую рекурсию. Если вы используете язык, где рекурсия не является идиоматической, это гораздо менее вероятно. Маловероятно, что хвостовая рекурсия не может быть реализована повсеместно, но большинство авторов компиляторов не собираются фокусироваться на вещах, которые не происходят часто.

Я не уверен, откуда вы взяли, что идиомы имеют какой-то моральный смысл. Идиомы это просто способ выразить вещи. Они представляют собой шаблоны в масштабе, превышающем отдельные слова или фразы.

Если бы я сказал вам, что с волками надо рыдать, вы бы не поняли, что я имел в виду, хотя это хорошо известная немецкая идиома. Если, ОТО, я сказал вам, когда в Риме поступайте так, как делают римляне, вы сразу поймете, о чем я говорю, потому что я использовал правильную английскую идиому.

Компьютерные языки ничем не отличаются.

На самом деле, альтернативное название «идиома» в мире программирования - «шаблон реализации». Это связывает идею с идеей шаблонов, которая исходит от архитектора (кирпичик и миномет, а не биты и байты) Кристофера Александра. Большинство программистов знают о шаблонах проектирования, некоторые знают об шаблонах архитектуры, которые представляют собой шаблоны в масштабе, превышающем шаблоны проектирования. Идиомы - это шаблоны в масштабе, меньшем, чем шаблоны дизайна.

Большинство языков намеренно поддаются определенному стилю. Код, написанный в этом стиле, идиоматичен. Если вы посмотрите за пределы того факта, что выбор среды выполнения сужает ваш доступный выбор языков, вам следует выбирать языки, потому что рассматриваемая проблема легко выражается в конкретных идиомах языка.

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

Идиоматический код это хорошо. Для постороннего это трудно, но они могут учиться. В конечном счете, код должен поддерживаться годами, поэтому, если вы можете найти язык, в рамках которого базовая программа может быть выражена простым способом, это то, что вам следует делать.

Позвольте мне пояснить, что определенно существует такая вещь, как чрезмерное использование идиом (или базовых языковых особенностей). Если вы используете шаблоны C ++ для выполнения значительных частей логики приложения во время компиляции, или если ваша полная программа на Лиспе представляет собой вызов некоторого макроса, который разворачивается к реальному предмету практически непредсказуемым образом, если ваше Java-решение простой задачи раздувается до пропорции FizzBuzzEnterpriseEdition ... вы делаете это неправильно.

Люди говорят, что код должен быть легко читаемым. Это только половина правды. Это должно быть легко понять, а для этого нужно также легко рассуждать. Это требует адекватного использования абстракций. Как и в большинстве случаев, это вопрос правильного баланса.