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

Я недавний выпускник AI (около 2 лет), работающий на скромную операцию. Мне пришлось (прежде всего потому, что я первый «усыновитель» в отделе) создать базовый (читай полезный?) Документ по стандартам кодирования на 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-е изд .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

m_strName = p_strName;

Какой ужас. Действительно ужасно

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

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

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

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

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

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

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

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

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

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

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

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

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

Правила SSW

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я также следую за Решарпером. Кроме того, руководство указано в блоге Скотта Гатри 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 ;-)