Есть ли какие-либо предложения для разработки C#, кодирующего стандарты / документ лучших практик? [закрытый]

Стандарт от Philips Medical Systems правильно написан, и главным образом следует инструкциям Microsoft: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

Мои стандарты основаны на этом с несколькими тонкими настройками, и некоторые обновления для.NET 2.0 (стандарт Philips записан для.NET 1.x, так немного датирован).

Посмотрите это: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx .

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

, Который интересен, потому что мой менеджер сказал мне в прошлом, что он не слишком увлечен ими: D

у Вас есть забавная задача перед Вами мой друг. Всего наилучшего, и спросите, нужно ли Вам что-нибудь больше:)

Я недавно нашел Руководство Encodo C#, которое включает идеи из многих других источников (IDesign, Philips, MSDN).

Другой источник может быть Профессиональные Инструкции .

Я - большой поклонник книги Francesco Balena" Практические Инструкции и Лучшие практики для VB и Разработчиков C# ".

Это очень подробно и затрагивает все существенные темы, Это только дает Вам правило, но также и объясняет причину позади правила, и даже предоставляет антиправило, где могло быть две противостоящих лучших практики. Единственный недостаток - то, что это было записано для.NET 1,1 разработчика.

Вы, скорее всего, настраиваетесь для сбоя. Добро пожаловать в промышленность.

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

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

Я испытал бы желание осуществить StyleCop Microsoft как стандарт. Это может быть осуществлено во время изготовления. но если у Вас есть унаследованный код, тогда просто осуществляют использование StyleCop на новом коде.

http://code.msdn.microsoft.com/sourceanalysis

В конечном счете это будет иметь осуществлять рефакторинг опцию к коду очистки.

http://blogs.msdn.com/sourceanalysis/

Собственные правила Microsoft являются превосходной начальной точкой. Можно осуществить их с FxCop.

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

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

Это стоит проверить;)

Я нашел следующую документацию очень полезной и краткой. Это прибывает из сайта idesign.net, и это создается Стандартом Кодирования Juval Lowy

C#

нбар: вышеупомянутая ссылка теперь мертва. Для получения .zip файла, необходимо дать им адрес электронной почты (но они не будут использовать его для маркетинга... честно), Попытка здесь

Никогда не пишите, что Ваши собственные стандарты кодирования используют MS (или Sun или... как подходящие для Вашего языка). Подсказка находится в стандарте слова, мир был бы намного более легким местом для кодирования в том, если каждая организация не решила записать их собственное. Кто действительно думает, изучая новый набор 'стандартов' каждый раз, когда Вы изменяетесь, команды/проекты/роли хорошее использование чьего-либо времени. Большинство, которое необходимо когда-либо делать, суммируют критические точки, но я отговорил бы от выполнения даже что, потому что то, что очень важно, варьируется от человека человеку. Две других точки, которые я хотел бы сделать при кодировании стандартов

1. Близкий, достаточно хороши - Изменяющий код для следования, стандарты кодирования к букве пустая трата времени, пока код достаточно близок.
2. при изменении кода Вы не записали, следуют 'локальным стандартам кодирования', т.е. заставляют Ваш новый код быть похожим на окружающий код.

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

Я всегда использовал Juval Lowy pdf как ссылка при выполнении кодирования стандартов / лучшие практики внутренне. Это следует очень близко к FxCop / Исходный Анализ , который является другим неоценимым инструментом, чтобы удостовериться, что стандарт сопровождается. Между этими инструментами и ссылками, необходимо быть в состоянии придумать хороший стандарт, что все разработчики не будут возражать против следующего и будут в состоянии осуществить их.

Другие плакаты указали на Вас на базовую линию, все, что я добавил бы, делают Ваш документ коротким, сладким, и к точке, используя большую дозу Strunk, и White для различения "должен имущие" от, "это была бы хорошая IFS".

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

я соглашаюсь, что FxCop является хорошим инструментом, но слишком многое из этого может вынуть всю забаву прямо из программирования, так быть осторожным.

Ironically, устанавливающий фактические нормы, вероятно, будет легкой частью.

Мое первое предложение должно было бы выявить предложения от других инженеров о том, что они чувствуют, должен быть покрыт, и какие инструкции, которые они чувствуют, важны. Осуществление любого вида инструкций требует степени закрытия сделки от людей. Если Вы внезапно отбросите документ о них, который определяет, как записать код, то Вы встретитесь с сопротивлением, являетесь ли Вы самым младшим или старшим парнем.

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

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

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

IDesign имеет C#, кодирующий документ стандартов, который является наиболее часто используемым. Также посмотрите Руководство по проектированию Платформы 2-й Ed.

Я только что запустил в месте, где стандарты кодирования передают под мандат использование m_ для членских переменных, p_ для параметров и префиксов для типов, таких как 'ул.' для строк. Так, у Вас могло бы быть что-то вроде этого в теле метода:

m_strName = p_strName;

Ужасный. Действительно ужасный.

Весь наш стандарт кодирования примерно гласит: «Используйте StyleCop».

Лично мне нравится тот, который создан IDesign . Но я пишу не для этого ...

Сложность в моей компании заключалась в учете всех языков. И я знаю, что моя компания не одинока в этом. Мы используем C #, C, сборку (мы создаем устройства), SQL, XAML и т. Д. Хотя в стандартах есть некоторые сходства, каждый из них обычно обрабатывается по-разному.

Кроме того, я считаю, что стандарты более высокого уровня имеют большее влияние на качество конечного продукта. Например: как и когда использовать комментарии, когда исключения являются обязательными (например, события, инициированные пользователем), следует ли (или когда) использовать исключения или возвращаемые значения, каков объективный способ определить, каким должен быть код контроллера или код представления, и т. д. Не поймите меня неправильно, Также необходимы стандарты низкого уровня (форматирование важно для удобочитаемости!) У меня просто предубеждение в отношении общей структуры.

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

Я должен предложить документ dotnetspider.com .
Это отличный и подробный документ, который пригодится где угодно.