Внедрение и применение стандартов кодирования

Question

Моя команда (из которой я - самый новый и самый младший член) увеличилась в размере от 3 до 9 разработчиков всего за 1 год. Наш основной продукт увеличился по сложности, и мы собираемся провести перенос портов/перезапись на год в Silverlight. Раньше не было определенного стиля/стандарта.

Я предложил моему начальнику, что сейчас самое подходящее время для реализации таких стандартов. Я передал ему документ IDesign's, и ему нравится эта идея. У него две проблемы.

1. Это большой документ для поглощения. Моя мысль здесь состоит в том, чтобы разработать сглаженный чит-лист для наиболее распространенных предметов, с которыми мы, вероятно, столкнемся, с пониманием того, что стандартом IDesign является «Мастер», и все, что не рассматривается в уменьшенной версии, должно выглядеть в документе «Мастер».

2. Каков наилучший способ обеспечить соблюдение этого. Дело не в том, чтобы пытаться диктовать; дело в том, чтобы заставить людей привыкнуть к определенному стандарту. В команде есть как минимум 2 человека, которые уже несколько лет развиваются до нынешнего нестандартного уровня. Чтобы решить эту проблему, я хотел бы посмотреть, есть ли инструмент, который можно настроить для обеспечения соблюдения этих стандартов или, как минимум, предупреждать о «нарушениях» стандарта во время компиляции или времени разработки. Я нашел Microsoft'd StyleCop, но из того, что я смог определить, он не настраивается и настроен на соответствие стандарту Microsoft, который не полностью связан с IDesign.

Любой вход на инструменты или подход, на который я смотрю, будут оценены.

Answer 1

Комбинация ReSharper, FxCop/StyleCop (есть способ определить пользовательские правила, по крайней мере, для FxCop), четкие руководящие принципы кода и ежемесячные обзоры должны выполнять работу для команды из девяти человек, я думаю. Если кто-то нарушит правила, у вас не будет никакого способа, кроме как использовать хлыст :)

Answer 2

Попробуйте ReSharper, он может отформатировать код в вашем стиле. Даже переформатировать все решение сразу.

Answer 3

Регулярные обзоры кода будет хорошим способом пойти ...

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

Использование инструмента вместе с обзором кода должно быть хорошим.

Answer 4

StyleCop будет большой помощью.

Answer 5

Если ваша команда имеет непрерывную сборку (например, с использованием Hudson), вы можете применять ограничения стиля путем сбоя сборки или ее неустойчивости, когда кто-то совершает изменения, которые нарушают правила стиля. У Hudson есть плагин Violations, который можно использовать с такими инструментами, как Checkstyle и StyleCop.

Answer 6

Благодарим вас за советы. Мне бы хотелось услышать больше. Как это происходит, когда я смотрел в Resharper, как рекомендовал Ilya Ryzhenkov, мне довелось повторно загрузить стандарт IDesign, который поставляется в zip-файле со ссылкой на этот blog entry. Хорошая часть - это стандарт по умолчанию, который я хочу использовать. Это недорого (читайте бесплатно, если вы не пожертвуете), а Ihappend станет большим поклонником Code-Rush! and Refactor, поэтому у меня уже загружен DXCore!

Answer 7

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

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

Answer 8

Его трудно переоценить важность стандартов кодирования. Ключ в том, что у вас должна быть постоянная база кода, которую каждый может быстро прочитать и понять. Его менее важно, какой набор стандартов вы выбираете (пока все подписываются), но если вы выберете стандарт, который широко используется, меньшее количество разработчиков придется корректировать свой стиль. Microsoft Design Guidelines for Class Library Developers - мои любимые (и очень ReSharper).

Мой коллега (Howard van Rooijen) и его команда с открытым исходным кодом разрабатывают отличный StyleCop for ReSharper, который показывает нарушения стиля в реальном времени, выделяя их при вводе! Был рекомендован recent release.

Answer 9

Я только что написал блог об использовании ReSharper и StyleCop и обеспечил его непрерывную интеграцию (используя NAnt).

http://www.robertbeal.com/archives/47

Посмотрите, что вы думаете об этом. Это работает очень хорошо для нас. Несколько ворчат, поскольку в настоящее время я не выполняю сборку, если введено одно нарушение кода. У нас действительно есть десятки тысяч нарушений (в основном в старых устаревших кодах), поэтому мой ответ - очистить один из них, а код - лучше не хуже.

Я получил послал это в ответ сразу, Nightly Сложение Гитлера не удается: http://www.youtube.com/watch?v=Azl4nqLn4-Y

Answer 10

