Lines Matching full:should
39 messages, should not be broken up over multiple lines despite this rule.
63 Single-line comments should be consistently either C or C++ within a file.
64 Multi-line comments should also be consistently either C or C++, but may differ
67 The copyright header should be a multi-line comment, with the first
92 that should be on the same line as the word
94 You should not insert a new copyright line between an old
96 Instead, you should insert a new copyright phrase after
109 new copyright assertions should be added last.
112 lines should only be added when making substantial changes to the file,
118 Version control system ID tags should only exist once in a file
121 from elsewhere should be maintained, including, where applicable, multiple IDs
160 The remaining kernel headers should be sorted alphabetically.
185 which should be sorted alphabetically by name.
233 Any final statement-terminating semicolon should be
253 This comment should be used only for (subjectively) long regions, regions
257 The comment should be separated from the
262 For short conditionally compiled regions, a closing comment should not be
267 should match the expression used in the corresponding
275 should match the inverse of the expression(s) used in the preceding
314 New code should use the former, and old code should be converted to
318 Like white-space commits, care should be taken in making
329 New code should use
341 Userspace code should include
343 while kernel code should include
374 You should use one tab only if it suffices to align at least 90% of
377 should be separated by a single space.
379 Major structures should be declared at the top of the file in which they
382 Use of the structures should be by separate declarations
383 and should be
446 local to one source module should be declared
451 Function prototypes should be listed in a logical order, preferably
497 * All major routines should have a comment briefly describing what
498 * they do. The comment before the "main" routine should describe
511 should be used to parse options.
513 should be sorted in the
523 statement that execute some code and then cascade to the next case should have a
526 Numerical arguments should be checked for accuracy.
567 Usage within a function should be consistent.
669 Exits should be 0 on success, or 1 on failure.
678 The function type should be on a line by itself
680 The opening brace of the function body should be
694 Calls to complicated functions should be avoided when initializing variables.
774 should not have their return values cast
779 statements should be enclosed in parentheses.
803 Variable numbers of arguments should look like this:
823 Functions should have local variable declarations first, followed by one
825 If no local variables are declared, the first line should be a statement.
829 Such lines should be removed when signficant changes are made to the code.
840 Usage statements should look like the manual pages
842 The usage statement should be structured in the following order:
859 listed in the order they should be specified on the command line.
862 any optional arguments should be listed,
863 listed in the order they should be specified,
884 Note that the manual page options description should list the options in
887 The alphabetical ordering should take into account the case ordering
890 New core kernel code should be reasonably compliant with the
894 relaxed but at a minimum should be internally consistent with their style.
904 Whenever possible, code should be run through a code checker
909 New code should use
917 should only be used in frequently executed code when it makes the code
921 When using branch prediction hints, atypical error conditions should use