Есть ли какие-либо предложения по разработке документа о стандартах кодирования C# / передовой практике?

Начнем с того, что

• Рекомендации Microsoft по .NET: http://msdn.microsoft.com/en-us/library/ms229042.aspx (ссылка обновлена для .NET 4.5)
• Рекомендации Microsoft C#: http://blogs.msdn.com/brada/articles/361363.aspx .

а затем документируйте различия и дополнения к этой базовой линии.

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

По иронии судьбы установление фактических стандартов, скорее всего, будет легкой частью.

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

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

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

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

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

Другие плакаты указали вам на исходную точку, все, что я хотел бы добавить, - это сделать ваш документ коротким, сладким и по существу, используя большую дозу Странка и белого, чтобы отличить "must haves" от "it would be nice ifs".

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

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

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

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

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

Я нашел следующую документацию очень полезной и краткой. Он взят с сайта idesign.net и является автором Juval Lowy

Стандарт Кодирования C#

NB: приведенная выше ссылка теперь мертва. Чтобы получить файл .zip, вам нужно дать им свой адрес email (но они не будут использовать его для маркетинга... честно) попробуй здесь

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

m_strName = p_strName;

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

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

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

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

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

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

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

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

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

Поскольку я написал и ту, что была опубликована для Philips Medical Systems, и ту, что на http://csharpguidelines.codeplex.com , я, возможно, немного предвзят, но у меня есть более 10 лет на написание, поддержку и продвижение стандартов кодирования. Я попытался написать один CodePlex с учетом различий во мнениях и потратил большую часть введения на то, как справиться с этим в вашей конкретной организации. Прочитайте его и предоставьте мне обратную связь.....

У меня был бы соблазн применить Microsoft StyleCop в качестве стандарта. Он может быть применен во время сборки. но если у вас есть устаревший код, то просто примените использование StyleCop на новом коде.

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

В конечном итоге у него будет возможность рефакторинга для очистки кода.

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

Правила SSW

Он включает в себя некоторые стандарты C# + намного больше.... в первую очередь ориентирован на разработчиков Microsoft

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

Я уже использовал Juval'S раньше, и это если не излишне, но я ленив и теперь просто подчиняюсь воле Resharper .

Весь наш стандарт кодирования примерно гласит: "Use StyleCop."

Вы, скорее всего, настроены на неудачу. Добро пожаловать в индустрию.

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

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

Вы можете проверить это, топ-7 стандартов кодирования & руководящие документы для C#/.NET разработчиков http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html надеюсь, что это поможет

Видеть это: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx .

Я большой поклонник книги Франческо Балены "практические рекомендации и лучшие практики для разработчиков VB и C#".

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

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

Другим источником могут быть профессиональные рекомендации по кодированию C#/VB .NET .

Я также следую Resharper. Также путеводная линия упоминается в блоге Скотта Гатри http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net.aspx и http://csharpguidelines.codeplex.com/releases/view/46280

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

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

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

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