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

Question

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

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

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

Итак , поехали ....есть какие-нибудь предложения?Вообще никаких?

Answer 1

Мы начнем с

• Рекомендации Microsoft по использованию .NET: http://msdn.microsoft.com/en-us/library/ms229042.aspx (ссылка обновлена для .NET 4.5)
• Рекомендации Microsoft по C #: http://blogs.msdn.com/brada/articles/361363.aspx.

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

Answer 2

IDesign (Дизайн идей) имеет документ о стандартах кодирования на C #, который обычно используется.Также смотрите Руководство по проектированию фреймворка 2-е Изд.

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

m_strName = p_strName;

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

Answer 9

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

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

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

Answer 10

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

Answer 11

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

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

В конечном итоге у него будет возможность рефакторинга для очистки кода.

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

Answer 12

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

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

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

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

Answer 13

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

Answer 14

Правила SSW

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

Answer 15

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

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

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

Answer 16

Недавно я обнаружил, что Руководство по кодированию C #, который включает идеи из многих других источников (IDesign, Philips, MSDN).

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

Answer 17

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

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

Answer 18

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

Answer 19

Видишь это:http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx.

Answer 20

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

Answer 21

Я уже пользовался Juval's раньше, и это было бы перебором, если бы не перебор, но я ленив и теперь просто подчиняюсь воле Перетачиватель.

Answer 22

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

Answer 23

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

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

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

Answer 24

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

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

Answer 25

Я также слежу за 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

Answer 26

В коде, который я пишу, я обычно следую Рекомендации по проектированию .NET Framework для общедоступных 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 пробелами.Однако, после некоторой практики, я обнаружил, что это действительно помогает мне писать менее запутанный код, применяя своего рода ограничение отступов.

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

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

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