Захотелось мне объективных критериев качества кода и конечно я вспомнил про свои давние наработки (коллекцию нефункциональных тестов, см. тут и тут).
Ещё тогда была идея оформить их не в виде коллекции тестов, а в виде отдельной утилиты, но удалось сделать только теперь, встречаем perlqual (от perl quality).

Пока перенёс ранее накопленные тесты, добавил только проверку на DELMEAFTER (чтобы в коде написать DELMEAFTER 2016-01-01 и тесты ругнулись что забыл удалить).
Как неоднократно писал — тесты не могут определить хороший код, но могут обнаружить плохой. Хотя при нынешней моде на нейронные сети с глубинным обучением можно попробовать сделать робота который будет узнавать хороший код, но для этого надо иметь очень большую базу кода о котором точно известно что он хороший, не думаю что CPAN сойдёт за эталон.
Итак, под неплохим кодом подразумевается:
  • код который покрыт тестами как минимум на 70% — 100% добиться не всегда просто, но ниже 70 означает что тестов просто нет
  • код чьи метрики сложности не выходят за рекомендованные пределы
  • код который соблюдает рекомендации Perl Best Practice
  • код соблюдающий единый стиль кодирования
  • код в котором не осталось ничего забытого (отладки, пометок)
  • код оформленный в стандартный дистрибутив
  • код имеющий документацию

Все параметры данных проверок настраиваются в конфиге, дефолтный конфиг живёт в самом скрипте в секции __DATA__, можно положить себе копию в хомдиру или в папку проекта и настраивать под себя.
Утилита выводит результат в формате TAP и думаю будет полезна для предварительной оценки кода до code review.
Понятное дело что делал под себя и возможно не везде получилось достаточно универсально, поэтому замечания и предложения приветствуются.
Надеюсь утилита будет полезна.

Комментарии (22)


  1. Sasha_Pitenin
    09.02.2016 12:02

    Что то статья короткая, можно же было привести как нужно писать, а как нет.


    1. worldmind
      09.02.2016 12:06

      Да это на многотомник тянет, одни только PBP это уже книга.


  1. pavelodintsov
    09.02.2016 13:27
    -1

    Как выжимку из PBP можно использовать вот это: www.reg.ru/coding_standards Довольно грамотные рекомендации.

    Но главная рекомендация для поддержки крупного проекта на Perl — никогда в жизни не писать на Perl что-либо длиннее сотни строк.


    1. dmrt
      09.02.2016 13:59

      В одном модуле не больше сотни строк?


      1. pavelodintsov
        09.02.2016 14:07

        Там написано «в одной функции».


        1. ivanych
          09.02.2016 14:42
          -1

          Где «там»?


          1. igorsd
            09.02.2016 14:51

            8.2. Рефакторинг

            Там.


          1. pavelodintsov
            09.02.2016 14:53

            Там — это «тут»: www.reg.ru/coding_standards


  1. igorsd
    09.02.2016 14:25

    sudo make install

    А отсутствие Makefile, никому не помешает?


    1. worldmind
      09.02.2016 20:08

      Да, косяк, поправил, это потому что Makefile обычно генерится и он в .gitignore, а тут пока руками сделал, планирую скоро на стандартную схему перевести