Какие показатели мы должны использовать для оценки качества кода?

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

Вы смешиваете две разные вещи.

Вы говорите о стиле кодирования, но затем упоминаете покрытие тестами, метрики и т. Д.

Безусловно, можно указать стиль кодирования - все, что в документе с требованиями должно указывать, это то, что «В целях поддержки и согласованности кода в этом проекте будут использоваться эти стили и стандарты кодирования».

Однако, как правило, для большинства проектов просто требуются «передовые отраслевые практики» и «единый стиль кодирования в рамках всего проекта», а фактическое определение и реализация этого остается на усмотрение разработчиков.

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

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

Короче, да, все это можно (и нужно, ИМХО) уточнить для любого значимого проекта.

-Адам

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

Люди, особенно новички в проекте, всегда привносят свой стиль. Проверки кода помогают андрогинизировать код.

Есть так много вещей, которые можно назвать атрибутами нормального / хорошего кода.

• без ошибок и предупреждений при компиляции

есть также несколько других тем на SO по этой теме ...

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

1. Управление требованиями. Придумайте какой-нибудь процесс для применения контроля качества к вашим требованиям. Есть ли в них смысл? Кто об этом просил? Правильно ли они обращаются с такими просьбами?

2. Дизайн теста. Создавайте тесты в соответствии с требованиями, а не реализацией. Не позволяйте кодерам проводить тестирование!

3. Проверяйте все - каждый раз. Пройдите полный цикл тестирования для каждого выпуска, не существует такого понятия, как второстепенный выпуск.

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

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

StyleCop ... также, FxCop ...

Команда должна полностью стандартизировать свои стили. Некоторая свобода для личного выбора, но команда должна абсолютно стандартизировать свои стили. Код более читабелен, удобнее в обслуживании, легче проверять и т. Д. И т. Д. И т. Д.

Какие-то рекомендации (стиль менее важен, чем контент IMO), например. лучшие образцы / практики, но, что более важно, ОБЗОРЫ КОДА.