Комментарии 14
Забываение throw, похоже, универсальная проблема.
Недавно наковырял пучок такой радости в питоне.
Многодумаю, почему эти варнинги не в компиляторах.
Недавно наковырял пучок такой радости в питоне.
Многодумаю, почему эти варнинги не в компиляторах.
Уважаемые ИТ-специалисты из PVS-Studio!
Ограничьте, пожалуйста, Вашу энергию: хронография публикаций за последние две недели — 22 января, 27 января, 02 февраля, 03 февраля, 05 февраля, 07 февраля.
Да, у Вас есть интересный материал, не буду спорить, но давайте придерживаться каких-то средних цифр других корпоративных блогов на Хабре.
Вы же сами первыми будете в выигрыше — обычно от «самофильтрации» качество публикаций только возрастает.
Ограничьте, пожалуйста, Вашу энергию: хронография публикаций за последние две недели — 22 января, 27 января, 02 февраля, 03 февраля, 05 февраля, 07 февраля.
Да, у Вас есть интересный материал, не буду спорить, но давайте придерживаться каких-то средних цифр других корпоративных блогов на Хабре.
Вы же сами первыми будете в выигрыше — обычно от «самофильтрации» качество публикаций только возрастает.
Так это, автор же явно указывает, что
Вначале маленький Disclaimer для сомневающихся: да, за этот пост я, возможно, получу лицензию на PVS-Studio для проверки открытого проекта Microsoft Orleans. А может и не получу, как фишка ляжет-с. Нет, с компанией «СиПроВер» я напрямую никак не связан и написал этот пост по своей инициативе.
А что не так с качеством? Или это tall-poppy syndrome на хабре? И еще, я, например, могу понять причины возникновения такого количества статей — наконец-то вышел анализатор для C# кода и все кто его ждал — бросились проверять проекты и продукты. Что плохого в том, что качество опен-сорс проектов улучшилось?
А то всё ложат и ложат!
Я просто оставлю эти ссылочки здесь.
FxCop
StyleCop
ReSharper Command Line Tools
и вишенкой опенсурс, мультиязычный, кроссплатформенный, гибко настраиваемый и на порядок более функциональный/наглядный/полезный: SonarQube
В последнее время уж очень стала напрягать активность пиарастов от этой софтины.
FxCop
StyleCop
ReSharper Command Line Tools
и вишенкой опенсурс, мультиязычный, кроссплатформенный, гибко настраиваемый и на порядок более функциональный/наглядный/полезный: SonarQube
В последнее время уж очень стала напрягать активность пиарастов от этой софтины.
А вы сравните качество проверки этими утилитами и PVS-Studio. И тогда станет понятно, нужно ли ссылочки оставлять или нет :)
Кстати, интересная статья могла бы получиться.
Кстати, интересная статья могла бы получиться.
В том-то и дело, что я сравнил :) Если б не сравнивал — не оставлял бы этот комментарий.
И не на мелком проектике, а на чудовище в 170k+ строк кода возрастом ~10 лет и ещё парочке проектов посвежее.
PVS выдал не больше, настраивается на порядок хуже, способов вывода результатов ещё меньше, а про отображение можно даже не заикаться.
Для себя (50+ проектов в компании. свои + аутсорсеры. зоопарк из c#/js/sql/java/scala/python) выбрал прогон SonarQube по шедулеру на git-репозитории, в которых были изменения с последнего прогона (из TeamCity/TFS), в некоторых случаях триггерится на коммиты.
В сонаре гибко настраивается список правил, для каждого выставляется уровень критичности и результаты просеиваются через Quality Gate. Т.е. это не тупое "У ВАС ТУТ В КОДЕ ОПЕЧАТКА!", а прям-таки нормальный отчёт — сколько, чего, какого плана, насколько критично, в каких компонентах, какая динамика (сколько где и чего добавилось с последнего прогона / с предыдущей версии).
Я не пытаюсь противопоставить pvs сонару. Нет, это совершенно разного уровня продукты.
Я лишь утверждаю, что имея опыт организации проверок и их интеграции в процесс на основе всех этих stylecop/fxcop/resharper для c# и скачав PVS для сравнения — я смеялся и плакал.
И не на мелком проектике, а на чудовище в 170k+ строк кода возрастом ~10 лет и ещё парочке проектов посвежее.
PVS выдал не больше, настраивается на порядок хуже, способов вывода результатов ещё меньше, а про отображение можно даже не заикаться.
Для себя (50+ проектов в компании. свои + аутсорсеры. зоопарк из c#/js/sql/java/scala/python) выбрал прогон SonarQube по шедулеру на git-репозитории, в которых были изменения с последнего прогона (из TeamCity/TFS), в некоторых случаях триггерится на коммиты.
В сонаре гибко настраивается список правил, для каждого выставляется уровень критичности и результаты просеиваются через Quality Gate. Т.е. это не тупое "У ВАС ТУТ В КОДЕ ОПЕЧАТКА!", а прям-таки нормальный отчёт — сколько, чего, какого плана, насколько критично, в каких компонентах, какая динамика (сколько где и чего добавилось с последнего прогона / с предыдущей версии).
Я не пытаюсь противопоставить pvs сонару. Нет, это совершенно разного уровня продукты.
Я лишь утверждаю, что имея опыт организации проверок и их интеграции в процесс на основе всех этих stylecop/fxcop/resharper для c# и скачав PVS для сравнения — я смеялся и плакал.
Отлично, а есть где-либо статьи где можно про все это прочитать и как сонар настроить без излишних приседаний, а то там installation manual такой, что отпадает все желание его попробовать?
Ну так вы опубликовали бы результаты сравнения. Дайте возможность команде PVS-Studio ответить на ваш смех и плач над их продуктом.
Кстати, речь не совсем про Sonar шла. Напомню, что сначала вы выложили ссылки на
Кстати, речь не совсем про Sonar шла. Напомню, что сначала вы выложили ссылки на
- FxCop
- StyleCop
- ReSharper Command Line Tools
Почитав что нужно чтобы запустить анализ солюшена при помощи SonarQube, я готов отказаться от заявления, что современные анализаторы использовать легко. Не все. Там один процесс инсталляции и требований к машине — на пару дней работы… А сравнение результатов с PVS будет действительно интересно почитать.
И еще на всякий случай повторюсь — я написал статью со стороны проекта Orleans, а не со стороны команды PVS студии, но вы скорей всего не читали даже первого абзаца, а просто зашли покидаться «ссылочками».
И еще на всякий случай повторюсь — я написал статью со стороны проекта Orleans, а не со стороны команды PVS студии, но вы скорей всего не читали даже первого абзаца, а просто зашли покидаться «ссылочками».
Да всем плевать на Orleans, потому что писали вы про PVS на самом деле.
А покидался ссылочками я исключительно для того, чтоб чуть расширить кругозор тех, кто зайдёт в "очередную рекламную брошюрку PVS". Я ничего не имею против них самих — пиарятся как могут. И фиг с ними.
Фокус в том, что практически все эти статейки от/про PVS — они про то, что static code analysis должен быть. Не о том, что они находят лучше/больше других — нет, от такой постановки вопроса они сами шарахаются, как от огня.
А о том, что это НАДО делать. И что это ПОЛЕЗНО делать РЕГУЛЯРНО.
Дальше, по логике, должны быть ссылочки на приятную, внятную, наглядную документацию, где показано, как удобно, просто и беспроблемно интегрировать это конкретное средство в системы CI… Но вот нет. С документацией печально. С интеграцией печально.
Именно поэтому я и дал ссылочки на отдельные средства, которые можно настраивать под свои нужды.
И для хорошего такого комбайна, который делает на два порядка больше работы и находится вообще в другой вселенной. Просто связан с этой темой.
А покидался ссылочками я исключительно для того, чтоб чуть расширить кругозор тех, кто зайдёт в "очередную рекламную брошюрку PVS". Я ничего не имею против них самих — пиарятся как могут. И фиг с ними.
Фокус в том, что практически все эти статейки от/про PVS — они про то, что static code analysis должен быть. Не о том, что они находят лучше/больше других — нет, от такой постановки вопроса они сами шарахаются, как от огня.
А о том, что это НАДО делать. И что это ПОЛЕЗНО делать РЕГУЛЯРНО.
Дальше, по логике, должны быть ссылочки на приятную, внятную, наглядную документацию, где показано, как удобно, просто и беспроблемно интегрировать это конкретное средство в системы CI… Но вот нет. С документацией печально. С интеграцией печально.
Именно поэтому я и дал ссылочки на отдельные средства, которые можно настраивать под свои нужды.
И для хорошего такого комбайна, который делает на два порядка больше работы и находится вообще в другой вселенной. Просто связан с этой темой.
Я бы столько всего в CI настроил, будь у меня бесконечное количество времени, благо умею. А по факту — если хочется что-то сделать за разумное время\усилия — не всегда стоит выбирать супер-мега-комбайны. Из личного опыта — банальный Парето тут работает — если простыми решениями за 20% времени можно решить 80% проблем — это надо сделать. оставшиеся 20% отнимут 80% времени и могут вообще никогда за время жизни проекта не всплыть.
Первые три ссылки я знаю:
FxCop используется в Orleans (через www.nuget.org/packages/Microsoft.CodeAnalysis.FxCopAnalyzers), эпичный баг он не поймал. Или не-донастроен как надо или к его предупреждениям не прислушались.
Еще есть www.nuget.org/packages/Microsoft.CodeAnalysis
StyleCop умер, хватит пинать дохлую лошадь. В репо есть какая-то странная активность, но из всего — просто перевыложен релиз 2013 года. Посмотрите хистори и увидите. Если хотите стиля — запиливайте CodeFormatter, хватит травить джуниоров в профессии.
Решарпер — я знаю что у кого-то из команды он есть. Опять же или не поймал или не прислушались.
И да, я сделал статью в том же стиле что и другие обзоры, потому что это наиболее удобный формат для описания результатов проверки. Возможно, не очень удачно выбрал время публикации, т.к. статей с проверками за последнюю пару недель действительно оказалось много.
С интеграцией сложно, но исходно так было у всех — и решарпер не сразу сделал тулзы для консоли. Посмотрим на темпы развития.
А вот про качество — я, лично, никогда раньше не видел чтобы статический анализатор умел отлавливать не просто синтаксис, а именно паттерны, конкретно у нас — double-locking pattern. И не просто обнаруживать, но и рассказывать, что там может быть не правильно (хотя если я правильно понял других гуру — volatile там не нужен (валидно для .NET) и это скорей всего FP у PVS-Studio)
Если вы покажете что решарпер или СонарКуб такое умеют и из коробки — следующую проверку и статью я, честно, напишу про них.
PS: И мне не плевать, но вы же меня лучше знаете…
Первые три ссылки я знаю:
FxCop используется в Orleans (через www.nuget.org/packages/Microsoft.CodeAnalysis.FxCopAnalyzers), эпичный баг он не поймал. Или не-донастроен как надо или к его предупреждениям не прислушались.
Еще есть www.nuget.org/packages/Microsoft.CodeAnalysis
StyleCop умер, хватит пинать дохлую лошадь. В репо есть какая-то странная активность, но из всего — просто перевыложен релиз 2013 года. Посмотрите хистори и увидите. Если хотите стиля — запиливайте CodeFormatter, хватит травить джуниоров в профессии.
Решарпер — я знаю что у кого-то из команды он есть. Опять же или не поймал или не прислушались.
И да, я сделал статью в том же стиле что и другие обзоры, потому что это наиболее удобный формат для описания результатов проверки. Возможно, не очень удачно выбрал время публикации, т.к. статей с проверками за последнюю пару недель действительно оказалось много.
С интеграцией сложно, но исходно так было у всех — и решарпер не сразу сделал тулзы для консоли. Посмотрим на темпы развития.
А вот про качество — я, лично, никогда раньше не видел чтобы статический анализатор умел отлавливать не просто синтаксис, а именно паттерны, конкретно у нас — double-locking pattern. И не просто обнаруживать, но и рассказывать, что там может быть не правильно (хотя если я правильно понял других гуру — volatile там не нужен (валидно для .NET) и это скорей всего FP у PVS-Studio)
Если вы покажете что решарпер или СонарКуб такое умеют и из коробки — следующую проверку и статью я, честно, напишу про них.
PS: И мне не плевать, но вы же меня лучше знаете…
«Эпичный баг» — это правило CA1806: Do not ignore method results. Существует со времён VisualStudio 2010. У нас его точно также поймал сонар при прогоне FxCop.
Ругается на него обычно в двух случаях: 1) вот такое кривое использование string.Replace(); 2) ..TryParse()-методы.
И если первый надо исправлять, то во втором зачастую можно просто закрыть как false-positive.
StyleCop устарел? Он работает? А что нового-то появилось? Разве что он некорректно ругается на новые C# 6 конструкции вида obj.?Property, но это настолько несущественно…
CodeFormatter это вообще совершенно другой функционал. Это принудительное форматирование кода в соответствии с правилами принятыми за внутренний стандарт оформления кода в конкретной компании, жёстко зашитыми авторами тулзы. С помощью этого инструмента нельзя получить форматирование, настраиваемое под нужды компании/команды/продукта в конце-концов.
Что снова возвращает нас к тому, о чём я говорю — суть не в инструментах, а в процессе, который их задействует. Если цепочке dev->qa->prod не задействован code analysis в виде чётких критериев, то можно считать, что его просто нет. Причём жить он должен именно на стадии dev, потому как это прямая зона ответственности и заинтересованности разработчика.
Эмм, ну чтож — поздравляю, новые знания это всегда хорошо.
Я не сказал «вам». Я сказал «всем».
Попробуйте чуть-чуть абстрагироваться и посмотреть на это так: "очередная статья про то, как в каком-то там проекте искали баги с PVS". Потому как сам по себе проект Orleans здесь удостоен, конечно, пяти абзацев вначале, вот только дальше эта информация совершенно не используется в статье, потому как речь идёт про анализ кода от PVS. Поэтому людям, которые что-то знают/хотят узнать про Orleans статья бесполезна, а всем остальным — назойлива. Такая формулировка вам больше нравится?
Ругается на него обычно в двух случаях: 1) вот такое кривое использование string.Replace(); 2) ..TryParse()-методы.
И если первый надо исправлять, то во втором зачастую можно просто закрыть как false-positive.
StyleCop устарел? Он работает? А что нового-то появилось? Разве что он некорректно ругается на новые C# 6 конструкции вида obj.?Property, но это настолько несущественно…
CodeFormatter это вообще совершенно другой функционал. Это принудительное форматирование кода в соответствии с правилами принятыми за внутренний стандарт оформления кода в конкретной компании, жёстко зашитыми авторами тулзы. С помощью этого инструмента нельзя получить форматирование, настраиваемое под нужды компании/команды/продукта в конце-концов.
Решарпер — я знаю что у кого-то из команды он есть. Опять же или не поймал или не прислушались.
Что снова возвращает нас к тому, о чём я говорю — суть не в инструментах, а в процессе, который их задействует. Если цепочке dev->qa->prod не задействован code analysis в виде чётких критериев, то можно считать, что его просто нет. Причём жить он должен именно на стадии dev, потому как это прямая зона ответственности и заинтересованности разработчика.
я, лично, никогда раньше не видел чтобы статический анализатор умел отлавливать не просто синтаксис, а именно паттерны
Эмм, ну чтож — поздравляю, новые знания это всегда хорошо.
PS: И мне не плевать, но вы же меня лучше знаете…
Я не сказал «вам». Я сказал «всем».
Попробуйте чуть-чуть абстрагироваться и посмотреть на это так: "очередная статья про то, как в каком-то там проекте искали баги с PVS". Потому как сам по себе проект Orleans здесь удостоен, конечно, пяти абзацев вначале, вот только дальше эта информация совершенно не используется в статье, потому как речь идёт про анализ кода от PVS. Поэтому людям, которые что-то знают/хотят узнать про Orleans статья бесполезна, а всем остальным — назойлива. Такая формулировка вам больше нравится?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Проверка проекта Microsoft Orleans с помощью PVS-Studio