В нашей компании мы используем эталонные карты для C#. Справочные карты производятся в Powerpoint с использованием 2 слайдов. Frontslide и backslide (печать на 2 страницы). Каждый слайд имеет 3 столбца (настройка газеты). Между каждой колонкой 1 см белого цвета делается для достижения складок.

Поместите наиболее важные аспекты полного руководства по кодированию компании на 2 слайда (например, у нас есть стиль кодирования, пространства имен & структура решения, соглашения об именах).

Вы выбрали директивы кодирования IDesign из коробки. Возможно, вам легче разбираться в стиле кодирования MS, но это ваш выбор. Большинство разработчиков знакомы с рекомендациями MS и, следовательно, легче разбираются в них.

Answer 11

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

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

В стороне от вас, вы обеспечили себя в команде?

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

public bool compare (Object other){ 
    if(other == null) throw new NullPointerException("You twit, don't give me a null pointer"); 
    if(!(other instanceof CustomerObject)) throw new UnsupportedArgumentException("Give me the right argument, dammit"); 
    ... 

Потому что такие вещи теперь занимают три строки, и, следовательно, не напишите (или если это произойдет, не дайте программисту понять, что делает этот метод).

Answer 12

Примечания к моему опыту получения бай-ин по стандартам кодирования в моей текущей компании (разработчик небольшого размера из нескольких проектов, каждый из которых состоит из 1-6 программистов, мы в основном C++, но я думаю, что ответы будут по-прежнему применяться):

A код проверки чит-лист - отличная идея. Подчеркните его в соответствии с вашей организацией (например, что легко упустить или не получится) и обновите его, когда вы идете (один раз в месяц, возвращайтесь и удаляете материал, который применяется другими способами). Если у вас есть wiki, включите ссылки на «почему» для каждой точки, если сможете!

Разделите свои отзывы. Некоторые коммиты просят официальные отзывы, некоторые - нет. Мы используем несколько типов:

• отзывы Мини-Design-Doc, в котором короткие (обычно одна или две страницы на вики) прокомментированы группой до начала реализации. Отлично подходит для поиска «изобретать колесо» раньше.
• Проведено теплые отзывы, где один или несколько сверстников сидят с оригинальным автором до совершения (отлично подходят для распространения опыта, в результате чего кооперативы/интерны достигают скорости). Оригинальный автор имеет тенденцию выявлять больше проблем, чем рецензенты в них. =)
• Формальный пост-фиксация отзывы о холоде, где кто-то без руководства (кроме комментария и любой документации) просматривает код. Это имеет тенденцию выявлять проблемы с логикой или ошибкой, а также ошибки границ.

Автоматизировать и толкать, не тянуть полезной информации. Мы отправляем отчеты с нашего сервера buildserver - он обычно создается один раз за фиксацию (в зависимости от того, насколько он занят). Эти отчеты могут включать, например, различия между текущим запуском Gimpel PC-Lint и последним. Это относится к проблеме «слишком много информации»: вы получаете только предупреждения/ошибки , вы, возможно, ответственны за, а также за описание. Когда информация сужается и понятна, люди используют ее как инструмент обучения.

Я не могу подчеркнуть этот бит достаточно: не потеть мелкие вещи. (Смотрите пункт # 0 чудесные C++ Coding Standards книги.)

• Разделите стандарт кодирования в двух или более секции, в «нужном» и в раздел «рекомендованного» - позволяют людям читать рекомендованный раздел на их досуга, и сохранить необходимый раздел небольшим.
• При анализе явно очертите материал, который действительно важно исправить прямо сейчас, и материал, который нет. Например, для наших «теплых обзоров»: расположение кронштейнов и несогласование именования явно «исправить это позже», потому что мы не хотим аннулировать те тесты, которые были сделаны перед опросом перед фиксацией.Ошибки логики «исправлены сейчас, перед фиксацией». Ошибки обработки ошибок или недостающие случаи различаются. Если вы требуете, чтобы люди сразу исправляли нарушения, вы получите недовольство.

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

Answer 13

Использование TFS и VS 2010, с C# базы, мы делаем это так:

Мы используем неотредактированную idesign стандарт в качестве стандартного кода на бумаге.

Мы поддерживаем один набор определений кода и определения стиля Cop, которые мы запускаем на выпусках с нулевым допуском.

Мы также поддерживаем совместимое определение корня Resharper, которое позволяет разработчикам быстро форматировать свой код в стиле, когда они работают с ним. Это облегчает их рабочий процесс, поскольку им больше не нужно ждать предупреждений SA/CA из проверок времени сборки.

Мы разрешаем разработчику переопределять определение корня.

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