6.2.12.7. CodingStyleΒΆ
Checks for coding style issues
Nested Rules
Use Allman bracing style |
|
Start functions and methods with an upper-case letter |
|
Use only certain extensions for file names |
|
Use only certain characters for file names |
|
You have to use the specified sort of line breaks |
|
A file should not contain more than N lines of code |
|
Do not put more than one statement in a line |
|
The length of a line of code must not exceed the character limit |
|
All #else, #elif and #endif preprocessor directives shall be aligned with the same amount of spaces as the #if or #ifdef directive to which they are related |
|
Naming Conventions |
|
Avoid blank lines after { and before } |
|
Do not use more than one consecutive underscore in a macro |
|
Do not use identifiers consisting of just a single character |
|
Do not use tabs |
|
Do not use trailing whitespace |
|
No whitespace before or after a member selection |
|
Whitespace rule in declarations before (or after) * or & |
|
No whitespace rule in declarations between identifier and * or & |
|
No whitespace after an unary operator |
|
Name a source_file for a type defined in it |
|
At assignment sites, the strong types of left and right side should match |
|
Report units with high number of included files |
|
Use Whitesmith bracing style |
|
There must be exactly one whitespace on both sides of an operator |
Options
Setting an option for this rule means setting the default for all nested rules.
This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity
The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions
This rule has no individual options.