Да, override на этом методе действительно есть, и все другие реализации уже не допускают того же, на что указало срабатывание в статье. Но зачем в исходной реализации параметр перетирается? Выглядит как не самое хорошее решение, потому в статью и попало. Кстати, помимо этого, у данного метода даже есть две реализации, которые похожи как две капли воды :)
В общем, скорее всего нам стоило вынести это срабатывание анализатора в раздел про чистоту кода, поскольку это определённо не прям-таки баг. Но мне кажется, что как указатель на странные решения в ООП дизайне, это срабатывание вполне имеет право на жизнь. Это буквально "Человек, задумайся!" от анализатора.
Точную вероятность сказать не смогу (выше тоже был комментарий с таким запросом :), но мне кажется, что в разбитом на классы switch разработчику проще заметить, если что-то написано не так. Но, опять же, это imho и попытка высчитать общую температуру по палате
В статье по той ссылке действительно был пересказ спора с моими комментариями, но также была и вторая часть с, что называется, размышлениями на тему.
Насчёт "огромности" switch согласен, что с точки зрения code review иерархия классов будет не лучшей альтернативой. Но мне всё же кажется, что в процессе написания кода при правильной декомпозиции можно просто глазами заметить ошибку. Но это, полагаю, imho
Спасибо за комментарий! Про "Программист-прагматик" действительно упустил. Книга давно стоит на полке и ждёт, никак не соберусь с мыслями, чтобы посвятить ей достаточно времени)
Насчёт подхода к статическому анализу дополню, что не стоит отключать диагностики просто для того, чтобы спрятать то, что он находит. Если вы хотите выключить диагностику на этапе внедрения, это вполне может быть оправдано. Например, нет смысла включать диагностические правила стандартов MISRA, если вы не разрабатываете ПО в соответствии с этими стандартами :)
Спасибо за ваше мнение! Должен отметить, что в данной статье приведена несколько субъективная подборка событий, происходивших в языке (авторы такие авторы...). Моё внимание было направлено на приведённый в статье список изменений по той же причине, по которой для Вас важна унификация представления отрицательных целых - у каждого разработчика свои потребности :) Да и для упоминания всех изменений всех стандартов правильнее было бы писать статью про каждый из них, чем проводить общую экскурсию по истории языков.
Нет, предыдущие срабатывания не останутся, поскольку анализатор будет проводить анализ только для изменённых файлов. Но перед запуском анализа плагин предложит сохранить отчёт. Однако, в будущем релизе PVS-Studio 7.35 в Visual Studio будет добавлен режим анализа модифицированных файлов (в данном тексте описан для PVS-Studio_Cmd.exe), который будет также проверять, не исправлены ли выданные ранее предупреждения.
MSBuild сохраняет информацию о том, какие файлы обновлялись в .tlog файлы и на основе этих файлов умеет пересобирать только то, что имеет более новую временную метку. На основе этого же механизма анализатор понимает, какие файлы были изменены, а какие нет. Поэтому нет, после повторной сборки без изменений файлы не будут modified.
Да,
overrideна этом методе действительно есть, и все другие реализации уже не допускают того же, на что указало срабатывание в статье. Но зачем в исходной реализации параметр перетирается? Выглядит как не самое хорошее решение, потому в статью и попало. Кстати, помимо этого, у данного метода даже есть две реализации, которые похожи как две капли воды :)В общем, скорее всего нам стоило вынести это срабатывание анализатора в раздел про чистоту кода, поскольку это определённо не прям-таки баг. Но мне кажется, что как указатель на странные решения в ООП дизайне, это срабатывание вполне имеет право на жизнь. Это буквально "Человек, задумайся!" от анализатора.
Точную вероятность сказать не смогу (выше тоже был комментарий с таким запросом :), но мне кажется, что в разбитом на классы
switchразработчику проще заметить, если что-то написано не так. Но, опять же, это imho и попытка высчитать общую температуру по палатеСпасибо за комментарий!
В статье по той ссылке действительно был пересказ спора с моими комментариями, но также была и вторая часть с, что называется, размышлениями на тему.
Насчёт "огромности"
switchсогласен, что с точки зрения code review иерархия классов будет не лучшей альтернативой. Но мне всё же кажется, что в процессе написания кода при правильной декомпозиции можно просто глазами заметить ошибку. Но это, полагаю, imhoСпасибо за комментарий! Про "Программист-прагматик" действительно упустил. Книга давно стоит на полке и ждёт, никак не соберусь с мыслями, чтобы посвятить ей достаточно времени)
Насчёт подхода к статическому анализу дополню, что не стоит отключать диагностики просто для того, чтобы спрятать то, что он находит. Если вы хотите выключить диагностику на этапе внедрения, это вполне может быть оправдано. Например, нет смысла включать диагностические правила стандартов MISRA, если вы не разрабатываете ПО в соответствии с этими стандартами :)
Спасибо за комментарий!
Спасибо!
Спасибо!
Спасибо за ваше мнение!
Должен отметить, что в данной статье приведена несколько субъективная подборка событий, происходивших в языке (авторы такие авторы...). Моё внимание было направлено на приведённый в статье список изменений по той же причине, по которой для Вас важна унификация представления отрицательных целых - у каждого разработчика свои потребности :)
Да и для упоминания всех изменений всех стандартов правильнее было бы писать статью про каждый из них, чем проводить общую экскурсию по истории языков.
Нет, предыдущие срабатывания не останутся, поскольку анализатор будет проводить анализ только для изменённых файлов. Но перед запуском анализа плагин предложит сохранить отчёт.
Однако, в будущем релизе PVS-Studio 7.35 в Visual Studio будет добавлен режим анализа модифицированных файлов (в данном тексте описан для
PVS-Studio_Cmd.exe), который будет также проверять, не исправлены ли выданные ранее предупреждения.MSBuild сохраняет информацию о том, какие файлы обновлялись в
.tlogфайлы и на основе этих файлов умеет пересобирать только то, что имеет более новую временную метку. На основе этого же механизма анализатор понимает, какие файлы были изменены, а какие нет.Поэтому нет, после повторной сборки без изменений файлы не будут modified.
Спасибо за комментарий! В том числе для этого текста некоторые детали были подчёркнуты из этой книги, а во второй части будет целый пункт про неё :)
Вторая часть статьи уже вышла! Приятного чтения!
Да, в репозитории проекта открыл Issue, в котором написал о найденных ошибках