Ja kak-to skachal testversiju "CodeWizard" firmy parasoft.
Polnoe der'mo!
0)Programma snachala ne poshla, t.k. predpologalas' fajlovaja struktura opredelennogo distributiva Linuxa. Vidno firma parasoft ne znala chto Linux eto ne vsegda "RH 7.1"
1)Programma napisana srazu na 4-h jasykah: bash, python, c++, Java
2)Pri proverke 30.000 Strochnoj programmy sozhrala 2GByta ram, i komputer zavis.
3)Vydala trivial'nye ochibli, ne vyhodjaschie za kontext odnoj stroki.
4)Priznala Kod Qt-Biblioteki absoljutno negodnym!
Punkt Nr.3 — Slabost' bolschinstva podobnyh programm. Nelzja po odnoj strochke vyjavit' oshibku.
Napr.(c++) Soderzhit klass chleny ukazateli, bud' dobr opredeli operator= i copy-konstructor,
esli chlenov ukazatelei net, mozhno obojtis' standartnymi operatorami.
Esli porazbrosit' mozgami, kak rabotajut podobnye programmy?
Ischut regexp, vydajut soobschenie i sovet.
Vsja cennost' programmy zakljuchaetsja v nbore "regexpov" i sootvetstvujuschih
pojasnenii s sovetami.
Samu programmu mozhno realizovat' v vide 10 strochnogo skripta s pomoschju prikaza "grep".
Paradox firmy parasoft zakluchalsja v tom, chto svoju nikchemnuju programmu oni zaschishajut
vsjakimi kljuchami, a baza dannyj ochibok i sovetov lezhiz otkrytaja v text-failah
Soznanije uchastnikov kollektiva, i kollektivnye pravila napisanija koda + predpisanie
pereodicheskogo codereview pomoemu namnogo poleznei chem podobnye tooly.
A esli prosmotr koda bjet po samoljubiju programistov, ili nachalniku "v lom" kod pochitat',
to takoj komande ne pomoch'.
s uvazheniem,
Valentin
Здравствуйте, softilium, Вы писали:
S>Здравствуйте, Слава Шевцов, Вы писали:
СШ>>А какие ещё существуют аналогичные инструменты?
S>При обсуждении темы в SWRUS-PROGRAMMING всплыла информация об утилите FxCop, она проверяет .NET assemblies на соответствие гайдлайнам. Насколько я понял, это где-то близко, но не аналог.
S>Поиском по google можно найти с десяток подобных утилит, но они как правило достаточно дороги и занимаются именно синтаксическим анализом, с помощью которого находятся потенциальные дыры. Здесь совсем другой принцип, все гораздо проще.
Re[2]: Проверка исходных текстов перед компиляцией
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Здравствуйте, softilium, Вы писали:
S>>1. Любая конструктивная критика.
СШ>А какие ещё существуют аналогичные инструменты?
Сходу вспоминается pc-lint (Gimpel) и CodeWizard (Parasoft). Есть еще "C++Test", но это уже более широкого профиля софта (включает в себя тестирование).
Пытался внедрить в проект — особого успеха не имела и пользы имхо не принесла.
С уважением. Алик.
Re[5]: Проверка исходных текстов перед компиляцией
S>>Я считаю, что подобные утилиты должны комплектоваться хорошим набором готовых правил для проверки, которые будут демонстрировать их реальную пользу "с ходу". А если человек на такую проверку кода подсядет — он потом и сам сколько угодно критериев для проверки и оценки кода выработает. У меня около 40 активно испольуемых правил в своем проекте, которые, поверьте, сильно облегчают жизнь при коллективной работе.
B>Можно привести пример?
кстати, checkstyle поддерживает достаточно хитрые проверки, он расширяем, но твои правила реализованы на regexp, а в checkstyle на java (можно вызвать regexp из java ). у тебя проще добавить настройки, но на ява можно написать более сложные правила. вот примеры правил:
Detects inline conditionals. Rationale: Some developers find inline conditionals hard to read, so their company's coding standards forbids them.
The "double-checked locking" idiom (DCL) tries to avoid the runtime cost of synchronization. The problem with the DCL idiom in Java is that it just does not work correctly. Using it introduces bugs that are extremely hard to track down and reproduce.
Checks that classes that override equals() also override hashCode().
Checks that a local variable or a parameter does not shadow a field that is defined in the same class.
Checks for illegal instantiations where a factory method is preferred. Rationale: Depending on the project, for some classes it might be preferable to create instances through factory methods rather than calling the constructor. A simple example is the java.lang.Boolean class. In order to save memory and CPU cycles, it is preferable to use the predefined constants TRUE and FALSE. Constructor invocations should be replaced by calls to Boolean.valueOf(). Some extremely performance sensitive projects may require the use of factory methods for other classes as well, to enforce the usage of number caches or object pools.
Checks for assignments in subexpressions, such as in "String s = Integer.toString(i = 2);". Rationale: With the exception of for iterators, all assignments should occur in their own toplevel statement to increase readability. With inner assignments like the above it is difficult to see all places where a variable is set.
Checks that there are no "magic numbers", where a magic number is a numeric literal that is not defined as a constant.
Checks that switch statement has "default" clause. Rationale: It's usually a good idea to introduce a default case in every switch statement. Even if the developer is sure that all currently possible cases are covered, this should be expressed in the default branch, e.g. by using an assertion. This way the code is protected aginst later changes, e.g. introduction of new types in an enumeration type.
Checks for redundant exceptions declared in throws clause such as duplicates, unchecked exceptions or subclasses of another declared exception.
Checks for overly complicated boolean expressions. Currently finds code like if (b == true), b || true, !false, etc.
Checks for overly complicated boolean return statements.
При коллективной работе над проектами, особенно большими, часто стоит задача проверки и просмотра кода разработчиков перед сборкой. Обычно этим занимается менеджер проекта, часто он же и производит билды для тестирования и для заказчика.
Находясь в подобной роли, я для себя написал тул, проверяющий код на соответствие неким формальным правилам. Правила определены в виде регулярных выражений. Сделал, использую — нравится. Выпустил это в виде 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 можно найти с десяток подобных утилит,
То есть уже наработанный опыт не был учтён при написании обсуждаемой утилиты?
Здравствуйте, Слава Шевцов, Вы писали:
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[2]: Проверка исходных текстов перед компиляцией
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Здравствуйте, 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>всё это — продукты, которые широко используются в огромной куче проектов. посмотри идеи, заложенные в них
Спасибо, посмотрю. Я сейчас самостоятельно ищу аналоги (хотя вышеуказанные продукты аналогами не являются, они скорее дополняют друг друга при билде), использование таких тулз хорошо бы унифицировать хотя бы внешне.
Re[3]: Проверка исходных текстов перед компиляцией
M>>всё это — продукты, которые широко используются в огромной куче проектов. посмотри идеи, заложенные в них
S>Спасибо, посмотрю. Я сейчас самостоятельно ищу аналоги (хотя вышеуказанные продукты аналогами не являются, они скорее дополняют друг друга при билде), использование таких тулз хорошо бы унифицировать хотя бы внешне.
почему не аналоги? checkstyle и jalopy встраиваются в среды разработки и подсвечивают, например, ляпы или вызываются из среды для форматирования текстов, пример — Eclipse plugins (я синеньким закрасил кое-что, это несущественно):
Re[4]: Проверка исходных текстов перед компиляцией
Здравствуйте, mihhon, Вы писали:
M>почему не аналоги? checkstyle и jalopy встраиваются в среды разработки и подсвечивают, например, ляпы или вызываются из среды для форматирования текстов, пример — Eclipse plugins (я синеньким закрасил кое-что, это несущественно):
В смысле встраиваемости в среды разработки да, аналоги, нужно поддерживать это. В остальном — утилиты совершенно разные.
Re[5]: Проверка исходных текстов перед компиляцией
Здравствуйте, mihhon, Вы писали:
M>посмотри вот это http://www.castsoftware.com/Products/platform/AMS/Enforce/Features.html , продукт для параноиков, анализатор кода, генератор отчётов, поддерживает в дом числе и Дельфи
M>на реальном проекте был плохо настроен, поэтому особой пользы от него не было. а так мощная штука, если хорошо настроить
Да, это возможно самый близкий аналог, но такого уровня накрученности мне не достичь, по крайней мере сразу. Да и незачем, кому нужен второй такой же CAST?
Re[7]: Проверка исходных текстов перед компиляцией
S>Да, это возможно самый близкий аналог, но такого уровня накрученности мне не достичь, по крайней мере сразу. Да и незачем, кому нужен второй такой же CAST?
ценовая категория. CAST стоит десятки тысяч долларов, как договоришься
Re[8]: Проверка исходных текстов перед компиляцией
Здравствуйте, mihhon, Вы писали:
S>>Да, это возможно самый близкий аналог, но такого уровня накрученности мне не достичь, по крайней мере сразу. Да и незачем, кому нужен второй такой же CAST?
M>ценовая категория. CAST стоит десятки тысяч долларов, как договоришься
Да, цена там действительно только для ОЧЕНЬ крупных команд. Ниша есть и для меня, выходит. Уже копаю...
Re[6]: Проверка исходных текстов перед компиляцией
Здравствуйте, mihhon, Вы писали:
M>кстати, checkstyle поддерживает достаточно хитрые проверки, он расширяем, но твои правила реализованы на regexp, а в checkstyle на java (можно вызвать regexp из java ). у тебя проще добавить настройки, но на ява можно написать более сложные правила. вот примеры правил:
......
Да, понятно. Осталось только найти красивый способ скармливания фрагментов по необходимости некому парсеру в моей программе. Стоит подумать.
Re[4]: Проверка исходных текстов перед компиляцией
