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

Я недавний выпускник ИИ (около 2 лет), работаю на скромном предприятии. На меня выпало (прежде всего потому, что я первый «усыновитель» в отделе) создать базовый (полезный?) Документ стандартов кодирования C#.

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

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

Итак, начнем .... есть предложения? Есть вообще?

Ответов (25)

Решение

Начнем с

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

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

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

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

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

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

Правила SSW

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

Раньше я использовал Juval's, и это прошло, если не переборщить, но я ленив и теперь просто подчиняюсь воле 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарт 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/

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

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

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

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

Другой источник может быть Professional C# / VB .NET Coding Guidelines .

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

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

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

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

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

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

m_strName = p_strName;

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

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

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

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

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

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

В коде, который я пишу, я обычно следую рекомендациям по проектированию .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 ;-)