Как ваша команда настроила Stylecop (и, возможно, другие инструменты) для .Net для достижения хорошего результата? - PullRequest
1 голос
/ 18 мая 2010

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

Прежде чем сделать это, я хотел спросить других ТАК пользователей. Для стандартизации (но не ограничения) ответов:

  1. Какая у вас текущая версия StyleCop?
  2. На какую версию .Net вы сейчас нацелены?
  3. Какие правила по умолчанию вы отключили?
  4. Какие не стандартные правила вы включили?
  5. Вы закодировали свои собственные правила? Пожалуйста, опишите.
  6. У вас есть еще какие-нибудь трюки с StyleCop, которыми стоит поделиться?
  7. Вы используете Resharper? Какая версия? Это хороший удар для доллара?
  8. Используете ли вы какие-либо другие инструменты для .Net / C ++, которые интегрируются с Visual Studio и помогают в разработке? Вы получили ценность своих денег?
  9. Что-нибудь еще, что вы хотели бы добавить?
  10. ...

Спасибо!

Ответы [ 3 ]

3 голосов
/ 18 мая 2010
  1. Какая у вас текущая версия StyleCop? 4.3.3 локально, 4.3.0 на сервере сборки
  2. На какую версию .Net вы сейчас нацелены? 2,0 или 3,5
  3. Какие правила по умолчанию вы отключили? нет
  4. Какие нестандартные правила вы включили? только что добавил пару исключений в венгерское правило
  5. Вы закодировали свои собственные правила? Пожалуйста, опишите. Нету
  6. У вас есть еще какие-нибудь трюки с StyleCop, которыми стоит поделиться? используйте элемент <ExcludeFromStyleCop> в файлах вашего проекта
  7. Вы используете Resharper? Какая версия? Это хороший удар для доллара? да, R # 5, большое значение (особенно с StyleCop для ReSharper )
  8. Используете ли вы какие-либо другие инструменты для .Net / C ++, которые интегрируются с Visual Studio и помогают в разработке? Вы получили ценность своих денег? GhostDoc - единственный другой инструмент, который мы используем
2 голосов
/ 18 мая 2010
  1. Я нахожусь на 4.3.3.0
  2. .net 3.5
  3. Лоты, вся документация и коллекция других.
  4. Нет, IIRC.
  5. В прошлом я это делал. В настоящее время у меня нет требований к стилю кодирования, но раньше я это делал. Я создаю собственные правила для них, когда они у меня есть.
  6. "Правый клик по предупреждению, Показать справку об ошибках" - хороший вариант. Мой любимый вариант - «добавить файл Settings.StyleCop в папку« Элементы решения »».
  7. Нет, но я бы, если бы мог.
  8. FxCop. Да, бесконечное соотношение цены и качества.
  9. Да. Какие правила вы включаете / отключаете, должны полностью основываться на правилах кодирования, которые вы пытаетесь проверить. Причина, по которой вы не знаете, какие из них использовать, вероятно, потому что у вас их нет. Итак, это первое, что вы должны сделать, создать набор правил кодирования. Вы можете использовать StyleCop, чтобы определить, какие правила вы хотите применить (начните со всех из них и удалите одно, когда все согласятся, что это правило не дает никакой ценности для усилий, которые потребуются для его исправления). Это кажется немного отсталым и может упустить возможность иметь стандарт кодирования, который еще не был применен в StyleCop, но определенно лучше, чем ничего. И это был бы быстрый способ создать некоторые местные стандарты. Другим способом сделать это было бы поискать существующих опубликованных руководящих принципов кодирования , с которыми ваша команда может более или менее согласиться (1), и затем настроить StyleCop для обеспечения их соблюдения. В любом случае, наличие единообразного стиля кодирования в группе позволяет многому научиться, и StyleCop - это способ применить его.
  10. Пользовательские правила потрясающие. Не стоит сбрасывать со счетов возможность отключения правила StyleCop и реализации «лучшей» версии того же правила.

(1) Это как начинки для пиццы, вы никак не можете получить полное согласие в группе, но может возникнуть общее согласие

1 голос
/ 18 мая 2010
  1. 4.3.3
  2. .NET 3.5
  3. Выключено SA1309 - имена полей не должны начинаться с подчеркивания (для частных переменных за свойством
  4. Пользовательское правило, что никакие переменные не начинаются с "m _"
  5. Да, пользовательское правило в # 4 основано на коде в этом блоге
  6. не совсем
  7. нет
  8. мы используем плагин VisualSVN, он бесплатный, и мы находим его полезным, поскольку мы используем Subversion для контроля версий
...