iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: checkpatch: add multiline, do/while, and multiple-assignment messages

Browse Source 
Added and documented 3 new message types:
- MULTILINE_DEREFERENCE
- SINGLE_STATEMENT_DO_WHILE_MACRO
- MULTIPLE_ASSIGNMENTS

Signed-off-by: Utkarsh Verma <utkarshverma294@gmail.com>
Link: https://lore.kernel.org/r/20210925163852.12096-1-utkarshverma294@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Utkarsh Verma 2021-09-25 22:08:52 +05:30 committed by Jonathan Corbet
parent cbb817fc2e
commit 250a0a5ba9
1 changed files with 43 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
Documentation/dev-tools/checkpatch.rst
View File

@ -716,6 +716,33 @@ Indentation and Line Breaks
See: https://lore.kernel.org/lkml/20120203052727.GA15035@leaf/ See: https://lore.kernel.org/lkml/20120203052727.GA15035@leaf/
**MULTILINE_DEREFERENCE**
A single dereferencing identifier spanned on multiple lines like::
struct_identifier->member[index].
member = <foo>;
is generally hard to follow. It can easily lead to typos and so makes
the code vulnerable to bugs.
If fixing the multiple line dereferencing leads to an 80 column
violation, then either rewrite the code in a more simple way or if the
starting part of the dereferencing identifier is the same and used at
multiple places then store it in a temporary variable, and use that
temporary variable only at all the places. For example, if there are
two dereferencing identifiers::
member1->member2->member3.foo1;
member1->member2->member3.foo2;
then store the member1->member2->member3 part in a temporary variable.
It not only helps to avoid the 80 column violation but also reduces
the program size by removing the unnecessary dereferences.
But if none of the above methods work then ignore the 80 column
violation because it is much easier to read a dereferencing identifier
on a single line.
**TRAILING_STATEMENTS** **TRAILING_STATEMENTS**
Trailing statements (for example after any conditional) should be Trailing statements (for example after any conditional) should be
on the next line. on the next line.
@ -872,6 +899,17 @@ Macros, Attributes and Symbols
See: https://lore.kernel.org/lkml/1399671106.2912.21.camel@joe-AO725/ See: https://lore.kernel.org/lkml/1399671106.2912.21.camel@joe-AO725/
**SINGLE_STATEMENT_DO_WHILE_MACRO**
For the multi-statement macros, it is necessary to use the do-while
loop to avoid unpredictable code paths. The do-while loop helps to
group the multiple statements into a single one so that a
function-like macro can be used as a function only.
But for the single statement macros, it is unnecessary to use the
do-while loop. Although the code is syntactically correct but using
the do-while loop is redundant. So remove the do-while loop for single
statement macros.
**WEAK_DECLARATION** **WEAK_DECLARATION**
Using weak declarations like __attribute__((weak)) or __weak Using weak declarations like __attribute__((weak)) or __weak
can have unintended link defects. Avoid using them. can have unintended link defects. Avoid using them.
@ -947,6 +985,11 @@ Functions and Variables
Your compiler (or rather your loader) automatically does Your compiler (or rather your loader) automatically does
it for you. it for you.
**MULTIPLE_ASSIGNMENTS**
Multiple assignments on a single line makes the code unnecessarily
complicated. So on a single line assign value to a single variable
only, this makes the code more readable and helps avoid typos.
**RETURN_PARENTHESES** **RETURN_PARENTHESES**
return is not a function and as such doesn't need parentheses:: return is not a function and as such doesn't need parentheses::