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

Які стандарти кодування, на вашу думку, важливі для проектів .NET / C #? Це може бути чим завгодно, якщо мати справу з фігурними дужками та міжряддями та педантизмом. Або це можуть бути більш фундаментальні питання, такі як, яких просторів імен у .NET Framework слід уникати, кращі практики з файлами конфігурацій тощо.

Постарайтеся уникати створення публікації, яка є просто наслідком для іншого. Наприклад, було б непогано мати один пост з акцентом на фігурні брекети. Нам не потрібно два, щоб підтримувати один стиль проти іншого. Ідея полягає не в тому, щоб голосувати за стандарт вашого улюбленця, а навпаки, щоб чітко визначити, про що слід думати, створюючи стандарти.

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

Якщо ви хочете старішу версію для 1.1, спробуйте тут .

Як вони кажуть, я не обов'язково дотримуюся цього "Т". Однак, коли ви сумніваєтесь, це найкраще місце, щоб почати узгоджуватись із чинними рамками .NET, що полегшує всім, незалежно від того, чи є вони новими для вашого конкретного проекту чи ні.

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

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

Рекомендації від Microsoft:

• .NET - http://msdn.microsoft.com/en-us/library/czefa0ke.aspx
• C # - http://blogs.msdn.com/brada/articles/361363.aspx

Ми прийняли це в нашому офісі. Його написав Ланс Хант, і він досить вичерпний:

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

Почніть з FxCop . Він розповість про порушення кращих практик у вашому існуючому коді.

Я намагаюся підібрати загальний набір стилів з різних джерел. Деякі, про які раніше не говорилося:

• документація з Керівних принципів кодування C # - останнє оновлення 2010 року
• Стан кодування IDesign C # - останнє оновлення у 2008 році
• Philips Healthcare - Стандарт кодування C # - останнє оновлення у 2009 році
• Довідник Encodo C # - останнє оновлення у 2009 році

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

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

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

Методи повинні бути короткими

Більшість методів повинні використовувати більшість полів у класі.

Добре виберіть свої імена.

Наприклад , читати Чистий код книги

Я використовую наступні програми для підтримки стандарту кодування, крім правил camelback, назви методу тощо.

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 чи будь-яким іншим), щоб ви могли бачити, які файли містять код вікна, а які - звичайні об'єкти.

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

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

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

Попередження: Прагматизм нижче - начебто, це питання викликає дискусію про "правильний" фігурний стиль фігури та ін. Я не змиряюся з тим, щоб витрачати час на ці дурниці.

1. Встановіть ReSharper , залиште параметри за замовчуванням, виконайте все, що там сказано.

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

Чим менше часу ваша команда витрачає на створення та посилання на якийсь жартівливий документ чи книгу, або на хитрощі про curly bracesта інші нежиттю, тим більше кодування вони будуть виконані. ReSharper застосовуватиме ім’я та стиль під час їх введення. Зроблено. Кінець дискусії. Не залишається нічого сперечатися. Жити далі.

Однак, читання класичного Code Complete допоможе їм зрозуміти обґрунтування стандартів кодування та запропонує багато чудових покажчиків щодо ефективного передавання значення за допомогою коду - те, що стандартний документ чи програма перевірки не можуть зробити.

Якщо ви хочете підвищує , що ReSharper може зробити для вас, додайте StyleCop з StyleCop для ReSharper плагіна. Як уже згадувалося, між керівництвом щодо MS та ReSharper за замовчуванням буде кілька незначних конфліктів. Я просто пішов би з ReSharper на ці. Але незалежно від того, яку б сторону ви взяли, просто збережіть результати у конфігураційному файлі ReSharper, поділіться ними з усією командою і будьте готові.

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