Критерии выразительности кода

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

Как вариант, можно смотреть насколько код близок к прозе (все названия - или из словаря, или их сокращения, умеренное использование спец. знаков).

Из соседнего треда, раз:

1. Соответствие правилам оформления кода в компании. Они вполне конкретны и часто в компании есть анализаторы, которые будут выдавать что где и почему в твоей программе не соотв. правилам.

2. Разумные примеры:

а) если в коде присутствуют однобуквенные переменные введенные программистом k, n и пр. — это жирный минус к коду, если есть однобуквенная переменная l — это просто говнище, а не код. Вполне конкретный критерий...

б) Количество команд в одной строчке > 2 — минус к коду...

в) Отсутствие комментариев перед определением функции — минус к коду...

и пр.

В целом же, конечно, это все критерии для субъективных показателей:

1. как быстро другой программист поймет твой код

2. насколько удобно код модифицировать

3. насколько он удобен для повторного использования

4. насколько он защищен

5. насколько он быстр (только в задачах где это нужно, в остальных же ПОНЯТНОСТЬ кода важнее скорости, т.е. можно пожертвовать скоростью, напр. внести что-то доп. в цикл, чтобы код был понятней)

Два:

WTF per minute

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

Единственный критерий это человек, который занимается программированием хотя бы 7-19 лет, имеющий опыт в разных областях, а значит работавший с разными языками. Если такому человеку читать какие-то исходники сложно, несмотря на подготовку(изучение языка проекта, архитетуры и тд), то его мнение можно брать в расчёт.

Все остальные мнения и критерии - полное дерьмо и никак ни на что не влияют. Потому что можно сделать язык, который вроде бы хорошо читается(привет Ada), но реальные проекты на этом языке всё равно будут нечитаемы для новичка, потому что он банально не будет понимать что происходит, почему и где.

Есть цикломатическая сложность. Можно её нормировать на размеры участков кода. Но оно всё равно останется субъективным и можно разве что подогнать подобные метрики к какому-то определённому вкусу.

Чем больше слов, тем читабельней. Чем больше всяких сокращений и неуместных знаков пунктуации, тем нечитабельней.

Хм, а как насчёт всякой жути в триггерах на SQL, где элементарные вещи, делаемые на каком-нибудь C++, делаются с помощью SQL примерно в 5-10 раз большим количеством как строк, так и длиной строк? Получается, что программист должен распарсить больше, это тратит его ресурс.

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

Но почему-то эти триггеры обычно продолжают писать на PL/SQL, а не на C++.

чем меньше в языке символов ;^:%'[()]*?@!=,.`&#><}{, тем лучше читаемость

более изящные решения в производительности часто сливают нечитаемым вариантам

Ты запиливаешь бенчмарки говенности языков, и это на порядок лучше, чем исходная задача алиотха. Но я бы не стал учитывать мнение 7-19 летних опытов, т.к. с учетом роста кол-ва кадров на рынке их всегда будет лишь какие-то проценты.

Может вообще запилить опросник вида (лет опыта в Х, лет опыта в /devel, читаемость по шкале [wat, hmm, okay, crystal clear])? Тогда это будет не однобокий датасет, а хоть какое-то средство анализа.

искуственный критерий, чтобы реабилитировать читаемость

Любой искусственный критерий будет учитывать фазу Луны и погоду на Марсе, но только не «читаемость» и «выразительность». Просто присвой определённые баллы «читаемости» каждому тесту своим волюнтаристским решением.

а как насчёт всякой жути в триггерах на SQL, где элементарные вещи, делаемые на каком-нибудь C++, делаются с помощью SQL примерно в 5-10 раз большим количеством как строк, так и длиной строк?

а можно несколько примеров, желательно для Oracle DB?

Нужен какой-то искуственный критерий, чтобы реабилитировать читаемость, начав принимать её во внимание при построении рейтинга.

https://ru.wikipedia.org/wiki/Формальная_верификация

https://habr.com/ru/post/437296/

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

Давно созданы эти критерии, и они сильно зависят от того кто хочет мерить «изящность» покупатель, РАБотник или начальник РАБотника. Среднего нет, ибо такого человека, кому нужно это среднее нет. Каждый тянет на себя одеяло, и в каждом случае кто-то в приоритете. Гули.

В целом достаточно стандарта языка и комментариев перед чем-то сложным для понимания самым тупым членом команды, которая НЕ работает над этим проектом. Возможно, есть ещё какой-то внутренний устав для переносимости, но это частности.

Чем больше слов, тем читабельней. Чем больше всяких сокращений и неуместных знаков пунктуации, тем нечитабельней.

То есть вместо

d = a*a-4*a*c

MULTIPLY A BY A GIVING A2.
MULTIPLY A BY C GIVING AC.
MULTIPLY 4 BY AC GIVING AC4.
SUBTRACT 4AC FROM A2 GIVING D.

Или хотя бы

get a get a mult 4 get a multiply get c multiply subtract put d

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

Тогда самые читабельные APL, K и J.

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

2. Если код _понятен_ большинству на проекте, то код хороший.

3. Если он сходу _понятен_ новым людям на проекте, то код отличный.

4. Если в него быстро въезжают начинающие программисты, то код замечательный.

Других критериев нет.

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

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

Не всегда. На Common Lisp, например, разработка почти всегда в отладчике. Потому что сам процесс так устроен: пишешь прототип, запускаешь, пишешь в REPL тест, который должен упасть, попадаешь в отладчик, из него дописываешь недостающее. Эдакий TDD, но не Test Driven, а Debugger Driven.

Классический ТОП (Теория Относительности в Программировании). Выразительность кода чуть ли не на 100% зависит от наблюдателя, его знаний, умений и прошлого опыта.

Ты не первый на ЛОРе, кто страдает подобной фигнёй.

Ну за лисп спорить не буду - в нём не шарю, но выглядит такое немного странновато. :-)