Объективные критерии качества Perl кода

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

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

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

    Похожие публикации

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

        Но главная рекомендация для поддержки крупного проекта на Perl — никогда в жизни не писать на Perl что-либо длиннее сотни строк.
          0
          В одном модуле не больше сотни строк?
          0
          Лучше использовать Perl::Critic + Perl::Tidy, например, как плагин для vim.
            0
            В перл критике много упоротых вещей — его нужно употреблять ограничено :)
              0
              он конфигурится, как минимум severity, да и отдельные правила можно отключать, хотя по мне дефолтные настройки нормальные
              0
              чем лучше?

              upd, а речь о том что лучше чем стандарты reg.ru, тогда да
                0
                Лучше тем, например, что Perl::Tidy автоматически форматирует код по правилам PBP, со всеми отступами и пробелами. Руками это делать не реально.
                  0
                  Никак не могу согласиться. Имея несколько больших проектов годами делаю хорошее форматирование руками.

                  Сложности нет, после выбора определенного стиля — период привыкания маленький, дальше всё делается автоматически на уровне рефлексов.
                    0
                    С Perl::tidy можно любой кусок кода, не ваш, например, привести к стандарту.
                    И незаменимо для команд разработчков.
            0
            sudo make install

            А отсутствие Makefile, никому не помешает?
              0
              Да, косяк, поправил, это потому что Makefile обычно генерится и он в .gitignore, а тут пока руками сделал, планирую скоро на стандартную схему перевести
                0
                make тоже может отсутстовать, так что рекомендуют использовать Module::Build, на пример.
                0
                Перевёл на стандартную для перловых модулей схему с Makefile.PL
                Если нет make это может означать только что модули не ставятся с CPAN, а только из репозиториев, в таком случаем несложно сделать пакет с помощью checkinstall на другой машине
                  0
                  Вроде бы, под Windows make надо ставить отдельно.
                    0
                    ) про такое я даже и не подумал, как там с перлом на винде даже не представляю, юзал в студенчестве что-то (вероятно active perl), но без установки CPAN модулей.
                0
                Попробовал оценить качество кода самого скрипта и получил кучу ошибок. Могу скинуть дамп в личку, если что. Ну, и при большом кол-ве кода вывод становится не читаемым (слишком много шума).
                  0
                  Да, сапожник без сапог, качество самого скрипта пока хромает, я тестил на реальном проекте, там почти все тесты проходят нормально.
                  А сам скрипт сейчас перерабатываю, по результатам переработки тестирование самого себя заработает как надо.
                    0
                    Теперь сам себя протестит (может только make manifest потребоваться), хотя я для него часть тестов отключил — покрытие тестами тут почти не нужно, ибо модуль это обёртка над кучей модулей у которых свои тесты, а нормальный POD пока лень писать.

                    P.S. установка изменилась, теперь надо традиционный perl Makefile.PL делать

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое