Комментарии 27
Очень хотелось бы ссылок на другие полезные анализаторы
github.com/icsharpcode/RefactoringEssentials
Выглядит скорее как «open-source R#»
Вот еще в ту же степь https://github.com/JosefPihrt/Roslynator
и логично предоставить возможность подключать / отключать их по одному
Так есть же возможность через ruleset (или как он там называется)
Или это для тех, кто регулярками для поиска пользоваться не умеет, чтобы немного порефакторить?
Да, конечно лучше бы сразу писать хорошо. Я выбрал анализаторы перед другим рассматриваемом вариантом «машина времени». Код по факту уже был написан так, когда мне достался.
Но и это еще не все. Вопрос в том, как добиться этого «сразу писать хорошо». Какие варианты? Изначально мы полагались на внедрение code review. Но вопрос в том, что code review требует времени ревьюеров. Если их мало, они становятся узким местом. Если много, то вопрос в том, как добиться унификации и соблюдения стандартов среди ревьюеров. Процесс распространения культурных изменений в компании — дело не одного дня, и часто — не одного месяца.
Про рефакторинг. В принципе, для небольших проектов просто поискать по солюшену — не сложно. Для крупных — сложнее. Начинаешь утопать в false позитивах и допустимых случаях — в комментариях можно. В SoapDocumentMethodAttribute можно. Пропустить один — довольно легко.
К тому же анализаторы поддерживают однажды свершенные победы (выпилены все хардкоды URLов) в актуальном состоянии.
Вы ещё попросите разработчиков сразу писать код без багов.
Может интегрироваться в IDE — http://www.sonarlint.org
На работе пользуемся более чем для пяти языков, при необходимости сами пишем плагины и новые правила.
Можно ли с помощью Roslyn написать например анализатор того, что в catch блоке программист не забыл залогировать ошибку? Основная проблема — логирование может быть вызвано не сразу, а например может быть вызван метод, который уже и залогирует. То есть нужно лезть внутрь по цепочке вызовов. Поможет ли в этом случае семантическая модель или roslyn не подходит для такого вида проверок?
Чем перебирать весь стек вниз, я бы сделал так:
Опознавать вызовы нескольких стандартных библиотек для логирования;
Предоставить атрибут, которым можно пометить метод, чтобы он считался «логирующим». Тогда вы можете прометить им свои обертки.
Кстати, вот такое решение примерно все наши проблемы решило с этим
https://github.com/SergeyTeplyakov/ErrorProne.NET/#exception-handling-rules
Борьба с хардкодами при помощи статических анализаторов С#