16f6c0aecf
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
50 lines
1.4 KiB
Plaintext
50 lines
1.4 KiB
Plaintext
== Why is this an issue?
|
|
|
|
Shared naming conventions allow teams to collaborate efficiently. This rule checks whether or not method and property names are PascalCased. To reduce noise, two consecutive upper case characters are allowed unless they form the whole name. So, ``++MyXMethod++`` is compliant, but ``++XM++`` on its own is not.
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,csharp]
|
|
----
|
|
public int doSomething() {...}
|
|
----
|
|
|
|
=== Compliant solution
|
|
|
|
[source,csharp]
|
|
----
|
|
public int DoSomething() {...}
|
|
----
|
|
|
|
=== Exceptions
|
|
|
|
* The rule ignores members in types that are marked with ``++ComImportAttribute++`` or ``++InterfaceTypeAttribute++``.
|
|
* The rule ignores ``++extern++`` methods.
|
|
* The rule allows for two-letter acronyms in which both letters are capitalized, as shown in the following identifier: ``++ExecuteOnUIThread++``.
|
|
* Furthermore, when ``++'_'++`` character is found in a name, the camel casing is not enforced.
|
|
|
|
[source,csharp]
|
|
----
|
|
void My_method(){...} // valid
|
|
void My_method_(){...} // invalid, leading and trailing underscores are reported
|
|
----
|
|
|
|
== Resources
|
|
|
|
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[]
|