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

159

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

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

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

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

ТЗ.
источник

Ответы:

26

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

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

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

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

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

Эндрю Грант
источник
14

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

Дейл Раган
источник
9

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

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

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


источник
9

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

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

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

Дэвид Хейс
источник
8

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

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

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

Абель Гаксиола
источник
5

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

m_strName = p_strName;

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

demoncodemonkey
источник
1
IntelliSense в Visual Studio 2010 позволяет вводить «Имя», и оно будет соответствовать подстроке в p_strName- делает его на 10% менее болезненным, когда вы вынуждены работать с такой мерзостью. : o
Сэм Харвелл
5

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

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

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

samiq
источник
2
Я собирался предложить ту же книгу. Должен читать.
Паскаль Паради
Я сейчас читаю книгу, читаю> 67%. Это изменило способ, которым я представляю программирование. Должен прочитать.
UrsulRosu
4

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

Кит
источник
4

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

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

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

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


источник
2
Вы можете не согласиться со всем, что обеспечивается StyleCop, но учтите, что Microsoft движется к единому стандарту, как и в случае с StyleCop, - так что это набор стандартов, с которыми другие разработчики могут быть знакомы. Согласованность с большей частью остальной отрасли может быть ценной.
Беван
4

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

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

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

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

derGral
источник
4

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

Деннис Доомен
источник
Мне ДЕЙСТВИТЕЛЬНО нравится это руководство, и я думаю, что оно соответствует фантастическому формату (быстрая версия и полная версия понравились многим, кого я видел). Вы получите мой голос против всех остальных, отличная работа. Я настоятельно рекомендую использовать этот документ в Codeplex для начала, так как это действительно хорошее руководство для сравнения заметок или для более тщательного изучения.
2012 года
Я видел это. Я действительно это имею в виду, продолжайте в том же духе, и я рекомендую это руководство по крайней мере в качестве отправной точки для серьезных разработчиков .NET.
atconway
1
+1 за большую работу, хотелось бы +100. Это кратко, так что люди на самом деле будут читать его, поэтому он выигрывает стандарты Microsoft и IDesign. У него есть осмысленные имена правил, шпаргалка, файлы стилей для VS / R # ... возможно, пропущены более обширные примеры в шпаргалке :)
Виктор Сергиенко
2

Правила SSW

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

Адам Коган
источник
1

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

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

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

Адам V
источник
Я не согласен. Худшее, что может случиться, - это то, что руководящие принципы противоречивы; и ошибки проносятся мимо. Если он пишет программное обеспечение для управления LHC, тогда мы будем в порядке. /
Сарказм
1

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

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

urini
источник
1

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

Джон Крафт
источник
1

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

the_drow
источник
1

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

Kenny
источник
0

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

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

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

Роб Купер
источник
0

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

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

Джо
источник
0

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

Дан Абрамов
источник