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

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

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

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

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

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

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

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

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

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

Суммируя:

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