многие классы утечек памяти и распространенных логических ошибок также могут быть пойманы статически. Вы также можете посмотреть на цикломатическую сложность и такие, которые могут быть частью" стандартов кодирования", которые вы упомянули, но могут быть отдельной метрикой, которую вы используете для оценки алгоритмической" чистоты " вашего кода.

в любом случае, только разумное сочетание профилирования (динамический или времени выполнения анализа) и статического анализа/анализа позволит обеспечить последовательное, надежное основание кода. О, что, и немного удачи ;-)

это компромисс. Для отдельного разработчика, который хочет улучшить свое понимание рамок и руководящих принципов, я бы определенно рекомендовал его. FxCop создает много шума / ложных срабатываний, но я также нашел следующие преимущества:

• он обнаруживает ошибки (например, предупреждение о неиспользуемом аргументе может указывать на то, что вы использовали неправильный аргумент в теле метода).

• понимание рекомендаций FxCop помогает вы станете лучшим разработчиком.

однако с командой со смешанными способностями FxCop может генерировать слишком много ложных срабатываний, чтобы быть полезным. Младшим разработчикам будет трудно оценить, должны ли некоторые из более эзотерических нарушений, вызванных FxCop, касаться их или просто шум.

итог:

• Если вы разрабатываете многоразовые библиотеки классов, такие как внутренняя структура, убедитесь, что у вас есть хорошие разработчики и использовать FxCop.

• для повседневной разработки приложений со смешанными командами это, вероятно, не будет практически осуществимо.

на самом деле, fxcop не особенно помогает вам следовать стандарту кодирования. То, что он помогает вам в разработке хорошо продуманной структуры/API. Это правда, что части стандарта кодирования (например, корпус публичных членов) будут пойманы FxCop, но стандарты кодирования не в центре внимания.

стандарты кодирования можно проверить с помощью stylecop, который проверяет исходный код вместо MSIL, как это делает fxcop.

Он может ловить фактические ошибки, например, забывая утилизировать IDisposables.

зависит от правил, но много тонких дефектов можно избежать, код можно очистить, потенциальные проблемы представления можно обнаружить ЕТК.

скажем так...если это дешево или бесплатно (как во времени, так и в финансовых затратах) и ничего не ломает, почему бы не использовать его?

FxCop

список все предупреждения в FxCop. Вы можете видеть, что есть предупреждения из следующих областей:

Предупреждения Дизайн

предупреждения, поддерживающие правильную библиотеку дизайн, как указано .Чистая Основы Принципы Дизайна.

Предупреждения Глобализации

предупреждения, которые поддерживают world-ready библиотеки и приложения.

совместимость Предупреждения!--8-->

предупреждения, поддерживающие взаимодействие с com-клиент.

Предупреждения Об Именовании

предупреждения которые поддерживают придерживание к соглашения об именах .NET Основы Принципы Дизайна.

Предупреждения О Производительности

предупреждения, которые поддерживают высокую производительность библиотеки и приложения.

Предупреждения Безопасности

предупреждения, которые поддерживают безопасные библиотеки и приложения.

в зависимости от вашего приложения некоторые из этих областей могут быть не очень интересны, но если вам, например, нужна совместимость COM, тесты действительно могут помочь вам избежать подводных камней.

другие инструменты

другие инструменты статической проверки могут помочь вам обнаружить ошибки, такие как не утилизируя IDisposable утечки памяти и другие тонкие ошибки. Для крайнего случая см. Еще не выпущенный NStatic инструмент.

NStatic используется для отслеживания таких вещей, как избыточные параметры, выражения, которые оценивают константы, бесконечные циклы и многие другие метрики.

преимущества заключаются в том, что вы можете автоматически найти и количественно оценить технический долг в вашем программном приложении.

Я нахожу инструменты статического анализа кода незаменимыми при разработке крупных корпоративных приложений, где многие разработчики и тестеры приходят и уходят в течение всего срока службы приложения, но качество кода по-прежнему должно быть высоким, а технический долг управляется должным образом.

каковы преимущества статического анализа кода в исходном коде?

преимущества зависят от типа статического анализа кода, который выполняется. Статический анализ кода может варьироваться от простых до сложных методов. Например, одним из методов является создание метрик исходного кода для идентификации кода, подверженного ошибкам. Другие методы активно пытаются найти ошибки в вашем коде. Сложные методы используют формальные методы, чтобы доказать, что ваш код без ошибок.

поэтому преимущество зависит от типа используемого статического анализа кода. Если метод создает метрики (например, сложность кода и т. д.), то преимущество заключается в том, что эти метрики могут использоваться во время проверки кода для определения кода, подверженного ошибкам. Если метод обнаруживает ошибки, то преимущество заключается в том, что разработчик может идентифицировать ошибки перед модульным тестом. Если формальные методы на основе методов используются для доказательства того, что код не содержит ошибок, то преимущество что эта информация может быть использована для доказательства департаменту QA (или сертификационным органам), что код свободен от определенных типов ошибок.

более подробное описание методов и преимуществ также можно найти на этой странице: www.mathworks.com/static-analysis

Я постараюсь описать основные из них:

• статический анализ кода определяет обнаруживает в программе на ранней стадии, что приводит к снижению затрат на их исправление.
• оно может обнаружить рванины в входных сигналах и выходах программы которые нельзя увидеть через динамическое испытание.
• он автоматически сканирует несжатые коды и определяет уязвимости.
• из того, что я знаю из работы с checkmarx, это то, что статический анализ кода исправляет несколько уязвимости в одной точке, что экономит много времени для разработчика.