Что должно быть включено в стандарт программирования C #? - PullRequest
2 голосов
/ 07 ноября 2008

Мне было поручено написать стандарт программирования C # нашего отдела (включая рекомендации). Какие стандарты / руководящие принципы я должен включить? Я уже взял кусочки из различных стандартов в сети (и фрагменты из Code Complete), но я хотел бы услышать от разработчиков на местах.

Я уже получил: Соглашения об именах - Общие / Переменные / Классы / Методы / Интерфейсы / Элементы управления

Общая практика программирования - Документация (комментарии и т. Д.), [WIP]

Практики программирования OO - инкапсуляция, [WIP]

Что еще было бы полезно? Что я не должен включать?

Ответы [ 3 ]

7 голосов
/ 07 ноября 2008

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

  • Вы должны очень редко создавать свои собственные структуры. Не думайте о них как о легких классах.
  • Структуры никогда не должны быть изменяемыми.
  • Поля всегда должны быть закрытыми, кроме полей только для чтения, где тип поля неизменен
  • Попытайтесь программировать без блокировки, если вы уверены, что более простое решение будет слишком медленным - и у вас есть доказательства!
  • Читаемость - король
  • Знайте о культурных проблемах - в частности, прочитайте Рекомендации Microsoft по обработке строк

Я добавлю больше, как я думаю о них ...

2 голосов
/ 07 ноября 2008

Информация о том, как обрабатывать пространства имен, соглашения об именах сборок / проектов / решений, соглашения об именах файлов ... группирование элементов (например, у вас есть Item и Item, они находятся в одном файле?)

  • Руководство по именам файлов
  • Правила именования / организации пространства имен
  • Руководства по проектированию и архитектуре, такие как использование интерфейсов для создания вши, и создание eaiser для тестирования юнитов (например, для внедрения зависимостей и насмешек)
  • Советы о том, когда что-то должно быть реорганизовано (длинные методы и т. Д.)
  • Наименование и регистр для параметров
  • Руководство по юнит-тестированию (если вы его используете) и по издевательству
  • Группировка элементов (например, у вас есть как универсальная, так и не универсальная реализация класса, они находятся в одном файле или в отдельных файлах в соответствии с соглашением об именах?)
  • Как обрабатывать сторонние зависимости
  • Содействие использованию таких инструментов, как FxCop, StyleCop и другие метрики

Просто пара вещей с макушки головы

1 голос
/ 07 ноября 2008

Полезны указания по максимальной длине метода, максимальному размеру класса и максимальному loc в исходном файле.

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

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

Короче говоря:

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

...