Lines Matching +full:broken +full:- +full:turn +full:- +full:around
19 --------------
31 Now, some people will claim that having 8-character indentations makes
33 80-character terminal screen. The answer to that is that if you need
37 In short, 8-char indents make things easier to read, and have the added
43 instead of ``double-indenting`` the ``case`` labels. E.g.:
45 .. code-block:: c
67 .. code-block:: c
74 .. code-block:: c
81 .. code-block:: c
93 used for indentation, and the above example is deliberately broken.
99 ----------------------------------
106 Statements longer than 80 columns should be broken into sensible chunks,
116 However, never break user-visible strings such as printk messages because
121 ----------------------------
129 .. code-block:: c
135 This applies to all non-function statement blocks (if, switch, for,
138 .. code-block:: c
154 .. code-block:: c
162 is ... well ... inconsistent, but all right-thinking people know that
168 ie a ``while`` in a do-statement or an ``else`` in an if-statement, like
171 .. code-block:: c
174 body of do-loop
179 .. code-block:: c
191 Also, note that this brace-placement also minimizes the number of empty
193 supply of new-lines on your screen is not a renewable resource (think
194 25-line terminal screens here), you have more empty lines to put
199 .. code-block:: c
206 .. code-block:: none
216 .. code-block:: c
227 .. code-block:: c
238 function-versus-keyword usage. Use a space after (most) keywords. The
250 .. code-block:: c
255 Do not add spaces around (inside) parenthesized expressions. This example is
258 .. code-block:: c
267 .. code-block:: c
274 Use one space around (on each side of) most binary and ternary operators,
277 = + - < > * / % | & ^ <= >= == != ? :
281 & * + - ~ ! sizeof typeof alignof __attribute__ defined
285 ++ --
289 ++ --
291 and no space around the ``.`` and ``->`` structure member operators.
307 ---------
310 Unlike Modula-2 and Pascal programmers, C programmers do not use cute
315 HOWEVER, while mixed-case names are frowned upon, descriptive names for
324 Encoding the type of a function into the name (so-called Hungarian
325 notation) is asinine - the compiler knows the types anyway and can check
330 Calling it ``loop_counter`` is non-productive, if there is no chance of it
331 being mis-understood. Similarly, ``tmp`` can be just about any type of
335 problem, which is called the function-growth-hormone-imbalance syndrome.
360 -----------
365 .. code-block:: c
373 .. code-block:: c
402 Again - there needs to be a **reason** for this. If something is
412 type-checking.
421 Therefore, the Linux-specific ``u8/u16/u32/u64`` types and their
423 permitted -- although they are not mandatory in new code of your
444 ------------
453 case-statement, where you have to do lots of small things for a lot of
457 less-than-gifted first-year high-school student might not even
460 descriptive names (you can ask the compiler to in-line them if you think
461 it's performance-critical, and it will probably do a better job of it
465 shouldn't exceed 5-10, or you're doing something wrong. Re-think the
475 .. code-block:: c
492 -----------------------------------
503 Avoid using GW-BASIC names like ``err1:`` and ``err2:``, as you would have to
509 - unconditional statements are easier to understand and follow
510 - nesting is reduced
511 - errors by not updating individual exit points when making
513 - saves the compiler work to optimize redundant code away ;)
515 .. code-block:: c
524 return -ENOMEM;
541 .. code-block:: c
544 kfree(foo->bar);
552 .. code-block:: c
555 kfree(foo->bar);
564 -------------
566 Comments are good, but there is also a danger of over-commenting. NEVER
580 When commenting the kernel API functions, please use the kernel-doc format.
581 See the files at :ref:`Documentation/doc-guide/ <doc_guide>` and
582 ``scripts/kernel-doc`` for details.
584 The preferred style for long (multi-line) comments is:
586 .. code-block:: c
589 * This is the preferred style for multi-line
594 * with beginning and ending almost-blank lines.
597 For files in net/ and drivers/net/ the preferred style for long (multi-line)
600 .. code-block:: c
606 * but there is no initial almost-blank line.
616 ---------------------------
618 That's OK, we all do. You've probably been told by your long-time Unix
622 typing - an infinite number of monkeys typing into GNU emacs would never
628 .. code-block:: none
630 (defun c-lineup-arglist-tabs-only (ignored)
632 (let* ((anchor (c-langelem-pos c-syntactic-element))
633 (column (c-langelem-2nd-pos c-syntactic-element))
634 (offset (- (1+ column) anchor))
635 (steps (floor offset c-basic-offset)))
637 c-basic-offset)))
639 (dir-locals-set-class-variables
640 'linux-kernel
641 '((c-mode . (
642 (c-basic-offset . 8)
643 (c-label-minimum-indentation . 0)
644 (c-offsets-alist . (
645 (arglist-close . c-lineup-arglist-tabs-only)
646 (arglist-cont-nonempty .
647 (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only))
648 (arglist-intro . +)
649 (brace-list-intro . +)
650 (c . c-lineup-C-comments)
651 (case-label . 0)
652 (comment-intro . c-lineup-comment)
653 (cpp-define-intro . +)
654 (cpp-macro . -1000)
655 (cpp-macro-cont . +)
656 (defun-block-intro . +)
657 (else-clause . 0)
658 (func-decl-cont . +)
660 (inher-cont . c-lineup-multi-inher)
661 (knr-argdecl-intro . 0)
662 (label . -1000)
664 (statement-block-intro . +)
665 (statement-case-intro . +)
666 (statement-cont . +)
669 (indent-tabs-mode . t)
670 (show-trailing-whitespace . t)
673 (dir-locals-set-directory-class
674 (expand-file-name "~/src/linux-trees")
675 'linux-kernel)
678 files below ``~/src/linux-trees``.
683 Now, again, GNU indent has the same brain-dead settings that GNU emacs
688 options ``-kr -i8`` (stands for ``K&R, 8 character indents``), or use
692 re-formatting you may want to take a look at the man page. But
695 Note that you can also use the ``clang-format`` tool to help you with
696 these rules, to quickly re-format parts of your code automatically,
700 See the file :ref:`Documentation/process/clang-format.rst <clangformat>`
705 -------------------------------
718 logging of avc messages output). Does not do system-call
730 Documentation/kbuild/kconfig-language.rst.
734 -------------------
736 Data structures that have visibility outside the single-threaded
743 users to have access to the data structure in parallel - and not having
757 Examples of this kind of ``multi-level-reference-counting`` can be found in
766 -------------------------
770 .. code-block:: c
781 Macros with multiple statements should be enclosed in a do - while block:
783 .. code-block:: c
795 .. code-block:: c
800 return -EBUGGERED; \
808 .. code-block:: c
815 3) macros with arguments that are used as l-values: FOO(x) = y; will
822 .. code-block:: c
830 .. code-block:: c
839 ret is a common name for a local variable - __foo_ret is less likely
847 ----------------------------
867 debug message printing is handled differently than printing other non-debug
874 Many subsystems have Kconfig debug options to turn on -DDEBUG in the
877 already inside a debug-related #ifdef section, printk(KERN_DEBUG ...) can be
882 ---------------------
887 about them. :ref:`Documentation/core-api/memory-allocation.rst
892 .. code-block:: c
906 .. code-block:: c
912 .. code-block:: c
924 ----------------------
930 kernel, which in turn slows the system as a whole down, due to a bigger
952 ------------------------------------
956 failed. Such a value can be represented as an error-code integer
957 (-Exxx = failure, 0 = success) or a ``succeeded`` boolean (0 = failure,
958 non-zero = success).
961 difficult-to-find bugs. If the C language included a strong distinction
967 the function should return an error-code integer. If the name
971 for success or -EBUSY for failure. In the same way, ``PCI device present`` is
981 this rule. Generally they indicate failure by returning some out-of-range
987 --------------
1011 readable alternative if the call-sites have naked true/false constants.
1016 18) Don't re-invent the kernel macros
1017 -------------------------------------
1024 .. code-block:: c
1030 .. code-block:: c
1032 #define sizeof_field(t, f) (sizeof(((t*)0)->f))
1040 ------------------------------------
1046 .. code-block:: c
1048 -*- mode: c -*-
1052 .. code-block:: c
1056 compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
1062 .. code-block:: c
1074 -------------------
1076 In architecture-specific code, you may need to use inline assembly to interface
1085 Large, non-trivial assembly functions should go in .S files, with corresponding
1098 .. code-block:: c
1106 ---------------------------
1111 files, providing no-op stub versions in the #else case, and then call those
1130 .. code-block:: c
1136 The compiler will constant-fold the conditional away, and include or exclude
1143 At the end of any non-trivial #if or #ifdef block (more than a few lines),
1147 .. code-block:: c
1155 ----------------------
1160 ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
1164 Addison-Wesley, Inc., 1999.
1165 ISBN 0-201-61586-X.
1167 GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
1171 language C, URL: http://www.open-std.org/JTC1/SC22/WG14/
1173 Kernel :ref:`process/coding-style.rst <codingstyle>`, by greg@kroah.com at OLS 2002: