Lines Matching refs:and
5 linux kernel. Coding style is very personal, and I won't _force_ my
7 able to maintain, and I'd prefer it for most other things too. Please
11 and NOT read it. Burn them, it's a great symbolic gesture.
18 Tabs are 8 characters, and thus indentations are also 8 characters.
20 characters deep, and that is akin to trying to define the value of PI to
24 a block of control starts and ends. Especially when you've been looking
29 the code move too far to the right, and makes it hard to read on a
31 more than 3 levels of indentation, you're screwed anyway, and should fix
34 In short, 8-char indents make things easier to read, and have the added
39 to align the "switch" and its subordinate "case" labels in the same column
68 Outside of comments, documentation and except in Kconfig, spaces are never
69 used for indentation, and the above example is deliberately broken.
71 Get a decent editor and don't leave whitespace at the end of lines.
74 Chapter 2: Breaking long lines and strings
76 Coding style is all about readability and maintainability using commonly
79 The limit on the length of lines is 80 columns and this is a strongly
83 exceeding 80 columns significantly increases readability and does not hide
84 information. Descendants are always substantially shorter than the parent and
90 Chapter 3: Placing Braces and Spaces
95 shown to us by the prophets Kernighan and Ritchie, is to put the opening
96 brace last on the line, and put the closing brace first, thusly:
126 (a) K&R are _right_ and (b) K&R are right. Besides, functions are
138 and
161 and
182 notable exceptions are sizeof, typeof, alignof, and __attribute__, which look
183 somewhat like functions (and are usually used with parentheses in Linux,
201 preferred use of '*' is adjacent to the data name or function name and not
208 Use one space around (on each side of) most binary and ternary operators,
225 and no space around the '.' and "->" structure member operators.
234 Git will warn you about patches that introduce trailing whitespace, and can
242 C is a Spartan language, and so should your naming be. Unlike Modula-2
243 and Pascal programmers, C programmers do not use cute names like
245 variable "tmp", which is much easier to write, and not the least more
258 notation) is brain damaged - the compiler knows the types anyway and can
259 check those, and it only confuses the programmer. No wonder MicroSoft
262 LOCAL variable names should be short, and to the point. If you have
276 It's a _mistake_ to use typedef for structures and pointers. When you see a
296 NOTE! Opaqueness and "accessor functions" are not good in themselves.
312 might be an "unsigned int" and under other configurations might be
313 "unsigned long", then by all means go ahead and use a typedef.
321 Although it would only take a short amount of time for the eyes and
325 Therefore, the Linux-specific 'u8/u16/u32/u64' types and their
336 require C99 types and cannot use the 'u32' form above. Thus, we
337 use __u32 and similar types in all structures which are shared
349 Functions should be short and sweet, and do just one thing. They should
351 as we all know), and do one thing and do that well.
354 complexity and indentation level of that function. So, if you have a
359 However, if you have a complex function, and you suspect that a
364 it's performance-critical, and it will probably do a better job of it
369 function, and split it into smaller pieces. A human brain can
371 and it gets confused. You know you're brilliant, but maybe you'd like
395 locations and some common work such as cleanup has to be done. If there is no
400 using GW-BASIC names like "err1:" and "err2:". Also don't name them after the
405 - unconditional statements are easier to understand and follow
441 fix for this is to split it up into two error labels "err_bar:" and "err_foo:".
448 write the code so that the _working_ is obvious, and it's a waste of
457 of the function, telling people what it does, and possibly WHY it does
461 See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc
475 * with beginning and ending almost-blank lines.
478 For files in net/ and drivers/net/ the preferred style for long (multi-line)
481 /* The preferred comment style for files in net/ and drivers/net
498 you, and you've noticed that yes, it does do that, but the defaults it
529 (when (and filename
550 "indent" has a lot of options, and especially when it comes to comment
586 environment they are created and destroyed in should always have
587 reference counts. In the kernel, garbage collection doesn't exist (and
588 outside the kernel garbage collection is slow and inefficient), which
591 Reference counting means that you can avoid locking, and allows multiple
592 users to have access to the data structure in parallel - and not having
598 counting is a memory management technique. Usually both are needed, and
603 the number of subclass users, and decrements the global count just once
607 memory management ("struct mm_struct": mm_users and mm_count), and in
608 filesystem code ("struct super_block": s_count and s_active).
610 Remember: if another thread can find your data structure, and you don't
614 Chapter 12: Macros, Enums and RTL
616 Names of macros defining constants and labels in enums are capitalized.
653 code and it's prone to breakage from seemingly innocent changes.
687 concise, clear, and unambiguous.
691 Printing numbers in parentheses (%d) adds no value and should be avoided.
695 and driver, and are tagged with the right level: dev_err(), dev_warn(),
696 dev_info(), and so forth. For messages that aren't associated with a
700 Coming up with good debugging messages can be quite a challenge; and once
706 and a related convention uses VERBOSE_DEBUG to add dev_vdbg() messages to
719 kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
727 The alternative form where struct name is spelled out hurts readability and
744 and return NULL if that occurred.
754 icache footprint for the CPU and simply because there is less memory
761 a parameter is known to be a compiletime constant, and as a result of this
766 Often people argue that adding inline to functions that are static and used
769 help, and the maintenance issue of removing the inline when a second user
774 Chapter 16: Function return values and names
776 Functions can return values of many different kinds, and one of the
784 between integers and booleans then the compiler would find these mistakes
792 For example, "add work" is a command, and the add_work() function returns 0
794 a predicate, and the pci_dev_present() function returns 1 if it succeeds in
797 All EXPORTed functions must respect this convention, and so should all
821 There are also min() and max() macros that do strict type checking if you
826 Chapter 18: Editor modelines and other cruft
847 editor configurations, and your source files should not override them. This
848 includes markers for indentation and mode configuration. People may use their
858 and should poke hardware from C when possible.
870 do so, though, and doing so unnecessarily can limit optimization.
874 string, and end each string except the last with \n\t to properly indent the
885 files; doing so makes code harder to read and logic harder to follow. Instead,
887 files, providing no-op stub versions in the #else case, and then call those
894 out part or all of the expression into a separate helper function and apply the
898 particular configuration, and the compiler would warn about its definition
904 symbol into a C boolean expression, and use it in a normal C conditional:
910 The compiler will constant-fold the conditional away, and include or exclude
913 inside the block, and check it for correctness (syntax, types, symbol
929 by Brian W. Kernighan and Dennis M. Ritchie.
935 by Brian W. Kernighan and Rob Pike.
940 GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
941 gcc internals and indent, all available from http://www.gnu.org/manual/