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

Я недавний выпускник ИИ (около 2 лет), работающий на скромную операцию. Это упало для меня (прежде всего, поскольку я первый "усыновитель" в отделе), чтобы создать базовый (прочитанный полезный?) Документ стандартов кодирования С#.

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

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

Итак, здесь идет... любые предложения? Любой вообще?

ОТВЕТЫ

Ответ 3

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Ответ 9

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

m_strName = p_strName;

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

Ответ 10

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

Ответ 11

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

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

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

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

Ответ 12

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

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

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

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

Ответ 13

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

Ответ 14

Правила SSW

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

Ответ 15

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

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

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

Ответ 17

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

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

Ответ 19

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

Ответ 20

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

Ответ 21

Я использовал Juval раньше и это, если бы не перебор, но я ленив и теперь просто согласен с волей Resharper.

Ответ 23

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

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

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

Ответ 24

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

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

Ответ 26

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