Чи можна поняття Entropy використовувати для аналізу вихідного коду корисним способом?

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

Вже існує низка заходів складності коду:

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

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

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

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

Найближчим аналогом термодинамічної ентропії є ентропія Шеннона, яка вимірює кількість розладу у випадковій змінній. Це поняття стосується насамперед кількості "інформації" у повідомленні.

У зв'язку з цим фрагмент коду може мати багато інформації (висока ентропія), але дуже низьку складність. Придумайте програму, яка просто виводить дуже довгу нитку довільних символів. У ньому багато інформації, але низької складності.

Ентропія - це "міра розладу [або] непередбачуваності". Більш широкий спектр унікальних моделей інформації (тобто приблизно "більше значення") вказує на більш високий ступінь ентропії.

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

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

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

Один із способів думати про ентропію - це "середня інформація, яку потрібно отримати", тому я вважаю, що краще повернутися до моделювання інформації. Я знаю два основних підходи до математичного моделювання інформації. (Пробачте, що я дав посилання у Вікіпедії, але в ІМХО вони непогані.)

• Інформація Шеннона , яка розглядає набори символів, розподіл ймовірностей на ті, коди, які можуть передавати інформацію між наборами символів, і довжиною цих кодів. Загальні поняття ефективності коду, шуму, виявлення та виправлення помилок за рахунок надмірності та ін. Викладені з точки зору теорії інформації Шеннона. Один із способів висловити інформацію - сказати, що це довжина найкоротшого двійкового коду, який міг би представляти символ. Це ґрунтується на ймовірності, яка є числовим значенням, присвоєним символу чи події деяким спостерігачем.

• Соломонофф (або Колмогоров ) інформація. Ось ще одне пояснення. У цій формулюванні інформаційний вміст символу чи події представлений довжиною найкоротшої програми, яка могла б його обчислити. Знову ж таки, це відносно не до спостерігача, який призначає ймовірність, а до універсальної машини, яка може виконувати програму. Оскільки кожна універсальна машина може бути змодельована універсальною машиною Тюрінга, це означає, в деякому сенсі, що інформаційний зміст символу чи події не є відносним, а абсолютним.

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

Набагато краще вважати (як я це робив під час вивчення AI), що функціональна характеристика програми складається з ментальної моделі, яка не тільки реальна, але і ефективно кодується, тобто з досить невеликою надмірністю, що змінює думку про вимоги це можна зробити без особливої ​​небезпеки зробити внутрішньо непослідовним - тобто мати "помилку". Тоді процес програмування - це інформаційний канал, який приймає в якості ментальної моделі, а її вихід - робочий вихідний код. Потім, коли змінюється ментальна модель, ця дельта повинна подаватися через процес програмування і перетворюватися на відповідну дельту у вихідному коді. Ця дельта легко виміряти. Розрізняйте джерело між тим, як застосувати цю дельту, і після її застосування (повністю, з усіма помилками), і підраховувати кількість кодових блоків, вставлених, видалених та замінених. Чим менше, тим краще мова вихідного коду представляє мову, на якій представлена ​​ментальна модель (з приводу іменників, дієслів та структури). Якщо цей показник якимось чином усереднюється за простором ймовірних функціональних змін, то це поняття ентропії мови-джерела, а менше - краще. Для цього є термін -Мова домену (DSL)

Вибачте, якщо посилання є слабкими / особистими, але я думаю, що це загальне питання є дуже важливим.

Джон Джаггер та Ольве Модаль дещо відрізняються поглядом на Entropy Code, як це можна побачити на їх сесії конференції Accu 2011 року " Entropy and Physics of Software" .

Вони говорять про стабільність коду, пов'язану з тим, чи можуть майбутні розробники / технічні працівники змінити цей код.

Щоб продемонструвати це, вони провели опитування з низкою фрагментів коду, і результати були досить цікавими.

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

плюс 16 інших.

Загальна тенденція виглядала як полегшення розуміння коду, так і складніше для неправильного розуміння.

Вони також розглядають деякі зміни, внесені у велику кодову базу за ці роки.

Хоча слайди самостійно страждають від того, що вони не є стенограмою сесії, все ж є ще деякі цікаві моменти.

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

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

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

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

Тож можна подумати, тоді я можу обчислити щось на зразок Entropy / CodeLines, використовуючи коефіцієнт стиснення як коефіцієнт, для вимірювання якості коду, однак у цьому є проблема, що загальний випадковий вхід виглядатиме як найкращий код у світі, який, очевидно, не є.

Дійсно, коефіцієнт стиснення є хорошим вимірювачем для вимірювання ентропії коду, проте обидва не є хорошими вимірювачами якості коду.

Що ж, термін ентропія з'являється не тільки в термодинаміці та теорії інформації, але й з'являється в реальному світі стиснення даних. У цьому контексті ентропія, яку бачить компресор, дорівнює кількості бітів, які він виробляє. (Зверніть увагу, що я сказав "ентропія, яку бачить компресор ", тому що те, що вважається ентропією, залежить від моделі, яку компресор використовує для опису вхідних даних. Це причина, чому різні компресори створюють файли різного розміру: Що таке ентропія для одна - експлуатаційна структура, а інша.)

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

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

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

Код має рівно стільки ентропії, скільки число π.

Зміст коду та зміна коду можуть запровадити ентропію (оскільки можлива зміна стану).

Але код - це просто велика кількість. З двійковим поданням.