Как читать / улучшать индекс CRAP, рассчитанный с помощью PHP

Question

Я только начал работать с PHPUnit и его красочными отчетами о покрытии кода.Я понимаю, все цифры и проценты, кроме одного: индекс CRAP.Может ли кто-нибудь предложить мне четкое объяснение того, что это значит, как его анализировать и как понизить?

Answer 1

@ Toader Михай дал убедительное объяснение. (+1 от меня)

Как понизить его:

Пишите менее сложный код ИЛИ пишите более проверенный код.(См. График ниже)

Лучший проверенный код?

В этом контексте это просто означает: более высокий охват кода и, как правило, приводит к написанию большего количества тестов.

Менее сложный код?

Например: реорганизовать ваши методы в меньшие:

// Complex
function doSomething() {
    if($a) {
        if($b) {
        }
        if($c) {
        }
    } else {
        if($b) {
        }
        if($c) {
        }
    }
}

// 3 less complex functions
function doSomething() {
    if($a) {
        doA();
    } else {
        doNotA();
    }
}

function doA() {
    if($b) {
    }
    if($c) {
    }
}

function doNotA() {
    if($b) {
    }
    if($c) {
    }
}

(просто тривиальный пример, вы найдете больше ресурсовдля этого я уверен)

Дополнительные ресурсы:

Прежде всего позвольте мне предоставить некоторые дополнительные ресурсы:

Сообщение в блоге авторов об индексе дерьма

на всякий случай: Объяснение цикломатической сложности .Такие инструменты, как PHP_CodeSniffer и PHPMD сообщат вам это число на случай, если вы захотите узнать.

И пока вам решать, какое число «в порядке», одно часто рекомендуемое число (то есть небольшое число imho)индекс дерьма, равный 30 , в результате чего график выглядит следующим образом:

(файл .ods можно получить здесь: https://www.dropbox.com/s/3bihb9thlp2fyg8/crap.ods?dl=1)

Answer 2

По сути, он хочет быть предиктором риска изменения метода.

В нем есть два фактора:

• сложность кода метода (cyclomatic complexity) или количество путей принятия решений в указанном методе: comp(m).
• насколько тестируем этот метод (с помощью автоматических тестов, предоставляемых инструментом покрытия кода).В основном это измеряет, сколько решений в указанном коде автоматически тестируется.

Если метод имеет 100% охват, риск изменения считается равным только сложности метода: C.R.A.P.(m) = comp(m).

Если метод имеет 0%охват, чем риск изменения, считается полиномом второй степени в меру сложности (из-за того, что если вы не можете протестировать изменение пути к коду, это увеличивает риск поломки): C.R.A.P.(m) = comp(m)^2 + comp(m)

Надеюсь, этопоможет вам.

Я только что заметил, что даю только половину ответа (прочитанная часть).Как это улучшить, должно быть достаточно понятно, если вы понимаете причины индекса.Но гораздо более четкое объяснение дано в ответе @ edorian .

Короткая история такова: пишите тесты до тех пор, пока вы не достигнете почти 100% покрытия, а после этого реорганизуйте методы для уменьшения цикломатической сложности,Вы можете попытаться провести рефакторинг до проведения тестов, но в зависимости от реальной сложности метода вы рискуете ввести поломку, если не можете объяснить (из-за сложности) все последствия изменений, которые вы делаете.