При коллективной работе над проектами, особенно большими, часто стоит задача проверки и просмотра кода разработчиков перед сборкой. Обычно этим занимается менеджер проекта, часто он же и производит билды для тестирования и для заказчика.
Находясь в подобной роли, я для себя написал тул, проверяющий код на соответствие неким формальным правилам. Правила определены в виде регулярных выражений. Сделал, использую — нравится. Выпустил это в виде trialware.
2. В дистрибутив включены примеры правил для Delphi и то, только общие правила. Как Вы считаете, каким образом лучше организовать обмен правилами, и сбор правил от людей, пишущих на других языках. Понятно, что человек, участвующий в написании правил, поощряется скидкой или бесплатным ключем. Но как это сделать УДОБНЕЕ?
18.02.05 12:19: Перенесено модератором из 'Управление проектами' — Merle
Здравствуйте, softilium, Вы писали:
S>При коллективной работе над проектами, особенно большими, часто стоит задача проверки и просмотра кода разработчиков перед сборкой. Обычно этим занимается менеджер проекта, часто он же и производит билды для тестирования и для заказчика.
Да ... то что программеров припахивают к выявлению требований к системе от заказчика, и тестированию -- это практикуется ... а вот чтобы мереджер проекта сам билды делал ... наверное проект небольшой и он (проект) один, раз у него есть на это время ...
S>Находясь в подобной роли, я для себя написал тул, проверяющий код на соответствие неким формальным правилам. Правила определены в виде регулярных выражений. Сделал, использую — нравится. Выпустил это в виде trialware.
Я думаю народ бы более охотно откликнулся, если бы это был freeware
S>Посмотреть можно здесь: http://www.softilium.com/clearcode/index.htm, там сверху прямая ссылка на скачивание.
S>А теперь вопросы: S>1. Любая конструктивная критика.
Насколько я знаю, теперь такая возможность включена во многие среды разработки ...
Здравствуйте, byur, Вы писали:
B>Да ... то что программеров припахивают к выявлению требований к системе от заказчика, и тестированию -- это практикуется ... а вот чтобы мереджер проекта сам билды делал ... наверное проект небольшой и он (проект) один, раз у него есть на это время ...
Проект большой, но у меня он один сейчас. Я в нем выполняю роль "играющего тренера". Знаю еще по крайней мере несколько команд, которые работают по сходным схемам.
B>Я думаю народ бы более охотно откликнулся, если бы это был freeware
Тогда это будет пионерская поделка, которую автор будет поддерживать по остаточному принципу. Нужен тул такого уровня?
B>Насколько я знаю, теперь такая возможность включена во многие среды разработки ...
Да, только правила проверки зачастую зависят от проекта. Среды разработки обячно включают правила проверки типа warnings/hints, сделанные "на сдачу" от синтаксического разбора текста. Это все же несколько другое.
Re[2]: Проверка исходных текстов перед компиляцией
Здравствуйте, Слава Шевцов, Вы писали:
СШ>А какие ещё существуют аналогичные инструменты?
При обсуждении темы в SWRUS-PROGRAMMING всплыла информация об утилите FxCop, она проверяет .NET assemblies на соответствие гайдлайнам. Насколько я понял, это где-то близко, но не аналог.
Поиском по google можно найти с десяток подобных утилит, но они как правило достаточно дороги и занимаются именно синтаксическим анализом, с помощью которого находятся потенциальные дыры. Здесь совсем другой принцип, все гораздо проще.
Re[3]: Проверка исходных текстов перед компиляцией
Здравствуйте, softilium, Вы писали:
СШ>>А какие ещё существуют аналогичные инструменты?
S>При обсуждении темы в SWRUS-PROGRAMMING всплыла информация об утилите FxCop, она проверяет .NET assemblies на соответствие гайдлайнам. Насколько я понял, это где-то близко, но не аналог.
S>Поиском по google можно найти с десяток подобных утилит,
То есть уже наработанный опыт не был учтён при написании обсуждаемой утилиты?
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Здравствуйте, softilium, Вы писали:
S>>1. Любая конструктивная критика.
СШ>А какие ещё существуют аналогичные инструменты?
Сходу вспоминается pc-lint (Gimpel) и CodeWizard (Parasoft). Есть еще "C++Test", но это уже более широкого профиля софта (включает в себя тестирование).
Пытался внедрить в проект — особого успеха не имела и пользы имхо не принесла.
С уважением. Алик.
Re[4]: Проверка исходных текстов перед компиляцией
Здравствуйте, Слава Шевцов, Вы писали:
S>>Поиском по google можно найти с десяток подобных утилит,
СШ>То есть уже наработанный опыт не был учтён при написании обсуждаемой утилиты?
Нечего там перенимать, если честно. Интерфейсные решения для подобных утилит должны быть максимально простыми и удобными — это единственный критерий, по-моему. Вот удастся мне упростить интерфейс без ущерба функциональности еще в 2 раза — отлично. Можете меня поправить.
А о перенимании алгоритмов работы, как Вы сами понимаете, не может идти речи, это уже не совсем честно по отношению к авторам.
Re[3]: Проверка исходных текстов перед компиляцией
Здравствуйте, Alik, Вы писали:
A>Сходу вспоминается pc-lint (Gimpel) и CodeWizard (Parasoft). Есть еще "C++Test", но это уже более широкого профиля софта (включает в себя тестирование).
A>Пытался внедрить в проект — особого успеха не имела и пользы имхо не принесла.
Я считаю, что подобные утилиты должны комплектоваться хорошим набором готовых правил для проверки, которые будут демонстрировать их реальную пользу "с ходу". А если человек на такую проверку кода подсядет — он потом и сам сколько угодно критериев для проверки и оценки кода выработает. У меня около 40 активно испольуемых правил в своем проекте, которые, поверьте, сильно облегчают жизнь при коллективной работе.
Вот на собирание коллекции правил (для разных языков) и направлены мои усилия, собственно.
Re[5]: Проверка исходных текстов перед компиляцией
Здравствуйте, softilium, Вы писали:
S>>>Поиском по google можно найти с десяток подобных утилит, СШ>>То есть уже наработанный опыт не был учтён при написании обсуждаемой утилиты? S>Нечего там перенимать, если честно.
Если честно, там должна быть вешь, которая недоступна шароварщику: опыт контроля кода проектов разной степени сложности. Этот опыт копится годами и десятилетиями. И он не может быть преобретён рассуждениями о программе и её пользователях.
S>А о перенимании алгоритмов работы, как Вы сами понимаете, не может идти речи, это уже не совсем честно по отношению к авторам.
Алгоритмы не патентуются. Так что возможность перенятия алгоритмов закреплена в мировом праве на законодательном уровне. Но дело не в алгоритмах, а в том, что работающие на рынке годы и десятилетия имеют некую обратную связь со своими пользователями. Соответственно, софт не вобрал в себя эволюцию ПО данной категории, которая протекала в предыдущих десятилетиях.
Кроме того, поддержка одного из форматов привела бы к тому, что программа обрела некий набор правил форматирования, которые уже давно используются. Например, не нужно было бы каждому разработчику OpenSource с нуля вбивать GNU-стандарт на форматирование кода.
Здравствуйте, Alik, Вы писали:
S>>>1. Любая конструктивная критика. СШ>>А какие ещё существуют аналогичные инструменты? A>Сходу вспоминается pc-lint (Gimpel) и CodeWizard (Parasoft). Есть еще "C++Test", но это уже более широкого профиля софта (включает в себя тестирование).
Спасибо.
A>Пытался внедрить в проект — особого успеха не имела и пользы имхо не принесла.
А в чём причина? Вроде такие утилиты должны приводить к более качественному коду и минимизации опасных участков. Или этого не происходит?
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Если честно, там должна быть вешь, которая недоступна шароварщику: опыт контроля кода проектов разной степени сложности. Этот опыт копится годами и десятилетиями. И он не может быть преобретён рассуждениями о программе и её пользователях.
Для подпадания под такое определение нужно быть pure шароварщиком — никогда не работать в командах разработчиков, никогда не работать с другими, кроме своих собственных, исходников и пр. Я например, подавляющую часть рабочего времени работаю с чужим кодом в течение последних 5-ти лет. Утилитку эту писал изначально только для себя и последние как минимум пол-года ни одна сборка моего проекта без проверки не проходит. Плюс к этому, имею собственный шароварный проект. Ничего, что я не подпадаю под Ваше определение?
СШ>Алгоритмы не патентуются. Так что возможность перенятия алгоритмов закреплена в мировом праве на законодательном уровне. Но дело не в алгоритмах, а в том, что работающие на рынке годы и десятилетия имеют некую обратную связь со своими пользователями. Соответственно, софт не вобрал в себя эволюцию ПО данной категории, которая протекала в предыдущих десятилетиях.
No comments. Не вобрал. Маленькое замечание: даже при том, что алгоримты не патентуются — это все равно некорректно по отношению к их авторам.
СШ>Кроме того, поддержка одного из форматов привела бы к тому, что программа обрела некий набор правил форматирования, которые уже давно используются. Например, не нужно было бы каждому разработчику OpenSource с нуля вбивать GNU-стандарт на форматирование кода.
Полностью с Вами согласен. Не могли бы Вы привести примеры утилит, которые могут служить образцом для подражания? Я буду их изучить и подстроиться под их стиль, если это будет разумно.
Re[4]: Проверка исходных текстов перед компиляцией
Здравствуйте, softilium, Вы писали:
S>Здравствуйте, Alik, Вы писали:
A>>Сходу вспоминается pc-lint (Gimpel) и CodeWizard (Parasoft). Есть еще "C++Test", но это уже более широкого профиля софта (включает в себя тестирование).
A>>Пытался внедрить в проект — особого успеха не имела и пользы имхо не принесла.
S>Я считаю, что подобные утилиты должны комплектоваться хорошим набором готовых правил для проверки, которые будут демонстрировать их реальную пользу "с ходу". А если человек на такую проверку кода подсядет — он потом и сам сколько угодно критериев для проверки и оценки кода выработает. У меня около 40 активно испольуемых правил в своем проекте, которые, поверьте, сильно облегчают жизнь при коллективной работе.
Можно привести пример?
Re[5]: Проверка исходных текстов перед компиляцией
S>>Я считаю, что подобные утилиты должны комплектоваться хорошим набором готовых правил для проверки, которые будут демонстрировать их реальную пользу "с ходу". А если человек на такую проверку кода подсядет — он потом и сам сколько угодно критериев для проверки и оценки кода выработает. У меня около 40 активно испольуемых правил в своем проекте, которые, поверьте, сильно облегчают жизнь при коллективной работе.
B>Можно привести пример?
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Здравствуйте, softilium, Вы писали:
S>>1. Любая конструктивная критика.
СШ>А какие ещё существуют аналогичные инструменты?
Для Java :
в IDEA есть режим Insect Code — около 50+ проверок
(например использование конкретного класса вместо интерфейса)
причем это все интегрированно с редактром,
при вводе такие места показываются как варнинги или ошибки (настраивается)
Кроме того есть инструменты для исправления этих проблем например
можно автоматом заменить все проверки вида
if (!string.equals(""))
на
if (!"".equals(string))
еще в Together'e есть метрики, но я с ними не разбирался...
пример на java:
проверка — checkstyle http://checkstyle.sourceforge.net/
автоматическое форматирование — jalopy http://jalopy.sourceforge.net/
и то и другое встраивается в процедуры автоматического билда (типа maven maven.apache.org) и генерятся отчёты — кто и что и как написал, например
всё это — продукты, которые широко используются в огромной куче проектов. посмотри идеи, заложенные в них
Re[2]: Проверка исходных текстов перед компиляцией
Здравствуйте, mihhon, Вы писали:
M>проверка — checkstyle http://checkstyle.sourceforge.net/ M>автоматическое форматирование — jalopy http://jalopy.sourceforge.net/ M>и то и другое встраивается в процедуры автоматического билда (типа maven maven.apache.org) и генерятся отчёты — кто и что и как написал, например
M>всё это — продукты, которые широко используются в огромной куче проектов. посмотри идеи, заложенные в них
Спасибо, посмотрю. Я сейчас самостоятельно ищу аналоги (хотя вышеуказанные продукты аналогами не являются, они скорее дополняют друг друга при билде), использование таких тулз хорошо бы унифицировать хотя бы внешне.
