Комментарии 10
Как содержимое статьи связано с её названием?
В одну из Ваших оптимизаций вкралась опечатка :)))
contentType = header.substr(strlen(ContentTypeHeader.size()));
strlen там явно лишнее.
Я всё ждал, когда вы доберётесь до проекта! Очень приятная новость для меня. Я contributor, но шарю только за маленький кусочек кодовой базы, связанной с отладкой и исполнением. Ну и упоминание Patapon доставило, т.к. я его реверс-инженерю. В прошлом году я прошерстил кодовую базу с помощью CppCheck и нашёл несколько ошибок:
https://github.com/hrydgard/ppsspp/commit/dae758e5f45ddd576c5e7abef025e54834ab3777
Потом ещё кто-то clang-tidy запускал, тоже собрали кое-какие ошибки... GermanAizek сделал очень много пул реквестов на основании статического анализа, кое-что помёрджили. Не всё. Я согласен с hrydgard-ом, что vec.push_back(TypeName(args)); читабельнее, чем vec.emplace_back(args));, т.к. в случае с эплейсом ещё надо вспомнить, какого типа объекты хранятся в векторе и какая сигнатура у конструктора. Когда пушбэк с явным упоминанием типа, IDE подсказывает нам всё. Ну и CE читабельнее тоже будут, а не "при попытке инстанцировать метод vector<T>::emplace_back от ваших аргументов где-то в глубинах вектора случился статик ассерт" или что-то подобное.
Очень жду продолжения!
По-хорошему анализаторы должны запускаться не эпизодически, а постоянно, на каждый pull request. Анализаторы типа clang-analyzer или clang-tidy нет проблемы запускать на пулл реквестах (даже делающихся из форков), некоторые (типа SonarCloud) на пулл реквестах из форков работать не могут, но их можно запускать на событие влива кода в основную ветку, настроить параметры того, что считается "новым кодом", таким образом проблемы хотя бы постфактум можно будет мониторить и исправлять.
Тут другой вопрос возникает... А что делать с результатами анализа на PR? Блокировать мёрдж, если есть, что сказать анализатору? Да нет... Просто любоваться на 100500 предложений в кодовой базе использовать std::transform от CppCheck? Да тоже нет...
Если что, вариант прям в комментариях рядом с кодом что-то сообщать анализатору (например, глушить диагностики) не предлагать. IMO, это вредит читабельности кода.
Ну cppcheck я не пользовался, но в clang-tidy и в сонаре можно отключать "ненужные" проверки глобально в конфиге или в веб-интерфейсе. Не нужны вам всякие modernize-* рекомендации - чпок и отключили их в файле .clang-tidy в корне проекта. А если уж clang-analyzer что-то нашёл, то над этим лучше всего крепко подумать, ибо процент false positive у него весьма невысок. Ну и вообще, эти сообщения же в первую очередь для самого разработчика, а не просто там для галочки какой-то, чтобы мердж блокировать. Смысл тут в другом - проблемы должны вовремя находиться, по крайней мере в новом коде, а не накапливаться от одного эпизодического прогона анализатора до другого.
Спасибо, рады были стараться!
Как в неё попал флаг true, остаётся загадкой
Судя по всему, автор кода подумал, что параметром должно быть наличие или отсутствие зеркального отражения.
PPSSPP или всё же psp? Смотрим баги в коде из будущего