# StyleBro > Roslyn analyzers and code fixes for C#, a modern StyleCop replacement that dotnet format fixes. Install the StyleBro.Analyzers package, run `stylebro-migrate init --write` (or `stylebro-migrate --write` when coming from StyleCop), then `stylebro-migrate format`. For scripts and AI agents (`--json`, `format --files`, AGENTS.md): https://bisforboman.github.io/stylebro/agents/ ## Docs - [Home](https://bisforboman.github.io/stylebro/): Roslyn analyzers and code fixes that keep C# code tidy. - [Getting started](https://bisforboman.github.io/stylebro/getting-started/): From install to the first `dotnet format` run. - [Migrating from StyleCop](https://bisforboman.github.io/stylebro/migrating/): Switching a StyleCop-clean repository to StyleBro shouldn't reformat code StyleCop was happy with. - [Rules](https://bisforboman.github.io/stylebro/rules/): Every StyleBro rule, by area. - [Settings](https://bisforboman.github.io/stylebro/configuration/): Every `stylebro_*` setting, in `.editorconfig` under `[*.cs]`. - [Baseline](https://bisforboman.github.io/stylebro/baseline/): Turning StyleBro on in a large codebase usually reports hundreds of existing violations. - [CI](https://bisforboman.github.io/stylebro/ci/): Two checks keep a repository clean. - [Pre-commit hook](https://bisforboman.github.io/stylebro/pre-commit/): A pre-commit hook runs StyleBro on the C# files you're about to commit, so a style problem never reaches CI. - [Scripts and AI agents](https://bisforboman.github.io/stylebro/agents/): `stylebro-migrate` has three things for scripts and AI coding agents: a JSON result for every command (`--json`), a fast format of just the files an edit touched (`format --files`), and, on request (`--agents-md`), a section in the repository's `AGENTS.md` that tells an agent how to work with StyleBro. - [Modernizing](https://bisforboman.github.io/stylebro/modernizing/): `stylebro-migrate init --modernize` turns on the .NET SDK's own rules that rewrite code into newer C# and newer APIs: target-typed `new()`, collection expressions, `is not null`, file-scoped namespaces, `ArgumentNullException.ThrowIfNull`, ranges, and more. - [Versioning](https://bisforboman.github.io/stylebro/versioning/): StyleBro.Analyzers and StyleBro.Migrate share one version number. - [StyleBro vs StyleCop](https://bisforboman.github.io/stylebro/stylebro-vs-stylecop/): For a team deciding whether to switch. - [Differences from StyleCop](https://bisforboman.github.io/stylebro/differences-from-stylecop/): What changes when a project moves from StyleCop.Analyzers with its default settings to StyleBro with its preset. - [StyleCop mapping](https://bisforboman.github.io/stylebro/stylecop-mapping/): What happens to each StyleCop.Analyzers rule when a project moves to StyleBro. - [Skipped rules](https://bisforboman.github.io/stylebro/skipped-rules/): Every StyleCop.Analyzers rule StyleBro doesn't cover, with why and what it would take to revisit it, so the decisions can be picked up again later. ## Rules - [BRO1001: Members should be ordered](https://bisforboman.github.io/stylebro/rules/BRO1001/): Members of a class, struct, record or interface, and the types and namespaces of a namespace or file, should appear in a fixed order: by kind, then accessibility, then constant/static/readonly. - [BRO1002: Single-line comments should begin with a space](https://bisforboman.github.io/stylebro/rules/BRO1002/): A `//` comment should have a space between the slashes and the text. - [BRO1003: Property accessors should follow order](https://bisforboman.github.io/stylebro/rules/BRO1003/): A property's or indexer's `get` accessor comes before its `set` or `init` accessor. - [BRO1004: Event accessors should follow order](https://bisforboman.github.io/stylebro/rules/BRO1004/): An event's `add` accessor comes before its `remove` accessor. - [BRO1005: Documentation lines should begin with single space](https://bisforboman.github.io/stylebro/rules/BRO1005/): Each `///` documentation line has exactly one space before its text. - [BRO1006: Preprocessor keywords should not be preceded by a space](https://bisforboman.github.io/stylebro/rules/BRO1006/): `#if`, not `# if`. - [BRO1007: Partial elements should declare an access modifier](https://bisforboman.github.io/stylebro/rules/BRO1007/): Every part of a partial type says its accessibility. - [BRO1008: Using directives should be placed correctly](https://bisforboman.github.io/stylebro/rules/BRO1008/): Using directives go inside or outside the namespace, as `csharp_using_directive_placement` says; without that setting nothing is reported. - [BRO1101: Code should not contain empty statements](https://bisforboman.github.io/stylebro/rules/BRO1101/): A stray `;` does nothing and should be removed. - [BRO1102: Each attribute should be in its own brackets](https://bisforboman.github.io/stylebro/rules/BRO1102/): `[A, B]` should be written as `[A]` and `[B]`. - [BRO1103: Constants should be on the right-hand side of comparisons](https://bisforboman.github.io/stylebro/rules/BRO1103/): `0 == count` should be written as `count == 0`. - [BRO1104: Use default instead of a value type's default constructor](https://bisforboman.github.io/stylebro/rules/BRO1104/): `new int()` creates the default value; `default(int)` says so. - [BRO1105: Constructor initializers should be on their own line](https://bisforboman.github.io/stylebro/rules/BRO1105/): `: base(...)` and `: this(...)` go on the line after the constructor's parameters, one level deeper. - [BRO1106: Use string.Empty for empty strings](https://bisforboman.github.io/stylebro/rules/BRO1106/): `""` should be written as `string.Empty`. - [BRO1107: Split parameters should start on the line after the declaration](https://bisforboman.github.io/stylebro/rules/BRO1107/): When parameters or arguments span several lines, the first one goes on its own line too, one level deeper than the line with the opening parenthesis. - [BRO1108: Parameters should be on the same line or on separate lines](https://bisforboman.github.io/stylebro/rules/BRO1108/): Parameters and arguments are either all on one line or each on its own line. - [BRO1109: Opening parenthesis or bracket should be on the declaration line](https://bisforboman.github.io/stylebro/rules/BRO1109/): The opening parenthesis of a parameter or argument list goes on the line of the name it belongs to, not on the next line. - [BRO1110: Closing parenthesis or bracket should be on the line of the last item](https://bisforboman.github.io/stylebro/rules/BRO1110/): A parameter or argument list ends on the line where its last item ends, not with the closing parenthesis on a line of its own. - [BRO1111: Generic type constraints should be on their own line](https://bisforboman.github.io/stylebro/rules/BRO1111/): Each `where` clause starts its own line, one level deeper than the declaration. - [BRO1112: Do not use regions](https://bisforboman.github.io/stylebro/rules/BRO1112/): `#region` isn't used between members or types, or in an expression body (between the arms of a switch expression after `=>`). - [BRO1113: Regions should not be placed inside code elements](https://bisforboman.github.io/stylebro/rules/BRO1113/): `#region` isn't used inside a `{ }` block of a method, accessor, lambda or other code. - [BRO1114: Do not combine fields](https://bisforboman.github.io/stylebro/rules/BRO1114/): Every field (and event field) has a declaration of its own. - [BRO1115: Use shorthand for nullable types](https://bisforboman.github.io/stylebro/rules/BRO1115/): `int?` instead of `Nullable`. - [BRO1116: Closing parenthesis should be on line of opening parenthesis](https://bisforboman.github.io/stylebro/rules/BRO1116/): An empty parameter or argument list is written `()`. - [BRO1117: Comma should be on the same line as previous parameter](https://bisforboman.github.io/stylebro/rules/BRO1117/): A comma in a parameter or argument list ends the line of the item before it. - [BRO1118: Parameter list should follow declaration](https://bisforboman.github.io/stylebro/rules/BRO1118/): No blank line between the opening parenthesis and the first parameter or argument. - [BRO1119: Parameter should follow comma](https://bisforboman.github.io/stylebro/rules/BRO1119/): No blank line between a comma and the next parameter or argument. - [BRO1120: Comments should contain text](https://bisforboman.github.io/stylebro/rules/BRO1120/): An empty comment at the start or end of a comment (or on its own) is removed. - [BRO1121: Enum values should be on separate lines](https://bisforboman.github.io/stylebro/rules/BRO1121/): Each enum value starts its own line. - [BRO1122: Use literal suffix notation instead of casting](https://bisforboman.github.io/stylebro/rules/BRO1122/): `1L` instead of `(long)1`. - [BRO1123: Use tuple syntax](https://bisforboman.github.io/stylebro/rules/BRO1123/): `(int, string)` instead of `ValueTuple`, and `(1, "a")` instead of `new ValueTuple(1, "a")` or `ValueTuple.Create(1, "a")`. - [BRO1124: Refer to tuple elements by name](https://bisforboman.github.io/stylebro/rules/BRO1124/): `item.Count` instead of `item.Item1` when the element has a name. - [BRO1125: Use lambda syntax](https://bisforboman.github.io/stylebro/rules/BRO1125/): `(s, e) => { }` instead of `delegate (object s, EventArgs e) { }`. - [BRO1126: Using directives should be qualified](https://bisforboman.github.io/stylebro/rules/BRO1126/): A using directive inside a namespace names its namespace or type fully. - [BRO1127: Query clause should follow previous clause](https://bisforboman.github.io/stylebro/rules/BRO1127/): No blank line between the clauses of a query expression. - [BRO1128: Query clauses should be on separate lines or all on one line](https://bisforboman.github.io/stylebro/rules/BRO1128/): A query's clauses are all on one line or each on its own line. - [BRO1129: Query clause should begin on new line when previous clause spans multiple lines](https://bisforboman.github.io/stylebro/rules/BRO1129/): A clause after a clause that spans several lines starts on its own line. - [BRO1130: Query clauses spanning multiple lines should begin on own line](https://bisforboman.github.io/stylebro/rules/BRO1130/): A clause that spans several lines starts on its own line. - [BRO1131: Do not prefix calls with base unless local implementation exists](https://bisforboman.github.io/stylebro/rules/BRO1131/): `this.Reset()` instead of `base.Reset()` when the type has no `Reset` of its own. - [BRO1132: Block statements should not contain embedded comments](https://bisforboman.github.io/stylebro/rules/BRO1132/): A comment between a statement's header and the `{` of its block moves into the block. - [BRO1133: Check for null in one form](https://bisforboman.github.io/stylebro/rules/BRO1133/): Null checks are written one way in the whole codebase: `x is null` and `x is not null` (the default), or `x == null` and `x != null`. - [BRO1134: Declarations should not contain embedded comments](https://bisforboman.github.io/stylebro/rules/BRO1134/): A comment between the header of a type, namespace, member, accessor or local function and its `{` moves into the body. - [BRO1135: Integer literal suffixes should be upper case](https://bisforboman.github.io/stylebro/rules/BRO1135/): The suffix of an integer literal is upper case: `1L`, `2U`, `3UL`. - [BRO1136: A lambda's single parameter should not be in parentheses](https://bisforboman.github.io/stylebro/rules/BRO1136/): A lambda with one parameter that has no type, modifier or attribute is written `x => ...`, not `(x) => ...`. - [BRO1137: Remove a redundant 'return;' or 'yield break;'](https://bisforboman.github.io/stylebro/rules/BRO1137/): A `return;` as the last statement of a body, or a `yield break;` as the last statement of an iterator, does nothing: the body ends there anyway. - [BRO1138: A string literal should be a plain string when nothing needs more](https://bisforboman.github.io/stylebro/rules/BRO1138/): A string literal uses `$`, `@` or raw string quotes only when it needs them: `$` for interpolations, `@` for backslashes, quotes or line breaks, raw strings for quotes or several lines. - [BRO1139: Write 'else if' on one line](https://bisforboman.github.io/stylebro/rules/BRO1139/): An `if` that follows `else` on the next line, or that is the only statement of the else's block, is written as `else if`. - [BRO1140: A record with an empty body should end with ';'](https://bisforboman.github.io/stylebro/rules/BRO1140/): A record with a parameter list and nothing in its body ends with `;`: `record Point(int X, int Y);`. - [BRO1141: Object creation with an initializer: parentheses in one style](https://bisforboman.github.io/stylebro/rules/BRO1141/): An object creation with an initializer and no arguments is written without the empty parentheses (`new List { 1 }`, the default) or with them (`new List() { 1 }`). - [BRO1142: Do not combine local variables](https://bisforboman.github.io/stylebro/rules/BRO1142/): Each local variable has its own declaration: `int a = 1, b;` becomes `int a = 1;` and `int b;`. - [BRO1143: No 'else' after a branch that ends in a jump](https://bisforboman.github.io/stylebro/rules/BRO1143/): When the `if` branch ends in `return`, `throw`, `break`, `continue`, `goto` or `yield break`, the `else` is not needed: its body can follow the `if` statement. - [BRO1144: Escape identifiers that C# 14 reads as keywords](https://bisforboman.github.io/stylebro/rules/BRO1144/): C# 14 reads `field`, `extension` and `partial` as keywords in places where they used to be plain names. - [BRO1145: A class, struct or interface with an empty body should end with ';'](https://bisforboman.github.io/stylebro/rules/BRO1145/): A class, struct or interface with nothing in its body ends with `;`: `class Marker;` (C# 12). - [BRO1146: Write 'record' without 'class'](https://bisforboman.github.io/stylebro/rules/BRO1146/): A record is a class unless it says `struct`, so `record class R` is written `record R`. - [BRO1147: Remove a redundant null-forgiving operator](https://bisforboman.github.io/stylebro/rules/BRO1147/): A null-forgiving `!` on a value the compiler already knows isn't null hides nothing: removing it changes no warning. - [BRO1148: Check a nullable value type for null instead of calling HasValue](https://bisforboman.github.io/stylebro/rules/BRO1148/): `x.HasValue` becomes `x is not null` and `!x.HasValue` becomes `x is null`, or `x != null` and `x == null`, whichever form BRO1133 asks for. - [BRO1149: Merge an if into the enclosing if](https://bisforboman.github.io/stylebro/rules/BRO1149/): An `if` that is the only statement of another `if`, where neither has an `else`, joins it: `if (a) { if (b) { ... - [BRO1150: Pass the predicate to the LINQ call instead of calling Where first](https://bisforboman.github.io/stylebro/rules/BRO1150/): `source.Where(p).Count()` becomes `source.Count(p)`, and the same for `Any`, `LongCount`, `First`, `FirstOrDefault`, `Last`, `LastOrDefault`, `Single` and `SingleOrDefault`. - [BRO1151: Pass the elements, not an array, to a params parameter](https://bisforboman.github.io/stylebro/rules/BRO1151/): An array created in the call for a `params` parameter is noise: `Sum(1, new[] { 2, 3 })` becomes `Sum(1, 2, 3)`, and the compiler creates the array. - [BRO1301: Variable names should begin with a lower-case letter](https://bisforboman.github.io/stylebro/rules/BRO1301/): Local variables and query range variables are camelCase: `total`, not `Total` or `_total`. - [BRO1302: Parameter names should begin with a lower-case letter](https://bisforboman.github.io/stylebro/rules/BRO1302/): Parameters are camelCase: `count`, not `Count` or `_count`. - [BRO1303: Private field names should be camelCase](https://bisforboman.github.io/stylebro/rules/BRO1303/): Private fields are named `count`, or `_count` if you configure that style. - [BRO1304: Interface names should begin with I](https://bisforboman.github.io/stylebro/rules/BRO1304/): Interfaces are named `IShape`, not `Shape`. - [BRO1305: Type parameter names should begin with T](https://bisforboman.github.io/stylebro/rules/BRO1305/): Type parameters are named `T` or `TItem`, not `Item`. - [BRO1306: Constant, static readonly and non-private field names should be PascalCase](https://bisforboman.github.io/stylebro/rules/BRO1306/): Constants, `static readonly` fields and public or internal fields are named `MaxCount`, not `maxCount` or `_maxCount`. - [BRO1307: Field names should not begin with a prefix](https://bisforboman.github.io/stylebro/rules/BRO1307/): Fields aren't named `m_count`, `s_count` or `t_count`. - [BRO1308: Field names should not contain an underscore](https://bisforboman.github.io/stylebro/rules/BRO1308/): Fields are named `maxValue` or `MaxValue`, not `max_value` or `Max_Value`. - [BRO1309: Element names should begin with an upper-case letter](https://bisforboman.github.io/stylebro/rules/BRO1309/): Types, methods, properties, events, enum members and local functions are PascalCase: `GetTotal`, not `getTotal`. - [BRO1310: Field names should not use Hungarian notation](https://bisforboman.github.io/stylebro/rules/BRO1310/): Variable, parameter and field names don't start with a type prefix: `count`, not `iCount`. - [BRO1311: Tuple element names should use correct casing](https://bisforboman.github.io/stylebro/rules/BRO1311/): Element names in tuple types are PascalCase: `(int Count, string Name)`, not `(int count, string name)`. - [BRO1312: Namespace names should begin with an upper-case letter](https://bisforboman.github.io/stylebro/rules/BRO1312/): Every part of a namespace name is PascalCase: `MyCompany.Billing`, not `myCompany.billing`. - [BRO1313: Parameter names should match the base member](https://bisforboman.github.io/stylebro/rules/BRO1313/): A parameter of an override or an interface implementation has the name of the parameter it overrides or implements. - [BRO1314: Asynchronous method names should end with Async](https://bisforboman.github.io/stylebro/rules/BRO1314/): A method that returns `Task`, `Task`, `ValueTask`, `ValueTask` or `IAsyncEnumerable` has a name ending in `Async`, as in .NET's own APIs. - [BRO1401: Use a trailing comma in multi-line initializers](https://bisforboman.github.io/stylebro/rules/BRO1401/): The last item of a multi-line list should be followed by a comma. - [BRO1402: Attribute constructor should not use unnecessary parenthesis](https://bisforboman.github.io/stylebro/rules/BRO1402/): `[Obsolete]` instead of `[Obsolete()]`. - [BRO1403: Remove delegate parenthesis when possible](https://bisforboman.github.io/stylebro/rules/BRO1403/): `delegate { }` instead of `delegate() { }`. - [BRO1404: Access modifier should be declared](https://bisforboman.github.io/stylebro/rules/BRO1404/): Types and members say their accessibility instead of relying on the default. - [BRO1405: Statement should not use unnecessary parenthesis](https://bisforboman.github.io/stylebro/rules/BRO1405/): Parentheses around a single value, or around a whole expression where nothing binds to it, are removed. - [BRO1406: Arithmetic expressions should declare precedence](https://bisforboman.github.io/stylebro/rules/BRO1406/): An operation inside an arithmetic operation of another kind is in parentheses. - [BRO1407: Conditional expressions should declare precedence](https://bisforboman.github.io/stylebro/rules/BRO1407/): `&&` and `||` aren't mixed without parentheses, and neither are the `and` and `or` patterns. - [BRO1408: Remove a redundant base type](https://bisforboman.github.io/stylebro/rules/BRO1408/): `enum E : int` and `class C : object` name what the declaration means anyway: an enum's underlying type is `int` and a class derives from `object` unless they say otherwise. - [BRO1409: Methods of internal types should be internal, not public](https://bisforboman.github.io/stylebro/rules/BRO1409/): An ordinary method declared `public` in a type that can't be seen outside the assembly (the type, or a type it is nested in, is `internal`, `private`, `private protected` or `file`) is internal in effect; `internal` says so. - [BRO1410: Patterns should not use unnecessary parentheses](https://bisforboman.github.io/stylebro/rules/BRO1410/): Parentheses around a pattern that means the same without them are removed: `x is (> 0)`, `o is (string s)`, `case (int i):`, a pair around another pair. - [BRO1501: Opening braces should not be preceded by a blank line](https://bisforboman.github.io/stylebro/rules/BRO1501/): An opening brace on its own line directly follows the line it belongs to. - [BRO1502: Chained blocks should not be preceded by a blank line](https://bisforboman.github.io/stylebro/rules/BRO1502/): `else`, `catch` and `finally` directly follow the block they continue. - [BRO1503: Opening braces should not be followed by a blank line](https://bisforboman.github.io/stylebro/rules/BRO1503/): The first line inside a block directly follows its opening brace. - [BRO1504: Single-line comments should be preceded by a blank line](https://bisforboman.github.io/stylebro/rules/BRO1504/): A `//` comment that follows code on the line above gets a blank line before it. - [BRO1505: Elements should be separated by a blank line](https://bisforboman.github.io/stylebro/rules/BRO1505/): Members, types and namespaces are separated by a blank line; consecutive fields may stay together, unless the first spans several lines (a multi-line initializer), and so may consecutive single-line properties. - [BRO1506: Single-line comments should not be followed by a blank line](https://bisforboman.github.io/stylebro/rules/BRO1506/): A `//` comment sits directly on the code it describes. - [BRO1507: Files should not end with blank lines](https://bisforboman.github.io/stylebro/rules/BRO1507/): A file ends with its last line of code, followed by at most one line break. - [BRO1508: A block should not be on a single line](https://bisforboman.github.io/stylebro/rules/BRO1508/): A statement's block (`if`, `else`, loops, `using`, `lock`, `try`/`catch`/`finally`, a standalone `{ }`) puts its braces and each statement on their own lines. - [BRO1509: An element should not be on a single line](https://bisforboman.github.io/stylebro/rules/BRO1509/): Types, namespaces, method bodies (including constructors, operators and local functions) and accessor lists with bodies put their braces and contents on separate lines. - [BRO1510: Accessors should all be single-line or all multi-line](https://bisforboman.github.io/stylebro/rules/BRO1510/): When every accessor of a property, indexer or event has a block body, they are laid out the same way: each on one line, or each over several lines. - [BRO1511: Element documentation headers should not be followed by blank line](https://bisforboman.github.io/stylebro/rules/BRO1511/): A documentation comment sits directly on the element it documents. - [BRO1512: While-do footer should not be preceded by blank line](https://bisforboman.github.io/stylebro/rules/BRO1512/): The `while` of a `do ... - [BRO1513: Element documentation header should be preceded by blank line](https://bisforboman.github.io/stylebro/rules/BRO1513/): A documentation comment is separated from the code above it by a blank line. - [BRO1514: Braces should not be omitted](https://bisforboman.github.io/stylebro/rules/BRO1514/): The child statement of an `if`, `else`, `for`, `foreach`, `while`, `do`, `using`, `lock` or `fixed` statement is a block. - [BRO1515: Braces should not be omitted from multi-line child statement](https://bisforboman.github.io/stylebro/rules/BRO1515/): A child statement that spans several lines is a block. - [BRO1516: Use braces consistently](https://bisforboman.github.io/stylebro/rules/BRO1516/): When one clause of an `if`/`else` chain has braces, all of them do. - [BRO1517: Code should not contain multiple blank lines in a row](https://bisforboman.github.io/stylebro/rules/BRO1517/): Two or more blank lines in a row become one. - [BRO1518: Closing braces should not be preceded by blank line](https://bisforboman.github.io/stylebro/rules/BRO1518/): A closing brace directly follows the code above it. - [BRO1519: Closing brace should be followed by blank line](https://bisforboman.github.io/stylebro/rules/BRO1519/): A statement after a block is separated from it by a blank line. - [BRO1520: Place the operator consistently when an expression wraps](https://bisforboman.github.io/stylebro/rules/BRO1520/): When the line breaks next to a binary operator (`&&`, `||`, `+`, `??`, `==`, ...) or the conditional operator's `?` or `:`, the operator goes at the beginning of the continuation line (the default) or at the end of the broken line. - [BRO1521: Place '=>' consistently when an expression body wraps](https://bisforboman.github.io/stylebro/rules/BRO1521/): When the line breaks next to the `=>` of an expression-bodied member (method, property, accessor, operator, local function, ...) or a switch expression arm, the `=>` goes at the end of the broken line (the default) or at the beginning of the continuation line. - [BRO1522: Place '=' consistently when an assignment wraps](https://bisforboman.github.io/stylebro/rules/BRO1522/): When the line breaks next to the `=` of an assignment (also compound ones like `+=` and `??=`) or an initializer (fields, properties, locals, parameter defaults, enum members), the `=` goes at the end of the broken line (the default) or at the beginning of the continuation line. - [BRO1523: Each call of a split call chain starts its own line](https://bisforboman.github.io/stylebro/rules/BRO1523/): When a member access chain is split over several lines (a `.` or `?.` of the chain starts a line), every call after the chain's first line starts its own line. - [BRO1524: A split conditional expression has the condition, '?' and ':' parts on their own lines](https://bisforboman.github.io/stylebro/rules/BRO1524/): A conditional expression (`c ? a : b`) is on one line, or the condition, the `? a` part and the `: b` part each start their own line. - [BRO1525: Attributes should not be followed by a blank line](https://bisforboman.github.io/stylebro/rules/BRO1525/): No blank line between an attribute list and the element it applies to, or between two attribute lists of the same element. - [BRO1526: Blank line between switch sections](https://bisforboman.github.io/stylebro/rules/BRO1526/): The sections of a `switch` statement are separated by a blank line, or (if you configure it) not. - [BRO1527: Auto-accessors should be on one line](https://bisforboman.github.io/stylebro/rules/BRO1527/): A property or indexer whose accessors are all auto-accessors (`get;`, `set;`, `init;`, also with a modifier such as `private set;`) goes on one line: `public int Simple { get; set; }`. - [BRO1601: Overrides and implementations should inherit their documentation](https://bisforboman.github.io/stylebro/rules/BRO1601/): An override or interface implementation without documentation gets `/// `, which takes the documentation from the member it overrides or implements. - [BRO1602: Single-line comments should not use documentation style slashes](https://bisforboman.github.io/stylebro/rules/BRO1602/): A comment that doesn't document a type or member uses `//`, not `///`. - [BRO1603: Documentation text should end with a period](https://bisforboman.github.io/stylebro/rules/BRO1603/): Summary, remarks, parameter, type parameter, return value, value and exception text are sentences and end with a period. - [BRO1604: Property summary documentation should match accessors](https://bisforboman.github.io/stylebro/rules/BRO1604/): A property's summary begins with the words its accessors call for: `Gets or sets`, `Gets` or `Sets` (with an `init` accessor: `Gets or initializes`, `Gets or sets` or just `Gets`, and `Initializes`), followed by `a value indicating whether` for a `bool`. - [BRO1605: Property summary documentation should omit accessor with restricted access](https://bisforboman.github.io/stylebro/rules/BRO1605/): A property whose setter is private or internal is documented as `Gets`, not `Gets or sets`: other code can't set it. - [BRO1606: Constructor summary documentation should begin with standard text](https://bisforboman.github.io/stylebro/rules/BRO1606/): A constructor's summary begins with `Initializes a new instance of the class.` (or `struct`), and a static constructor's with `Initializes static members of the class.`. - [BRO1607: Destructor summary documentation should begin with standard text](https://bisforboman.github.io/stylebro/rules/BRO1607/): A finalizer's summary begins with `Finalizes an instance of the class.`. - [BRO1608: Void return value should not be documented](https://bisforboman.github.io/stylebro/rules/BRO1608/): A method or delegate that returns `void` has no `` documentation. - [BRO1609: Do not use placeholder elements](https://bisforboman.github.io/stylebro/rules/BRO1609/): Documentation doesn't contain `` elements. - [BRO1610: Documentation text should not be empty](https://bisforboman.github.io/stylebro/rules/BRO1610/): An empty `` element is removed. - [BRO1611: Element parameter documentation should match element parameters](https://bisforboman.github.io/stylebro/rules/BRO1611/): `` tags document the parameters that exist, in their order. - [BRO1612: Element parameter documentation should declare parameter name](https://bisforboman.github.io/stylebro/rules/BRO1612/): Every `` tag says which parameter it documents. - [BRO1613: Generic type parameter documentation should match type parameters](https://bisforboman.github.io/stylebro/rules/BRO1613/): `` tags document the type parameters that exist, in their order. - [BRO1614: Generic type parameter documentation should declare parameter name](https://bisforboman.github.io/stylebro/rules/BRO1614/): Every `` tag says which type parameter it documents. - [BRO1615: File should have the XML copyright header](https://bisforboman.github.io/stylebro/rules/BRO1615/): Every file starts with StyleCop's XML header: a `` tag naming the file and the company, around the copyright text. - [BRO1616: Write the summary's tags consistently on their own lines or on the text's line](https://bisforboman.github.io/stylebro/rules/BRO1616/): A `` has its tags on lines of their own (the default), or, with `stylebro_summary_layout = single_line_when_fits`, is written on one line when its text is one line and the result fits within `max_line_length`. - [BRO1617: Write a cref's type arguments in braces](https://bisforboman.github.io/stylebro/rules/BRO1617/): A `cref` names a generic type or member with braces, `cref="List{T}"`, not with escaped angle brackets, `cref="List<T>"`. - [BRO1618: Write a C# keyword in documentation as <see langword="..."/>](https://bisforboman.github.io/stylebro/rules/BRO1618/): A C# keyword alone in ``, such as `null`, `true` or `static`, is written ``. - [BRO1619: Put the documentation elements in the standard order](https://bisforboman.github.io/stylebro/rules/BRO1619/): The top-level elements of a documentation comment come in this order: ``, ``, ``, ``, ``, ``, ``, ``, ``.