Вы правы, CppCheck всё нашел. Было уже поздно и я проверял файл, в котором этих ошибок еще не было:( В этом плюс AppChecker'а и PVS-Studio: там что ты компилируешь, то и проверяешь.
Тем не менее, AppChecker ничего подозрительного не нашел в этом коде.
Попробовал и понял, что сравнение в пользу PVS-Studio.
Проверял я на standalone-приложении. Отпишу кратко впечатления от первого запуска. При первом запуске увидел отличную
картинку:
Проверил на двух машинах, проблема воспроизводится. Но на дальнейшую работоспособность никак не влияет, кажется.
Отличие от AppChecker'а — наличие удобного standalone-приложения: тоже приходится запускать мониторинг вызовов компилятора, но делается это из нормального графического интерфейса, а не из консольной утилиты. Результаты работа мониторинга никуда передавать не надо, они сразу отображаются в окне приложения PVS-Studio Standalone.
Проект с Qt и сторонними библиотеками вполне себе проверился. Ничего критичного там, к счастью, не нашлось, но пару членов класса мы инициализировать забываем:(
Древний проект на Си с классами тоже прошел сканирование: 120 ошибок высокой важности, 168 — средней, 870 — низкой. Примеры ошибок:
V570 The 'Parabola' variable is assigned to itself. SomeFileName.cpp 287
Parabola =Parabola ;
V522 Dereferencing of the null pointer 'SetterGetter' might take place. OtherFileName.cpp 305
if ( SetterGetter==0 )
{
SetterGetter->set(false) ;
}
При проверке старых проектов увидел странные дефекты:
V546 Member of a class is initialized by itself: 'd(d)'. qsharedpointer_impl.h 561
V672 There is probably no need in creating the new 'stream' variable here. One of the function's arguments possesses the same name and this argument is a reference. Check lines: 8, 17. entityhelper.cpp 17
Выяснилось, что макрос LOG_ERROR при разворачивании создает переменную с названием 'stream'. Если я правильно помню описание работы PVS-Studio на хабре, то с такими ложными срабатываниями можно бороться. В рамках быстрого ознакомления этого делать не стал, нет необходимости.
У PVS-Studio Standalone в контекстном меню найденных ошибок есть пункт «Add TODO comments for selected messages» — удобная вещь для накопления технического долга:)
Оказалось, что легко и даже приятно исключать директории из сканирования — в частности, ошибки в Qt я предпочел больше не искать.
Ну и на закуску я решил проверить анализаторы на
синтаксическом примере:
bool CheckPointer(int value)
{
int* intPtr(new int(value));
std::cout << std::endl << *intPtr << std::endl;
return true;
}
class A {
int x;
public:
void bar() {
std::cout << x << "Test!\n";
}
};
int main()
{
CheckPointer(5);
A* a;
a->bar();
return 0;
}
PVS-Studio нашла две ошибки:
V773 The function was exited without releasing the 'intPtr' pointer. A memory leak is possible. main.cpp 224
V614 Uninitialized pointer 'a' used. main.cpp 238
AppChecker: В проекте не обнаружены потенциальные уязвимости и дефекты
CppCheck тоже говорит, что ошибок не найдено.
В целом — AppChecker'у есть куда расти как в части удобства, так и в части функциональности анализа. Пока что складывается ощущение, что сделать хотели много (и отчеты, и сравнение результатов сканирования), а получилось — не очень. Но я уверен, что разработчики компании «Эшелон» быстро исправятся и смогут составить достойную конкуренцию на рынке статических анализаторов и в статьях хабра!
И еще пару слов: наша небольшая команда разработчиков использует обязательное ревью всего кода, часть кода покрыта тестами, флаги компилятора включены по максимуму. И это все равно не избавляет нас от ошибок в коде — при запуске я был неприятно удивлен количеством срабатываний анализатора. Я думаю, что и синтаксический анализ не сможет полностью избавить от ошибок, но уменьшить их количество он сможет наверняка. Поэтому — рекомендую.
Спасибо за еще один продукт синтаксического анализа! Я опробовал его, кратко поделюсь впечатлениями.
User Interface: красиво:) Запускаешь серверную часть, идешь в браузер — создаешь проект. И тут — неудобство:
Для С/C++ проектов требуется дополнительная конфигурация.
Я понимаю, почему это сделано, но запускать утилиту, которая мониторит системные вызовы — не всегда удобно.
На большом проекте, использующем Qt и сторонние библиотеки, утилита сдохла. bad_alloc и падение без каких-либо полезных результатов. Уже минус, т.к. проверять планировал именно его.
Открыт древний и большой проект, не использующий ничего и написанный на Си с классами:)
Продукт нашел всего 4 дефекта трех типов, которые, признаюсь, действительно выглядят странно:
При этом параллельно работал CppCheck, который одних только ошибок нашел 37 штук, варнинги и прочие стилистические сообщения я отключил. При этом в коде есть вещи, которые явно указывают на ошибку:
У меня есть подозрение, что AppChecker анализирует не все файлы и файл с проектом сформировался криво, но как это быстро проверить и исправить, я не знаю.
Возможно, я что-то делаю не так, однако для быстрой проверки CppCheck и прочие Clang Static Analyzer'ы лично мне подходят удобнее.
Я допускаю, что ваш продукт можно правильно настроить и он будет работать превосходно, но, например, ручное формирование и загрузка специально сохраненного файла — как-то это долго и лениво.
Сразу вспомнилась целая книга — "Софт — отстой! И что с этим делать?".
И как я в процессе написании рецензии на эту книгу увидел чудное сообщение 7-zipa:
Для начального ознакомления с этими понятиями советую курс на Универсариуме — Основы проектного управления.
Мне он нравится тем, вместе с теорией идет неплохая практика в ProjectLibre: например, разбираются практические задания построения иерархической структуры работ.
И бесполезный риторический вопрос — как правильно: диаграмма Ганта или Гантта? Даже википедия неоднозначна в этом вопросе:)
Спасибо!
С «умным домом» я в чем-то с Вами согласен: для частного пользования это пока что не «средство передвижения», а роскошь. Но, возможно, с развитием IoT появятся и новые ниши для «умных домов». Экономия электроэнергия может быть полезна и нам, тем более экономить же можно не только ее: водопровод, газ и отопление. Контроль протечек с возможностью их устранения перекрыванием вентиля — тоже полезно же?
Продать клиенту умный кондиционер — наверное, сложно, я не продажник. Но и Bentley продать сложно, я думаю — в покупке такого автомобиля тоже больше роскоши и статуса, нежели функциональности, ИМХО
А вот с постскриптумом я не соглашусь: PLM/ERP/MES могут и должны быть тесно связаны с интернетом вещей, т.к. именно там value резко возрастает и экономия видна сразу, и полезность увеличивается.
Да, эмерджентность — это важное свойство сложных систем (а интернет вещей к таковым относится) и если оно будет проявляться (пусть и в других, более простых сценариях), то будет очень-очень хорошо.
Все изложенное в статье — лишь концепции, на тщательную и детальную проработку всего я не покушался.
Но на вопросы попробую ответить — сразу признаюсь, что это исключительно первое видение, которое может быть ошибочным.
Только что появившееся устройство может бродкастом найти интересных ему соседей, или тем же бродкастом определить, где находится некий агент желтых страниц (в мультиагентной платформе Jade для этого есть специальный агент — directory facilitation)
Определив, кто есть в системе и с кем можно общаться для достижения определенных целей (для этого использовав онтологии), устройство начинает общение.
Если у агента кондиционера есть потребность в обслуживании, то он определяет, кто может эту потребность удовлетворить. Если он сам имеет право на выбор фирмы, то примет решение на основании ряда критериев (цена, репутация фирмы, сроки ремонта), если же нет, то отдаст сигнал наверх, пользователю — «нужен ремонт!»
Допустим, изначально термометра не было, появился умный кондиционер. Он будет использовать данные метеослужбы, которые часто отличаются от реальности. Пользователь может захотеть повысить точность определения текущей температуры — и для этого приобретет термометр.
Я не претендую на идеальность модели. Я целиком и полностью за дальнейшие доработки, которые смогут сделать нашу жизнь лучше.
Спасибо!
Проблема в том, что возможности IoT не раскрыты до конца, да и описанное в статье — это по большей части концепции и идеи. Но реализация концепций — это вопрос времени, и чем раньше производители приступят к ней, тем больший профит они получат, как мне кажется.
Кратко изложу свое видение по этим вопросам.
Отказоустойчивость — высокая, т.к. выход одного узла из строя минимально влияет на остальные. Ну потеряют они источники информации — попробуют найти себе другие. Если же других поставщиков данных нет, то интернет вещей не спасет — то же самое и в обычном АСУ-подходе.
Изменение топологии — хочется на лету. Я что-то похожее описал — появляется агент, ищет поставщиков информации. Если эти поставщики вдруг отвалятся, то попробует установить связь с другими.
По поводу других концепций — очень много говорится про машинное обучение. Описанное в статье этому не противоречит, просто в этой теме я не так силен.
По поводу безопасности — мне нравится картинка из "Компьютер пресс":
Посмотреть картинку
Т.е. системы безопасности должны охватывать все — и, возможно, быть такими же участниками сетецентрического интернета вещей.
Значит, я не совсем верно понял комментарий, прошу прощения.
Хотелось бы, чтобы решение противоречий как динамический процесс все же дало в результате некие стандарты и принципы — достигнув тем самым состояние равновесия. И, разумеется, стандарты эти должны быть расширяемыми и адаптируемыми — то есть равновесие будет неустойчивым.
Общества, отрасли и занятия — разве человек ни к чему из перечисленного отношения не имеет?
Война — нет, большинству людей она не нужна. Но можно пытаться снизить человеческие потери на войне, а можно пытаться убеждать всех, что воевать — нехорошо, и одно другому не мешает.
Практически любая технология может быть обращена во вред, если постараться, но вряд ли из-за этого нужно запрещать прогресс.
Если уж вести речь о Jira, то и про Youtrack можно вспомнить — там тоже есть настраиваемый workflow, для гибкой разработки этот продукт подходит вполне.
Там не очень хорошее качество перевода. В комментариях справедливо указали на это, и я спрятал статью в черновики, чтобы отредактировать ее когда-нибудь. Это «когда-нибудь» так и не наступило, к сожалению — так что я вытащил статью из черновика в том же состоянии, как и спрятал ее туда.
Число 400 — это просто усредненная оценка, ведь на практике количество «разумно просматриваемых» строк зависит от состояния просматривающего, от качества кода и решаемых им задач. Можно же на каком-нибудь хаскеле (здесь можно вставить любой другой сложный для восприятия язык) написать несколько строк, но вот понять их будет сложнее.
Суть в том, что качество ревью зависит от объема кода.
Проверка форматирования на стандарт команды может быть и централизованной: например, «плохой» с точки зрения форматирования коммит просто не пройдет в систему управления версиями. Но от странного названия функции это вряд ли спасет.
Ну вот, чеклист уже можно оптимизировать:) Если на проекте используется автоматизированная проверка форматирования, то как минимум проверку скобок и отступов можно убрать. Но если включить в стиль названия переменных и функций, то автоматизировать это вряд ли удастся: вряд ли инструмент сможет распознать непонятное название переменной.
Тем не менее, AppChecker ничего подозрительного не нашел в этом коде.
Проверял я на standalone-приложении. Отпишу кратко впечатления от первого запуска. При первом запуске увидел отличную
Проверил на двух машинах, проблема воспроизводится. Но на дальнейшую работоспособность никак не влияет, кажется.
Отличие от AppChecker'а — наличие удобного standalone-приложения: тоже приходится запускать мониторинг вызовов компилятора, но делается это из нормального графического интерфейса, а не из консольной утилиты. Результаты работа мониторинга никуда передавать не надо, они сразу отображаются в окне приложения PVS-Studio Standalone.
Проект с Qt и сторонними библиотеками вполне себе проверился. Ничего критичного там, к счастью, не нашлось, но пару членов класса мы инициализировать забываем:(
Древний проект на Си с классами тоже прошел сканирование: 120 ошибок высокой важности, 168 — средней, 870 — низкой. Примеры ошибок:
V570 The 'Parabola' variable is assigned to itself. SomeFileName.cpp 287
V522 Dereferencing of the null pointer 'SetterGetter' might take place. OtherFileName.cpp 305
При проверке старых проектов увидел странные дефекты:
V546 Member of a class is initialized by itself: 'd(d)'. qsharedpointer_impl.h 561
V672 There is probably no need in creating the new 'stream' variable here. One of the function's arguments possesses the same name and this argument is a reference. Check lines: 8, 17. entityhelper.cpp 17
Выяснилось, что макрос LOG_ERROR при разворачивании создает переменную с названием 'stream'. Если я правильно помню описание работы PVS-Studio на хабре, то с такими ложными срабатываниями можно бороться. В рамках быстрого ознакомления этого делать не стал, нет необходимости.
У PVS-Studio Standalone в контекстном меню найденных ошибок есть пункт «Add TODO comments for selected messages» — удобная вещь для накопления технического долга:)
Оказалось, что легко и даже приятно исключать директории из сканирования — в частности, ошибки в Qt я предпочел больше не искать.
Ну и на закуску я решил проверить анализаторы на
PVS-Studio нашла две ошибки:
AppChecker: В проекте не обнаружены потенциальные уязвимости и дефекты
CppCheck тоже говорит, что ошибок не найдено.
В целом — AppChecker'у есть куда расти как в части удобства, так и в части функциональности анализа. Пока что складывается ощущение, что сделать хотели много (и отчеты, и сравнение результатов сканирования), а получилось — не очень. Но я уверен, что разработчики компании «Эшелон» быстро исправятся и смогут составить достойную конкуренцию на рынке статических анализаторов и в статьях хабра!
И еще пару слов: наша небольшая команда разработчиков использует обязательное ревью всего кода, часть кода покрыта тестами, флаги компилятора включены по максимуму. И это все равно не избавляет нас от ошибок в коде — при запуске я был неприятно удивлен количеством срабатываний анализатора. Я думаю, что и синтаксический анализ не сможет полностью избавить от ошибок, но уменьшить их количество он сможет наверняка. Поэтому — рекомендую.
User Interface: красиво:) Запускаешь серверную часть, идешь в браузер — создаешь проект. И тут — неудобство: Я понимаю, почему это сделано, но запускать утилиту, которая мониторит системные вызовы — не всегда удобно.
На большом проекте, использующем Qt и сторонние библиотеки, утилита сдохла. bad_alloc и падение без каких-либо полезных результатов. Уже минус, т.к. проверять планировал именно его.
Открыт древний и большой проект, не использующий ничего и написанный на Си с классами:)
Продукт нашел всего 4 дефекта трех типов, которые, признаюсь, действительно выглядят странно:
При этом параллельно работал CppCheck, который одних только ошибок нашел 37 штук, варнинги и прочие стилистические сообщения я отключил. При этом в коде есть вещи, которые явно указывают на ошибку:
У меня есть подозрение, что AppChecker анализирует не все файлы и файл с проектом сформировался криво, но как это быстро проверить и исправить, я не знаю.
Возможно, я что-то делаю не так, однако для быстрой проверки CppCheck и прочие Clang Static Analyzer'ы лично мне подходят удобнее.
Я допускаю, что ваш продукт можно правильно настроить и он будет работать превосходно, но, например, ручное формирование и загрузка специально сохраненного файла — как-то это долго и лениво.
И как я в процессе написании рецензии на эту книгу увидел чудное сообщение 7-zipa:
А хотел всего лишь сохранить настройки.
Мне он нравится тем, вместе с теорией идет неплохая практика в ProjectLibre: например, разбираются практические задания построения иерархической структуры работ.
И бесполезный риторический вопрос — как правильно: диаграмма Ганта или Гантта? Даже википедия неоднозначна в этом вопросе:)
А не могли бы вы поделиться результатами, что получается при отрисовке России, например, в разных вариантах масштаба?
С «умным домом» я в чем-то с Вами согласен: для частного пользования это пока что не «средство передвижения», а роскошь. Но, возможно, с развитием IoT появятся и новые ниши для «умных домов». Экономия электроэнергия может быть полезна и нам, тем более экономить же можно не только ее: водопровод, газ и отопление. Контроль протечек с возможностью их устранения перекрыванием вентиля — тоже полезно же?
Продать клиенту умный кондиционер — наверное, сложно, я не продажник. Но и Bentley продать сложно, я думаю — в покупке такого автомобиля тоже больше роскоши и статуса, нежели функциональности, ИМХО
А вот с постскриптумом я не соглашусь: PLM/ERP/MES могут и должны быть тесно связаны с интернетом вещей, т.к. именно там value резко возрастает и экономия видна сразу, и полезность увеличивается.
Но на вопросы попробую ответить — сразу признаюсь, что это исключительно первое видение, которое может быть ошибочным.
Только что появившееся устройство может бродкастом найти интересных ему соседей, или тем же бродкастом определить, где находится некий агент желтых страниц (в мультиагентной платформе Jade для этого есть специальный агент — directory facilitation)
Определив, кто есть в системе и с кем можно общаться для достижения определенных целей (для этого использовав онтологии), устройство начинает общение.
Если у агента кондиционера есть потребность в обслуживании, то он определяет, кто может эту потребность удовлетворить. Если он сам имеет право на выбор фирмы, то примет решение на основании ряда критериев (цена, репутация фирмы, сроки ремонта), если же нет, то отдаст сигнал наверх, пользователю — «нужен ремонт!»
Допустим, изначально термометра не было, появился умный кондиционер. Он будет использовать данные метеослужбы, которые часто отличаются от реальности. Пользователь может захотеть повысить точность определения текущей температуры — и для этого приобретет термометр.
Я не претендую на идеальность модели. Я целиком и полностью за дальнейшие доработки, которые смогут сделать нашу жизнь лучше.
Проблема в том, что возможности IoT не раскрыты до конца, да и описанное в статье — это по большей части концепции и идеи. Но реализация концепций — это вопрос времени, и чем раньше производители приступят к ней, тем больший профит они получат, как мне кажется.
Отказоустойчивость — высокая, т.к. выход одного узла из строя минимально влияет на остальные. Ну потеряют они источники информации — попробуют найти себе другие. Если же других поставщиков данных нет, то интернет вещей не спасет — то же самое и в обычном АСУ-подходе.
Изменение топологии — хочется на лету. Я что-то похожее описал — появляется агент, ищет поставщиков информации. Если эти поставщики вдруг отвалятся, то попробует установить связь с другими.
По поводу других концепций — очень много говорится про машинное обучение. Описанное в статье этому не противоречит, просто в этой теме я не так силен.
По поводу безопасности — мне нравится картинка из "Компьютер пресс":
Буду рад, если кто-то добавит о концепциях IoT.
Хотелось бы, чтобы решение противоречий как динамический процесс все же дало в результате некие стандарты и принципы — достигнув тем самым состояние равновесия. И, разумеется, стандарты эти должны быть расширяемыми и адаптируемыми — то есть равновесие будет неустойчивым.
Война — нет, большинству людей она не нужна. Но можно пытаться снизить человеческие потери на войне, а можно пытаться убеждать всех, что воевать — нехорошо, и одно другому не мешает.
Практически любая технология может быть обращена во вред, если постараться, но вряд ли из-за этого нужно запрещать прогресс.
Суть в том, что качество ревью зависит от объема кода.