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

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

Мы начинаем с

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

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

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

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

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

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

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

По иронии судьбы установить настоящие стандарты, вероятно, будет проще всего.

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

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

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

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

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

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

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

You are most likely being set up to fail. Welcome to the industry.

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

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

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

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

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

Стандарт Philips Medical Systems хорошо написан и в основном соответствует рекомендациям Microsoft: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

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

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

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

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

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

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

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

Стоит проверить;)

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

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

Следующая документация показалась мне очень полезной и краткой. Он взят с сайта idesign.net, его автором является Жюваль Лоуи.

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

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

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

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

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

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

m_strName = p_strName;

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

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

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

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

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

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

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

Раньше я использовал Juval, и это закончилось, если не переборщить, но я ленив и теперь просто подчиняюсь воле Решарпер.

Я также слежу за Решарпером. Также руководство, упомянутое в блоге Скотта Гатри 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 Framework для общедоступных API и Рекомендации по моно-кодированию для корпуса и отступов частных членов. Mono - это реализация .NET с открытым исходным кодом, и я думаю, что эти ребята знают свое дело.

Я ненавижу то, как код Microsoft тратит впустую место:

try
{
    if (condition)
    {
        Something(new delegate
        {
            SomeCall(a, b);
        });
    }
    else
    {
        SomethingElse();
        Foobar(foo, bar);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Okay, you got me");
}

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

Мне также нравится, как они ставят пробел перед открывающей скобкой.

try {
        if (condition) {
                Something (new delegate {
                        SomeCall (a, b);
                });
        } else {
                SomethingElse ();
                Foobar (foo, bar);
        }
} catch (Exception ex) {
        Console.WriteLine ("Okay, you got me");
}

Но, пожалуйста, не навязывайте ничего подобного, если вашим коллегам это не нравится (если вы не готовы внести свой вклад в Mono ;-)

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

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

Правила SSW

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