Реализация и осуществление [закрытых] стандартов кодирования

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

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

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

Его трудное для преувеличения важности кодирования стандартов. Ключ - то, что у Вас должна быть последовательная кодовая база, которую все могут считать и понять быстро. Его менее важное, какой набор стандартов Вы выбираете (пока все подписываются) - но если Вы выбираете стандарт, это широко используется затем меньше разработчиков, должно будет скорректировать их стиль. Microsoft Design Guidelines для Разработчиков Библиотеки классов является моим фаворитом (и очень дружественный ReSharper).

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

StyleCop был бы большой справкой.

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

Спасибо всем за Ваш совет. Я хотел бы услышать больше. Как это происходит, когда я изучал Resharper, как рекомендовал Ilya Ryzhenkov, я, оказалось, повторно загружал стандарт IDesign, который появляется в zip-файл со ссылкой на эту запись в блоге. Хорошая часть - это значения по умолчанию к стандарту, который я хочу использовать. Это недорого (читайте свободный, если Вы не жертвуете), и Ihappend, чтобы быть большим поклонником Порыва Кода! и Осуществите рефакторинг, таким образом, у меня уже есть загруженный DXCore!

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

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

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

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

Я был отправлен это в ответ однажды, Ночные Сбои Сборки Hitler: http://www.youtube.com/watch?v=Azl4nqLn4-Y

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

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

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

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

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

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

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

Кстати, обеспечили ли вы правильное поступление от команды?

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

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");
  ...

, потому что теперь такой материал занимает три строки и, следовательно, не записывается (или, если это так,

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

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

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

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

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

Я не могу выделить этот момент достаточно: не переживайте по мелочам . (См. Пункт № 0 замечательной книги «Стандарты кодирования C ++».)

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

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

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

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

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

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

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

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

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

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