Преимущества статического анализа кода
Идея заключается в том, что для соображений скорости и кеширования операнды должны считываться с адресов, соответствующих их естественному размеру. Чтобы это произошло, элементы структуры компоновщика компилируются так, чтобы следующий член или следующая структура были выровнены.
struct pixel {
unsigned char red; // 0
unsigned char green; // 1
unsigned int alpha; // 4 (gotta skip to an aligned offset)
unsigned char blue; // 8 (then skip 9 10 11)
};
// next offset: 12
Архитектура x86 всегда могла извлекать неверные адреса. Тем не менее, он медленнее, и когда несоосность перекрывает две разные строки кэша, тогда он вытесняет две строки кэша, когда выровненный доступ будет вытеснять только один.
Некоторым архитектурам на самом деле приходится ловить ложные недочетые чтения и записи и ранние версии архитектуры ARM (той, которая развивалась во всех современных мобильных процессорах) ... ну, на самом деле они просто вернули для них плохие данные. (Они проигнорировали младшие разряды.)
Наконец, обратите внимание, что строки кэша могут быть сколь угодно большими, а компилятор не пытается угадать их или сделать компромисс между пространством и скоростью. Вместо этого решения выравнивания являются частью ABI и представляют собой минимальное выравнивание, которое в конечном итоге равномерно заполняет линию кэша.
Значения TL; DR: важны.
7 ответов
Существуют все виды преимуществ:
- Если существуют антишаблоны в Вашем коде, Вас можно предупредить об этом.
- Существуют определенные метрики (такие как Цикломатическая Сложность McCabe), которые говорят полезные вещи об исходном коде.
- Можно также получить большой материал как графы вызовов и диаграммы классов от статического анализа. Это замечательно, если Вы нападаете на новую кодовую базу.
Смотрите на SourceMonitor
Много классов утечек памяти и ошибок общей логики могут быть пойманы статически также. Можно также посмотреть на цикломатическую сложность и такой, который может быть частью "стандартов кодирования", Вы упомянули, но можете быть отдельной метрикой, которую Вы используете для оценки алгоритмической "чистоты" кода.
В любом случае только разумная комбинация профилирования (динамический или анализ во время выполнения) и статический analysis/linting гарантирует последовательную, надежную кодовую базу. О, это и немного удачи ;-)
Это - компромисс. Для отдельного разработчика, который хочет улучшить его понимание платформы и инструкций, я определенно поощрил бы его. FxCop генерирует много шума / ложные положительные стороны, но я также нашел следующие преимущества:
это обнаруживает ошибки (например, предупреждение о неиспользованном аргументе может указать на использование неправильного аргумента в теле метода).
понимание инструкций, за которыми следует FxCop, помогает Вам стать лучшим разработчиком.
Однако с командой смешанной способности, FxCop может генерировать слишком много ложных положительных сторон, чтобы быть полезным. Младшие разработчики испытают затруднения при понимании, должны ли некоторые более тайные нарушения, подброшенные FxCop, коснуться их или являются просто шумом.
Нижняя строка:
При разработке допускающих повторное использование библиотек классов, таких как внутренняя платформа, удостоверьтесь, что Вы имеете хороших разработчиков и используете FxCop.
Для разработки стандартного приложения с командами смешанной способности это, вероятно, не будет реально.
на самом деле fxcop особенно не помогает Вам следовать стандарту кодирования. Что действительно помогает с разработке хорошо думавшего платформа/API. Это верно, что части стандарта кодирования (такие как преобразование регистра общедоступных участников) будут пойманы FxCop, но стандарты кодирования не являются фокусом.
с кодированием стандартов можно свериться stylecop, который проверяет, что исходный код вместо MSIL как fxcop делает.
Это может поймать фактические ошибки, как упущение Расположить IDisposables.
Зависит от правил, но многих тонких дефектов можно избежать, код может быть убран, потенциальные проблемы производительности могут быть обнаружены и т.д.
Поместите его один путь..., если это дешево или свободно (и во время и в финансовые затраты) и ничего не повреждает, почему бы не использовать его?
FxCop
Существует список всех предупреждений в FxCop. Вы видите, что существуют предупреждения от следующих областей:
Предупреждения дизайна
Предупреждения, которые поддерживают надлежащий дизайн библиотеки, как указано Руководством по проектированию Платформы.NET.
Предупреждения глобализации
Предупреждения, которые поддерживают мировые готовые библиотеки и приложения.
Предупреждения совместимости
Предупреждения, что поддержка, взаимодействующая с COM-клиентами.
Именование предупреждений
Предупреждения, что соблюдение поддержки соглашений о присвоении имен Руководства по проектированию Платформы.NET.
Предупреждения производительности
Предупреждения, что высокопроизводительные библиотеки поддержки и приложения.
Предупреждения системы безопасности
Предупреждения, которые поддерживают более безопасные библиотеки и приложения.
В зависимости от Вашего приложения некоторые из тех областей не могли бы быть очень интересными, но если Вам, например, нужна совместимость COM, тесты могут действительно помочь Вам избежать ловушек.
Другие инструменты
Другие статические инструменты проверки могут помочь Вам обнаружить ошибки как не расположение IDisposable, утечек памяти и других тонких ошибок. Поскольку крайний случай видит еще выпущенный инструмент NStatic.
NStatic используется для отслеживания вещей, таких как избыточные параметры, выражения, которые оценивают к константам, бесконечным циклам и многим другим метрикам.