Рекомендуемые стандарты кодирования .NET / C #? [закрыто]


19

Какие стандарты кодирования, на ваш взгляд, важны для проектов .NET / C #? Это может быть что угодно, начиная с фигурных скобок, пробелов и педантизма. Или это могут быть более фундаментальные вопросы, такие как, какие пространства имен в .NET Framework следует избегать, лучшие практики с файлами конфигурации и т. Д.

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

Ответы:


29

Вот официальное руководство Microsoft по стандартам кодирования для .NET Framework версии 4.0.

Если вы хотите старую версию для 1.1, попробуйте здесь .

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


3
Да, не могу ошибиться, сравнивая то, что используют люди, которые создают программное обеспечение. Я видел несколько религиозных войн из-за такого рода вещей, но когда вы получили что-то, что позволит вашему собственному коду соответствовать структурам, которые он использует, у вас должен был быть чрезвычайно сильный аргумент, чтобы не использовать его. В качестве бонуса, инструменты статического анализа, которые производит MS, уже настроены на поиск этих методов.
Тодд Уильямсон

Могу ли я получить отзыв о downvote, пожалуйста?
Райан Хейс

Что вы не следуете?
JeffO

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

10

Возможно, стоит взглянуть на StyleCop . Вы даже можете включить его в некоторые системы сборки, чтобы ошибки стиля не повредили сборку. Настройки по умолчанию в основном соответствуют рекомендациям MS (опубликованным другими).

Вы также можете изменить правила, с которыми он поставляется по умолчанию.



5

Мы приняли это в нашем офисе. Это написано Лэнсом Хантом, и оно довольно всеобъемлющее:

http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx


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

4

Начните с FxCop . Он расскажет вам о нарушениях лучших практик в вашем существующем коде.


FxCop смотрит на двоичные файлы, он не расскажет вам о стиле кодирования, но обнаружит некоторые проблемы.
Стив

2

Я пытаюсь выбрать общий набор стилей из разных источников. Некоторые, которые не были упомянуты ранее:


2

Я должен рекомендовать стандарты, предоставляемые SSW (Австралийская консалтинговая компания).

Не только кодирование, но и управление проектами и т.д ... Невероятно ценный ресурс.

http://www.ssw.com.au/ssw/standards/default.aspx


2

Методы должны быть короткими

Большинство методов должны использовать большинство полей в классе.

Выбери свои имена хорошо.

Например , читать Чистый код книги


2

Я использую следующие приложения для поддержания стандарта кодирования помимо правил верблюдов, имени метода и т. Д.

GhostDoc - добавляет автоматически сгенерированный комментарий в верхней части каждого метода. Приложение предоставляет хорошее начальное резюме метода. (свободно)

http://submain.com/products/ghostdoc.aspx

Resharper - анализ кода и рефакторинг http://www.jetbrains.com/resharper/

StyleCop - В качестве окончательной очистки перед регистрацией в TFS. (свободно)

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


1

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

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

Все бесполезно в большой картине.

То, что важно для написания эффективного, поддерживаемого и читаемого кода, никогда не упоминается в этих стандартах.

Например: вы помещаете свои переменные вверху или внизу своего класса? Ну, кого это волнует - важно, если вы сгруппируете свои переменные по функциональным областям. Это имеет значение (вы будете знать это, если вы когда-нибудь видели 20 переменных, разбросанных по всему месту).

Они говорят вам, чтобы поставить свои фигурные скобки в определенных местах. Большое дело! Я могу читать код в скобках в стиле K & R и ANSI, это не имеет значения. Важно то, что все классы Window как-то различаются (например, с суффиксом Form, Dlg и т. Д.), Чтобы вы могли видеть, какие файлы содержат код окна, а какие - обычные объекты.

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

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

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


1

Предупреждение: прагматизм ниже . Вопрос, похоже, сформулирован так, чтобы вызвать дебаты о «правильном» стиле фигурных скобок и т. Д. Я не мичу с тратой времени на эту чушь.

  1. Установите ReSharper , оставьте значения по умолчанию, делайте все, что он говорит.

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

Чем меньше времени ваша команда тратит на создание и ссылки на какой-то огромный документ или книгу, или на размышления о том curly bracesили ином бессмысленности, тем больше кода они будут выполнять. ReSharper будет вводить имена и стили по мере их ввода. Выполнено. Заключительное обсуждения. Спорить не о чем. Двигаемся дальше.

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

Если вы хотите улучшить то, что может сделать для вас resharper , добавьте StyleCop с плагином StyleCop for ReSharper. Как уже упоминалось, будет несколько незначительных конфликтов между рекомендациями MS и настройками ReSharper по умолчанию. Я бы просто пошел с ReSharper на них. Но какую бы сторону вы ни выбрали, просто сохраните результаты в конфигурационном файле ReSharper, поделитесь им со своей командой и все готово.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.