Захотелось мне объективных критериев качества кода и конечно я вспомнил про свои давние наработки (коллекцию нефункциональных тестов, см. тут и тут).
Ещё тогда была идея оформить их не в виде коллекции тестов, а в виде отдельной утилиты, но удалось сделать только теперь, встречаем perlqual (от perl quality).
Пока перенёс ранее накопленные тесты, добавил только проверку на DELMEAFTER (чтобы в коде написать DELMEAFTER 2016-01-01 и тесты ругнулись что забыл удалить).
Как неоднократно писал — тесты не могут определить хороший код, но могут обнаружить плохой. Хотя при нынешней моде на нейронные сети с глубинным обучением можно попробовать сделать робота который будет узнавать хороший код, но для этого надо иметь очень большую базу кода о котором точно известно что он хороший, не думаю что CPAN сойдёт за эталон.
Итак, под неплохим кодом подразумевается:
Все параметры данных проверок настраиваются в конфиге, дефолтный конфиг живёт в самом скрипте в секции __DATA__, можно положить себе копию в хомдиру или в папку проекта и настраивать под себя.
Утилита выводит результат в формате TAP и думаю будет полезна для предварительной оценки кода до code review.
Понятное дело что делал под себя и возможно не везде получилось достаточно универсально, поэтому замечания и предложения приветствуются.
Надеюсь утилита будет полезна.
Ещё тогда была идея оформить их не в виде коллекции тестов, а в виде отдельной утилиты, но удалось сделать только теперь, встречаем perlqual (от perl quality).
Пока перенёс ранее накопленные тесты, добавил только проверку на DELMEAFTER (чтобы в коде написать DELMEAFTER 2016-01-01 и тесты ругнулись что забыл удалить).
Как неоднократно писал — тесты не могут определить хороший код, но могут обнаружить плохой. Хотя при нынешней моде на нейронные сети с глубинным обучением можно попробовать сделать робота который будет узнавать хороший код, но для этого надо иметь очень большую базу кода о котором точно известно что он хороший, не думаю что CPAN сойдёт за эталон.
Итак, под неплохим кодом подразумевается:
- код который покрыт тестами как минимум на 70% — 100% добиться не всегда просто, но ниже 70 означает что тестов просто нет
- код чьи метрики сложности не выходят за рекомендованные пределы
- код который соблюдает рекомендации Perl Best Practice
- код соблюдающий единый стиль кодирования
- код в котором не осталось ничего забытого (отладки, пометок)
- код оформленный в стандартный дистрибутив
- код имеющий документацию
Все параметры данных проверок настраиваются в конфиге, дефолтный конфиг живёт в самом скрипте в секции __DATA__, можно положить себе копию в хомдиру или в папку проекта и настраивать под себя.
Утилита выводит результат в формате TAP и думаю будет полезна для предварительной оценки кода до code review.
Понятное дело что делал под себя и возможно не везде получилось достаточно универсально, поэтому замечания и предложения приветствуются.
Надеюсь утилита будет полезна.
Комментарии (22)
pavelodintsov
09.02.2016 13:27-1Как выжимку из PBP можно использовать вот это: www.reg.ru/coding_standards Довольно грамотные рекомендации.
Но главная рекомендация для поддержки крупного проекта на Perl — никогда в жизни не писать на Perl что-либо длиннее сотни строк.dmrt
09.02.2016 13:59В одном модуле не больше сотни строк?
Sasha_Pitenin
Что то статья короткая, можно же было привести как нужно писать, а как нет.
worldmind
Да это на многотомник тянет, одни только PBP это уже книга.