Comments 7
Что-то внезапно стало интересно, а как вы ставите внутренние цели для команды качества правил? :) По количеству, или это исключительно на человеческой оценке изменений?
И вот тут уже начинаем задумываться, что это мы такое увидели. Программист не отследил инвариант и поставил ненужную проверку. Почему не уследил? Тут надо было думать, прикладывать усилия. А если сразу написать осторожно, то время и усилия экономятся на другие задачи. Опять же, с точки зрения читающего инвариант тоже не впрыгивает в глаза очевидностью. Ненужную проверку читающий воспримет нормально, её отсутствие насторожит. Чтобы обнаружить, что всё в порядке, тут снова надо прикладывать те же думательные усилия.
Что же делать программисту в таких ситуациях? Может, где-то для надёжности и читаемости оставить как было, засоряя код фактически ненужным мусором и надеясь на всесильную оптимизацию. Может быть, оставить комментарий о ненужности проверки (который может внезапно оказаться неверным при следующем изменении, и для проверки снова нужны думательные усилия). Наш внутренний перфекционист, конечно, настоятельно требует реорганизации кода таким образом, чтобы эдакой переплетённости не возникало, хотя однозначных рекомендаций я вот так с места, спроси меня кто-нибудь, не предложил бы. Ну может маленькие функции присоветовал, только это всё равно не панацея.
Кстати, о всесилии оптимизации. Любопытно, может ли статический анализ вообще и описанный в статье аспект в частности предоставить для оптимизирующего компилятора какие-то ценные сведения, которые он не смог бы добыть сам?
Действительно, иногда лучше просто поставить лишнюю проверку, чтобы не тратить много времени на понимание кода. Но это может и стрельнуть, т.к. ненужная проверка может оказаться неверной из-за изменений переплетённого кода (как вы и написали).
Касаемо оптимизаций. Думаю, что статический анализ, несомненно, может предоставить ценные сведения для компилятора. Компилятор и сейчас использует статический анализ во время компиляции исходного кода. Вот только компилятор ограничен в своих возможностях статического анализа, так как его основной задачей является именно компиляция кода. Отдельные же утилиты не скованны так сильно во времени. Кстати, есть мысль, что некоторые диагностики из тех, что не дают ложных срабатываний, иногда и оказываются в компиляторе.
Анализ потока данных PVS-Studio распутывает всё больше связанных переменных