Какие стандарты кодирования, на ваш взгляд, важны для проектов .NET / C #? Это может быть что угодно, начиная с фигурных скобок, пробелов и педантизма. Или это могут быть более фундаментальные вопросы, такие как, какие пространства имен в .NET Framework следует избегать, лучшие практики с файлами конфигурации и т. Д.
Старайтесь не создавать пост, который является просто следствием для другого. Например, было бы хорошо иметь один пост, сосредоточенный на фигурных скобках. Нам не нужно два, чтобы поддерживать один стиль против другого. Идея состоит не в том, чтобы проголосовать за стандарт вашего питомца, а в том, чтобы выяснить, о чем следует помнить при создании стандартов.
c#
.net
coding-standards
RationalGeek
источник
источник
Возможно, стоит взглянуть на StyleCop . Вы даже можете включить его в некоторые системы сборки, чтобы ошибки стиля не повредили сборку. Настройки по умолчанию в основном соответствуют рекомендациям MS (опубликованным другими).
Вы также можете изменить правила, с которыми он поставляется по умолчанию.
источник
Рекомендации от Microsoft:
источник
Мы приняли это в нашем офисе. Это написано Лэнсом Хантом, и оно довольно всеобъемлющее:
http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx
источник
Начните с FxCop . Он расскажет вам о нарушениях лучших практик в вашем существующем коде.
источник
Я пытаюсь выбрать общий набор стилей из разных источников. Некоторые, которые не были упомянуты ранее:
источник
Я должен рекомендовать стандарты, предоставляемые SSW (Австралийская консалтинговая компания).
Не только кодирование, но и управление проектами и т.д ... Невероятно ценный ресурс.
http://www.ssw.com.au/ssw/standards/default.aspx
источник
Методы должны быть короткими
Большинство методов должны использовать большинство полей в классе.
Выбери свои имена хорошо.
Например , читать Чистый код книги
источник
Я использую следующие приложения для поддержания стандарта кодирования помимо правил верблюдов, имени метода и т. Д.
GhostDoc - добавляет автоматически сгенерированный комментарий в верхней части каждого метода. Приложение предоставляет хорошее начальное резюме метода. (свободно)
http://submain.com/products/ghostdoc.aspx
Resharper - анализ кода и рефакторинг http://www.jetbrains.com/resharper/
StyleCop - В качестве окончательной очистки перед регистрацией в TFS. (свободно)
http://code.msdn.microsoft.com/sourceanalysis
источник
Я ненавижу установившиеся стандарты кодирования, все они заинтересованы либо в том, чтобы вас не делали несколько глупых ошибок, либо в том, как так или иначе форматировать ваш код. Все это мелочи.
Я имею в виду, они скажут вам, сколько пробелов ставить между операторами, как записывать ваши переменные, какие префиксы в «венгерском стиле» использовать (например, _ для членов), противоречивые советы (например, вы не можете вызвать класс Cxyz, но вы должны вызовите интерфейс Ixyz), как расположить код в коде (поместите переменную вверху класса или внизу)
Все бесполезно в большой картине.
То, что важно для написания эффективного, поддерживаемого и читаемого кода, никогда не упоминается в этих стандартах.
Например: вы помещаете свои переменные вверху или внизу своего класса? Ну, кого это волнует - важно, если вы сгруппируете свои переменные по функциональным областям. Это имеет значение (вы будете знать это, если вы когда-нибудь видели 20 переменных, разбросанных по всему месту).
Они говорят вам, чтобы поставить свои фигурные скобки в определенных местах. Большое дело! Я могу читать код в скобках в стиле K & R и ANSI, это не имеет значения. Важно то, что все классы Window как-то различаются (например, с суффиксом Form, Dlg и т. Д.), Чтобы вы могли видеть, какие файлы содержат код окна, а какие - обычные объекты.
Подобные вещи имеют гораздо большее значение, чем незначительные моменты, которые обычно содержатся в стандартах. Я не знаю, почему они так развивались, но зачастую это просто тонна правил, мешающих эффективному и продуктивному кодированию.
Мои стандарты стараются больше ориентироваться на организацию кода и файлов. У нас есть определенные стандарты, которые указывают, где файлы будут найдены. Например, ребята, не являющиеся разработчиками, могут взглянуть на один из наших проектов и сразу же получить нужные им файлы документации. Точно так же мы пытаемся расположить код проекта таким же образом, как и другие проекты, насколько это практически возможно (примечание: настолько практично, но не строго запрещенным образом, который может не подходить все время), и в основном мы пытаемся сделать руководящие принципы по стандартам, которые могут быть изменены по мере необходимости.
Короче говоря - они здесь, чтобы помочь нам работать вместе, а не как набор ограничительных правил, которые всегда должны соблюдаться.
источник
Предупреждение: прагматизм ниже . Вопрос, похоже, сформулирован так, чтобы вызвать дебаты о «правильном» стиле фигурных скобок и т. Д. Я не мичу с тратой времени на эту чушь.
Установите ReSharper , оставьте значения по умолчанию, делайте все, что он говорит.
Прибыль - у всех в вашей команде будет один и тот же стиль, который будет чертовски близок к рекомендациям Microsoft, отклоняясь лишь от нескольких моментов, когда стандарты Resharper отражают то, что на самом деле более широко используется в промышленности и (возможно) являются улучшениями.
Чем меньше времени ваша команда тратит на создание и ссылки на какой-то огромный документ или книгу, или на размышления о том
curly bracesили ином бессмысленности, тем больше кода они будут выполнять. ReSharper будет вводить имена и стили по мере их ввода. Выполнено. Заключительное обсуждения. Спорить не о чем. Двигаемся дальше.Тем не менее, чтение классического Code Complete поможет им понять причину, лежащую в основе стандартов кодирования, и предложит множество полезных советов по эффективной передаче смысла через код - что не может сделать документ по стандартам или программа проверки.
Если вы хотите улучшить то, что может сделать для вас resharper , добавьте StyleCop с плагином StyleCop for ReSharper. Как уже упоминалось, будет несколько незначительных конфликтов между рекомендациями MS и настройками ReSharper по умолчанию. Я бы просто пошел с ReSharper на них. Но какую бы сторону вы ни выбрали, просто сохраните результаты в конфигурационном файле ReSharper, поделитесь им со своей командой и все готово.
(Нет, я не оплачиваемая служба ReSharper, просто довольный клиент. В дополнение к множеству других функций, он решает основные проблемы стиля более эффективно, чем любой документ по стандартизации или система проверки кода, оставляя мозги для важных вещей. .)
источник