51369b610e
When an include is not surrounded by empty lines, its content is inlined on the same line as the adjacent content. That can lead to broken tags and other display issues. This PR fixes all such includes and introduces a validation step that forbids introducing the same problem again.
56 lines
1.3 KiB
Plaintext
56 lines
1.3 KiB
Plaintext
== Why is this an issue?
|
|
|
|
Shared naming conventions allow teams to collaborate efficiently.
|
|
|
|
This rule raises an issue when a method or a property name is not PascalCased.
|
|
|
|
For example, the method
|
|
|
|
[source,csharp]
|
|
----
|
|
public int doSomething() {...} // Noncompliant
|
|
----
|
|
|
|
should be renamed to
|
|
|
|
[source,csharp]
|
|
----
|
|
public int DoSomething() {...}
|
|
----
|
|
|
|
=== Exceptions
|
|
|
|
* The rule ignores members in types marked with `ComImportAttribute` or `InterfaceTypeAttribute`.
|
|
* The rule ignores `extern` methods.
|
|
* To reduce noise, two consecutive upper-case characters are allowed unless they form the full name. So, `MyXMethod` is compliant, but `XM` is not.
|
|
* The camel casing is not enforced when a name contains the ``++'_'++`` character.
|
|
|
|
[source,csharp]
|
|
----
|
|
void My_method_(){...} // Noncompliant, leading and trailing underscores are reported
|
|
|
|
void My_method(){...} // Compliant by exception
|
|
----
|
|
|
|
== Resources
|
|
|
|
=== Documentation
|
|
|
|
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions[Microsoft Capitalization Conventions]
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
include::../message.adoc[]
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
include::../comments-and-links.adoc[]
|
|
|
|
endif::env-github,rspecator-view[]
|