Lines Matching full:should

38 These guidelines should be followed for all new code.
89 files, for the most part, should be sorted.
111 In userspace, functions local to one source module should be declared
113 This should not be done in the kernel since it makes it impossible
123 Prototypes should not have variable names associated with the types; i.e.,
139 There should be no space between the function name and the argument list.
155 Macros are capitalized and parenthesized, and should avoid side-effects.
166 Any final statement-terminating semicolon should be
177 those variables should use identifiers beginning with two underscores.
201 Major structures should be declared at the top of the file in which they
204 Use of the structures should be by separate declarations and should be
240  * All major routines should have a comment briefly describing what
241  * they do.  The comment before the "main" routine should describe
253 should be used to parse options.
254 Options should be sorted in the
258 Elements in a switch statement that cascade should have a FALLTHROUGH comment.
259 Numerical arguments should be checked for accuracy.
319 All code should fit in 80 columns.
371 Exits should be 0 on success, or non-zero for errors.
380 The function type should be on a line by itself
433 flag should be used to verify that the compiler does not generate
481 Global flags set inside signal handlers should be of type
510 should not have their return values cast to any pointer type.
529 Variable numbers of arguments should look like this:
551 Usage statements should take the same form as the synopsis in manual pages.
565 If numbers are used as options, they should be placed first,
581 New core kernel code should be reasonably compliant with the style guides.
583 relaxed but at a minimum should be internally consistent with their style.
585 Whenever possible, code should be run through a code checker
589 Since lint has been removed, the only lint-style comment that should