Pull to refresh

Comments 15

Я заметил, что ошибки, связанные с именами вида 'var1', 'var2', встречаются практически в каждом проверенном проекте. Создается впечатление: «Назвал переменные очень похоже — жди беды». Неужели ошибки такого рода превратились в пандемию? Самое обидное, что их и правда бывает сложно обнаружить с помощью Code Review. Конечно, их можно избежать, просто давая сущностям более различимые имена, но соблазн бывает велик)
Да, таких ошибок очень много. И сейчас я сделаю анонс новой статьи, написанием которой я планирую заняться в ближайшее время. Рабочее название «0, 1, 2». Должно получиться интересно и поучительно. В духе "Зло живёт в функциях сравнения" и "Эффект последней строки".
В чистой математике «более различимые имена» как правило не бывают — контекста нет. Однобуквенные либо индексированные, зачастую так и переезжают в код (разве что греческие
вроде lambda могут расписать), читать алгоритмы в таком коде одно мучение.

Не соглашусь. Когда под рукой пейпер, по которому реализован алгоритм, читать в таком виде, напротив, удобнее.

Верно, но тогда бумажная версия играет роль комментариев. А ее под рукой нет?
Тогда ее надо найти, скачать и по желанию распечатать. Или можно попытаться восстановить по алгоритму.

Вот серьезно. Если в математике не хватает контекста чтобы дать переменным более осмысленные имена — то откуда контекст возьмется в программе?
Так и я про то же. Это автор ветки пишет «Неужели ошибки такого рода превратились в пандемию?»
Предупреждение PVS-Studio: V3083 Unsafe invocation of event 'Started', NullReferenceException is possible. Consider assigning event to a local variable before invoking it. Evaluator RecommenderRun.cs 115

Здесь вообще много чего может произойти и не помогут ни local variable ни elvis оператор. Например можно задиспозить один из подписчиков во время вызова других.
Кстати, необычная реакция разработчиков. Ключ не попросили. Issue на GitHub закрыли. Удалили ссылку на статью из issue. Нет ссылки — нет проблем. Нет ссылки — нет возмущающихся людей, что баги не правятся. :) Ok.
Может, им нужно скриптом залить логи анализатора на гитхаб? По issue на каждое предупреждение…
Может им ничего не нужно?) Вот недавний пример с LibreOffice. Отчёт я им предоставил. Уже сделали более 150 коммитов с правками, более 1000 разобранных предупреждений PVS-Studio, сотни модифицированных файлов. Работают каждый день на протяжении уже 3-х недель. Присылают фидбек пару раз в неделю.
Вот я почитал этот issue. Его закрыли по двум с половиной причинам:
1. Во-первых, это не issue, а ссылка на статью, — и ничего не говорит о конкретных дефектах,
2. Во-вторых, чтобы воспроизвести этот результат, нужно обладать проприетарным ПО,
а выглядит issue (по содержанию, по оформлению) — как реклама.

Я не думаю что они противники пиара вашего инструмента, или сами себе противники, только github сочли для этого неподходящим местом. А так как issue — не issue, а непонятно что, его и закрыли.

Хотя я попользовался этим infer.net — он реально сырой.
Pull Request'ы часто непонятно, как оформить, поэтому Issue выглядит удобным уведомлением. Я бы даже сказал, очень удобным. Потому что коммиты проблем можно привазывать к Issue и организованно работать над выявленными проблемами.

Но реальность отличается, конечно. После сотен проектов приходит понимание, что всё это банально кадровый вопрос. Кто-то реально работает с результатами анализа, мы и лицензию выдаём для полной чистки кода. Кто-то забивает на нас. Если отрепортить сотни раз похожий материал, а получить разные реакции, что отчётливо видишь, что на проект влияют всего несколько человек и хорошо, если они заинтересеованы в его развитии.
Потому что коммиты проблем можно привазывать к Issue и организованно работать над выявленными проблемами.

Коммиты удобно привязывать там, где один коммит фиксит один issue.
Если же у вас десяток проблем в одном issue, это уже неудобно. А если это не просто десять одинаковых предупреждений PVS, а десять разных, то совсем неудобно.
Sign up to leave a comment.