StyleCop - молодша сестра або брат (кому як зручніше) інструменту FxCop, про який я писав у попередній частині. Але, на відміну від FxCop, StyleCop володіє великою кількістю додаткових правил, пов'язаних з оформленням коду.
Після установки StyleCop в Visual Studio з'являється додатковий функціонал:
Всі правила діляться на кілька груп:
Включити або вимкнути правила можна у вікні властивостей:
Розглянемо основні правила, з якими стикаються розробники.
Documentation rules
* MustBeDocumented - все елементи (методи, змінні і т.д. повинні бути задокументовані, включаючи приватні члени).
SA1625: ElementDocumentationMustNotBeCopiedAndPasted - опис змінних не повинно збігатися:
SA1633: FileMustHaveHeader - всі файли повинні містити шапку:
Причому назва файлу повинна збігатися зі значенням в file (SA1638: FileHeaderFileNameDocumentationMustMatchFileName).
SA1642: ConstructorSummaryDocumentationMustBeginWithStandardText - опис конструктора повинно відповідати шаблоном "Initializes a new instance of the class.":
Те ж саме для деструкторов (SA1643: DestructorSummaryDocumentationMustBeginWithStandardText).
Layout rules
SA1500: CurlyBracketsForMultiLineStatementsMustNotShareLine - дужки повинні розташовуватися на окремих лініях, тобто замість
Те ж саме для коду всередині методів (SA1507: CodeMustNotContainMultipleBlankLinesInARow).
Решта правила також стосуються, в основному, необхідності видалення порожніх ліній.
Maintainability rules
SA1119: StatementMustNotUseUnnecessaryParenthesis - код не повинен містити зайві дужки:
Всі методи і властивості повинні мати явно вказаний ідентифікатор доступу (SA1400: AccessModifierMustBeDeclared).
Для математичних виразів необхідно чітко вказувати порядок виконання за допомогою додаткових дужок (SA1407: ArithmeticExpressionsMustDeclarePrecedence). Тобто такий код:
потрібно переписати таким чином:
Код не повинен містити не використовується код (SA1409: RemoveUnnecessaryCode):
Naming rules
Якщо коротко, то назви методів, класів повинні починатися з великої літери (SA1300: ElementMustBeginWithUpperCaseLetter), а інтерфейси - з букви "I" (SA1302: InterfaceNamesMustBeginWithI). Не можна використовувати префікси m_ або s_ в іменах змінних (SA1308: VariableNamesMustNotBePrefixed), а також не можна використовувати символ підкреслення (SA1309: FieldNamesMustNotBeginWithUnderscore, SA1310: FieldNamesMustNotContainUnderscore).
Ordering rules
Одне з найбільш обговорюваних правил - все usings повинні розміщуватися всередині namespaces.
Якщо говорити про причини такого правила, то вона пов'язана з можливими труднощами при роботі з аліасами.
Наприклад, такий код успішно скомпілюється:
Але тут незрозуміло, який з Guid буде використовуватися.
Такий код викличе попередження CS0576: Namespace 'Microsoft.Sample' contains a definition conflicting with alias 'Guid':
Але допоможе уникнути плутанини в найменуваннях.
Всі елементи повинні розташовуватися в потрібному порядку всередині вихідного файлу (SA1201: ElementsMustAppearInTheCorrectOrder):
- Extern Alias Directives
- Using Directives
- Namespaces
- Delegates
- Enums
- Interfaces
- Structs
- Classes
У класі, структурі, інтерфейсі порядок повинен бути такий:
Елементи повинні бути відсортовані про рівнем доступу (SA1202: ElementsMustBeOrderedByAccess):
Все usings повинні бути відсортовані, а невикористовувані - видалені (SA1210: UsingDirectivesMustBeOrderedAlphabeticallyByNamespace).
Readability rules
Необхідно використовувати префікс this для доступу до членів класів (SA1101: PrefixLocalCallsWithThis). Решта правила такого типу пов'язані з позиціонуванням параметрів, регіонів, виразів і т.д.
Необхідно використовувати string.Empty замість порожнього рядка (SA1122: UseStringEmptyForEmptyStrings).
Необхідно використовувати вбудовані аліаси (int, string замість Int32, String і т.д.) (SA1121: UseBuiltInTypeAlias).
Spacing rules
У цій групі багато правил, пов'язаних з табуляцією і прогалинами. Якщо коротко, то код не повинен містити зайві прогалини, а використання табуляції заборонено (SA1027: TabsMustNotBeUsed).
Відключення правил в коді
Для того, щоб не перевіряти якийсь код на певне правило, можна скористатися спеціальним атрибутом:
- Rule Category - простір імен StyleCop, в якому оголошено. Наприклад, Microsoft.StyleCop.CSharp.DocumentationRules;
- Rule Id -Ідентифікатор правила в форматі shortname: longname. Наприклад, SA1600: ElementsMustBeDocumented;
- Justification - текст, який буде використаний для пояснення причини, чому те чи інше правило було пропущено.
Якщо ви хочете заборонити всі правила в заданому просторі імен, то це можна зробити таким чином:
StyleCop for Resharper
Крім, власне, StyleCop, є ще один продукт під назвою StyleCop for Resharper. Як неважко здогадатися з назви, цей інструмент служить для інтеграції правил з Resharper.
В цілому, використання StyleCop робить ваш код красивим і простим з точки зору читабельності і оформлення, що дуже важливо для послідовної підтримки.