Есть ли какие-либо предложения по разработке стандарта кодирования/передовой практики 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

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

Answer 3

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

Answer 4

IDesign имеет документ стандартов стандарта C#, который обычно используется. Также смотрите Framework Design Guidelines 2nd Ed.

Answer 5

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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

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

Answer 11

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

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

В конечном счете это будет иметь опцию рефакторинга для очистки коды.

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

Answer 12

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

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

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

Answer 13

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

Другим источником может быть Professional C#/VB .NET Coding Guidelines.

Answer 14

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

C# Coding Standard

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

Answer 15

Я большой поклонник книги Франческо Балена «Practical Guidelines and Best Practices for VB and C# Developers».

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

Answer 16

Посмотрите: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx.

Answer 17

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

m_strName = p_strName;

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

Answer 18

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

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

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

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

Answer 19

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

Answer 20

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

Answer 21

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

Answer 22

Я также следую за Решаром. Также руководство линия упомянута на блоге Скотта Гатри 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 23

В коде я пишу, я обычно следую .NET Framework Design Guidelines для публично открытых интерфейсов API и Mono Coding Guidelines для частного корпуса члена и отступа. 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 ;-)

Answer 24

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

Answer 25

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

Answer 26

SSW Rules

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