Можно ли использовать концепцию энтропии для анализа исходного кода полезным способом?

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

Уже существует ряд показателей сложности кода:

• Цикломатическая сложность
• Длина класса
• Длина метода
• Количество полей
• Количество параметров метода
• Сложность N-пути
• Разветвление и разветвление
• Анализ потока данных (цепочки DU / DD)

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

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

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

Ближайшим аналогом термодинамической энтропии является энтропия Шеннона, которая измеряет количество беспорядка в случайной переменной. Это понятие прежде всего касается количества «информации» в сообщении.

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

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

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

Как только модель спроектирована и затем заполнена исходным кодом программного приложения (то есть частот для узлов / ребер), энтропия может быть вычислена.

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

Один из способов думать об энтропии - это «средняя информация, которую нужно получить», поэтому я думаю, что лучше вернуться к моделированию информации. Я знаю два основных подхода к математическому моделированию информации. (Простите, что дали ссылки на Википедию, но ИМХО они не плохие.)

• Информация Шеннона , которая рассматривает наборы символов, распределения вероятностей по ним, коды, которые могут передавать информацию между наборами символов, и длины этих кодов. Общие понятия эффективности кода, шума, обнаружения и исправления ошибок посредством избыточности и т. Д. Сформулированы в терминах теории информации Шеннона. Один из способов выразить информацию - сказать, что это длина самого короткого двоичного кода, который может представлять символ. Это основано на вероятности, которая является числовым значением, присвоенным символу или событию некоторым наблюдателем.

• Соломонова (или Колмогорова ) информация. Вот еще одно объяснение. В этой формулировке информационное содержание символа или события представлено длиной самой короткой программы, которая могла бы его вычислить. Здесь, опять же, это относится не к вероятности назначения наблюдателя, а к универсальной машине, которая может выполнить программу. Поскольку каждая универсальная машина может моделироваться универсальной машиной Тьюринга, это означает, что в некотором смысле информационное содержание символа или события не является относительным, но является абсолютным.

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

Гораздо лучше учесть (как я это делал при изучении ИИ), что функциональная спецификация программы состоит из ментальной модели, которая не только реальна, но и кодируется эффективно, то есть с достаточно маленькой избыточностью, которая меняет представление о требованиях. может быть сделано без особой опасности сделать его внутренне несовместимым - то есть иметь «ошибку». Затем процесс программирования представляет собой информационный канал, который принимает в качестве входных данных ментальную модель, а его выходом является рабочий исходный код. Затем, когда в ментальной модели вносятся изменения, эта дельта должна передаваться в процессе программирования и превращаться в соответствующую дельту в исходном коде. Эта дельта легко измеряется. Различать источник между до применения этой дельты и после ее применения (полностью, со всеми исправленными ошибками), и подсчитайте количество вставленных, удаленных и замененных кодовых блоков. Чем меньше значение, тем лучше язык исходного кода представляет язык, на котором представлена ​​ментальная модель (в терминах существительных, глаголов и структуры). Если эта мера как-то усреднена по пространству вероятных функциональных изменений, это понятие энтропии исходного языка, и чем меньше, тем лучше. Есть термин для этого -Домен-специфический язык (DSL)

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

У Джона Джаггера и Олве Модала немного другое представление об энтропии кода, что можно увидеть на их сессии Accu на конференции 2011 года « Энтропия кода и физика программного обеспечения» .

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

Чтобы продемонстрировать это, они провели опрос с несколькими фрагментами кода, и результаты оказались весьма интересными.

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

плюс 16 других.

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

Они также рассматривают некоторые изменения, внесенные в большую кодовую базу за последние годы.

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

Я учился у профессора , который использовал энтропию как меру сложности программ (наш учебник был старше издание этого один , некоторые из его пабов здесь ). В ФАУ было несколько диссертаций, где это было одной из основных мер, но сайт школы изменился с тех пор, как я в последний раз смотрел, и я не могу определить, где сейчас находятся диссертации / диссертации студентов.

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

Если вам нужно определение «математическое» в смысле энтропии, вы можете посмотреть на сложность Колмогорова, которая измеряет сложность по минимальному объему кода, в котором можно что-то сделать. Однако это не сложность кода, но о том, что вы пытаетесь сделать с кодом. Но вы можете подумать, что это уместно, потому что теоретически вы можете сравнить конкретный фрагмент кода с минимальным. Тем не менее, в настоящее время это не полезный метод для измерения сложности кода реального мира.

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

Можно подумать, тогда я могу вычислить что-то вроде Entropy / CodeLines, используя коэффициент сжатия в качестве коэффициента, для измерения качества кода, однако при этом возникает проблема, заключающаяся в том, что общий случайный ввод будет выглядеть как лучший код в мире, который, очевидно, таковым не является.

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

Что ж, термин энтропия появляется не только в термодинамике и теории информации, но и в реальном мире сжатия данных. В этом контексте энтропия, которую видит компрессор, равна числу битов, которые он производит. (Обратите внимание, что я сказал «энтропия, которую видит компрессор », потому что то, что считается энтропией, зависит от модели, которую компрессор использует для описания входных данных. Это причина того, почему разные компрессоры создают файлы разного размера: что такое энтропия для одна является эксплуатируемой структурой для другой.)

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

Так, например, если язык допускает либо существующий идентификатор, либо что-то, заключенное в скобки, либо продукт в определенной точке, компрессор будет подсчитывать возможные существующие идентификаторы, принимая во внимание информацию о типе (скажем, у вас есть 3 таких идентификатора). ), и добавьте 2 для двух возможных подвыражений, давая 5 возможностей. Таким образом, узел будет закодирован lb 5 = 2.32битами. В случае двух возможных подвыражений потребуется больше битов для кодирования их содержимого.

Это действительно даст очень точную оценку сложности кода, как он есть. Однако эта мера все еще бесполезна! Это бесполезно по той же причине, по которой все измерения сложности кода бесполезны: они не позволяют установить связь между измеренной сложностью кода (какой бы она ни была) и сложностью проблемы, которую код решает. Вы всегда можете найти смехотворно сложные решения ваших программных проблем, чтобы произвести впечатление на вашего работодателя подсчетом LOC, но никакая мера сложности кода не скажет вам, что задача могла быть решена с небольшой долей усилий.

Код имеет столько же энтропии, сколько число π.

Ведение и изменение кода может привести к энтропии (поскольку возможно изменение состояния).

Но код это просто большое число. С двоичным представлением.