Есть ли предложения по разработке стандартов кодирования на C# / рекомендаций? [закрытый]

Я недавний выпускник AI (около 2 лет), работающий на скромную операцию. Мне выпало (в первую очередь, поскольку я первый "усыновитель" в отделе) создать базовый (читать полезно?) В документе о стандартах кодирования#.

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

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

Так вот .... есть предложения? Вообще?

26 ответов


начнем с

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


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


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

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

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

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

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


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


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

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

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


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

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

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


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

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

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


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

m_strName = p_strName;

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


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

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

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


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


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

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

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

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


лично мне нравится тот, что в idesign собрал. Но я пишу не поэтому...

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

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

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


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


правила SSW

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


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


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

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


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

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


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



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


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


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


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

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

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


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

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


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

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

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-space. Однако, после некоторого практика, я обнаружил, что это действительно помогает мне писать менее запутанный код, применяя своего рода ограничение отступов.

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

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

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