Такі інструменти, як pc-lint або QAC, можуть використовуватися для аналізу статичного коду на основі коду.
На мій досвід, статичний аналіз часто видає величезну кількість шуму, тобто попередження про речі, які не є справжніми помилками, але якимось чином порушують одне з правил у заданому наборі правил. Вимкнення певних правил (на користь у наборі правил або за допомогою спеціальних коментарів у коді) може бути справжнім громіздким процесом.
Які реальні переваги аналізу статичного коду?
Відповіді:
Я працював у місці, яке використовувало комерційну систему аналізу статичного коду під назвою Coverity Prevent, і це було дивовижно! Це справді витончено і розумно.
Ми кинули на це близько 18 ГБ як відкритого, так і фірмового коду C і C ++, і він простежив би кодові шляхи і швидко знайдеть тонкі помилки, які вічно потребують людини для пошуку. Також було чудово визначити речі, які зазвичай були Гайзенбугами.
Він проходив кожні кілька днів проти нашої кодової бази, і приємною особливістю було те, що ми могли сказати йому: "Це насправді не помилка", і це буде пам'ятати про це в майбутньому.
Гатча, Покритість дійсно дорога. Вони не публікують витрат, але я розумію, що для комерційних проектів це починається в сотні тисяч доларів на рік. Але це, ймовірно, врятувало нас, що потрібно найняти цілу купу розробників та персоналу з контролю якості, тому в цілому наше керівництво, здається, вважало це гарною покупкою.
Маючи такий досвід, я дуже прихильно дивлюся на статичний аналіз коду.
Починаючи з нової мови, приємно мати тренера. Ось так я думаю про інструменти статичного аналізу. Я пишу багато javascript, і на початку я підхопив кілька шкідливих звичок, головним чином тому, що я перекладав деякі речі з попередніх мов. Javascript є досить гнучким, так що ви можете піти майже з усього, але якби я jslint попереджав мене про певні шаблони, я б зібрав кращі шаблони кодування з самого початку, замість того, щоб пізніше вивчати речі.
Статичні аналізатори - це в основному машинні огляди коду. Вони вказують на сумнівні області, які можуть бути пропущені під час регулярного тестування.
Наприклад, чи справді автор мав намір зробити завдання в цьому умовному?
if (x = 1) {
...
}
Або, можливо, новичок плутає лексичний кастинг:
char* number = "123";
int converted = number;
Безумовно, статичні аналізатори вимагають налаштування. Потім знову, контроль редагування, вікі, трекер помилок, гарні принтери та інші інструменти також потребують налаштування. Чим більший проект, тим краща винагорода за початкову працю.
З точки зору консультанта, кожен інструмент статичного аналізу матиме певний шум, але не всі статичні аналізатори створюються рівними. Статичні інструменти аналізу, такі як Coverity, Klocwork, Grammatech, мають хороші методи аналізу, які повинні дати більш точні результати. Якщо ви налаштовуєте та підготуєте ще кілька, то зазвичай ви отримуєте кращі результати (адже статичні аналізатори повинні мати можливість працювати на всіх різних типах коду від крихітного медичного пристрою до мережевої операційної системи). Визначення "шуму" також залежить від ваших критеріїв того, що являє собою надійний звіт. На одному кінці спектру деякі розробники відзначають усі звіти, які вони не фіксують як "помилкові" (навіть погано написаний код, який у них немає часу на виправлення), а з іншого -
Деякі з цих інструментів більш орієнтовані на центральний аналіз, а інші - більш орієнтовані на робочий стіл, хоча всі три мають функції, які підтримують обидва. Як згадував @Bob, вони коштували грошей.
Статичний аналіз може бути виконаний і без інструментів, виконуючи вручну огляди програмного коду. Це часто найвигідніший спосіб поліпшити якість коду.
Другий найкращий варіант - вкласти гроші в один або кілька інструментів статичного аналізу високого класу (наприклад, раніше згадуваний покриття чи KLOCwork). Оскільки ці інструменти виконують набагато глибші аналізи, ніж ворсинки, наприклад, співвідношення сигнал-шум набагато краще.
Я вважаю використання ворсинок як третій варіант, через високий рівень шуму. Застосування линту до існуючого проекту може бути непростим завданням.
Загалом статичний аналіз програм за останні роки значно прогресував. Сучасні інструменти статичного аналізу здатні виконувати глибокі міжпроцедурні аналізи, які можуть автоматично ідентифікувати, наприклад, перед- та після умов процедури. Це може бути чудовою підмогою і для подальших оглядів коду.
Через високу хибну позитивну частоту не слід використовувати інструмент статичного аналізу (наприклад, lint або FindBugs) для кожної компіляції.
Швидше, це приємна перевірка обґрунтованості, щоб проконсультуватися, як тільки у вас є помилка, і ви не можете цього зрозуміти . У цьому випадку ви можете розважити помилкові позитиви, і, можливо, ви вже звузили можливі джерела помилки. Наприклад, якщо ви відтворюєте помилку, навіть не виконуючи якийсь модуль, ви можете ігнорувати, що FindBugs каже на них. Це особливо корисно, коли ви дивитеся на фрагмент коду і думаєте, що він говорить одне, тоді як компілятор читає його буквально (наприклад, на Java, коли у вас є equalsметод, який замість класу приймає тип класу Object).
Ви також можете статичні засоби аналізу бути частиною вашого процесу розробки: Коли розробник отримує огляд коду, він також повинен запускати FindBugs на ньому. Коротше кажучи, це корисно, але ви не будете використовувати його так часто, як компілятор чи текстовий редактор.