Lines Matching +full:use +full:- +full:case
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
42 to align the ``switch`` and its subordinate ``case`` labels in the same column
43 instead of ``double-indenting`` the ``case`` labels. E.g.:
45 .. code-block:: c
48 case 'G':
49 case 'g':
52 case 'M':
53 case 'm':
56 case 'K':
57 case 'k':
67 .. code-block:: c
82 ----------------------------------
99 However, never break user-visible strings such as printk messages because
104 ----------------------------
112 .. code-block:: c
118 This applies to all non-function statement blocks (if, switch, for,
121 .. code-block:: c
124 case KOBJ_ADD:
126 case KOBJ_REMOVE:
128 case KOBJ_CHANGE:
134 However, there is one special case, namely functions: they have the
137 .. code-block:: c
145 is ... well ... inconsistent, but all right-thinking people know that
151 ie a ``while`` in a do-statement or an ``else`` in an if-statement, like
154 .. code-block:: c
157 body of do-loop
162 .. code-block:: c
174 Also, note that this brace-placement also minimizes the number of empty
176 supply of new-lines on your screen is not a renewable resource (think
177 25-line terminal screens here), you have more empty lines to put
180 Do not unnecessarily use braces where a single statement will do.
182 .. code-block:: c
189 .. code-block:: none
197 statement; in the latter case use braces in both branches:
199 .. code-block:: c
208 Also, use braces when a loop contains more than a single simple statement:
210 .. code-block:: c
220 Linux kernel style for use of spaces depends (mostly) on
221 function-versus-keyword usage. Use a space after (most) keywords. The
227 So use a space after these keywords::
229 if, switch, case, for, do, while
233 .. code-block:: c
241 .. code-block:: c
247 preferred use of ``*`` is adjacent to the data name or function name and not
250 .. code-block:: c
257 Use one space around (on each side of) most binary and ternary operators,
260 = + - < > * / % | & ^ <= >= == != ? :
264 & * + - ~ ! sizeof typeof alignof __attribute__ defined
268 ++ --
272 ++ --
274 and no space around the ``.`` and ``->`` structure member operators.
290 ---------
293 Unlike Modula-2 and Pascal programmers, C programmers do not use cute
298 HOWEVER, while mixed-case names are frowned upon, descriptive names for
307 Encoding the type of a function into the name (so-called Hungarian
308 notation) is asinine - the compiler knows the types anyway and can check
314 Calling it ``loop_counter`` is non-productive, if there is no chance of it
315 being mis-understood. Similarly, ``tmp`` can be just about any type of
319 problem, which is called the function-growth-hormone-imbalance syndrome.
344 -----------
346 Please don't use things like ``vps_t``.
347 It's a **mistake** to use typedef for structures and pointers. When you see a
349 .. code-block:: c
357 .. code-block:: c
386 Again - there needs to be a **reason** for this. If something is
393 ``unsigned long``, then by all means go ahead and use a typedef.
395 (c) when you use sparse to literally create a **new** type for
396 type-checking.
403 some people object to their use anyway.
405 Therefore, the Linux-specific ``u8/u16/u32/u64`` types and their
407 permitted -- although they are not mandatory in new code of your
413 (e) Types safe for use in userspace.
416 require C99 types and cannot use the ``u32`` form above. Thus, we
417 use __u32 and similar types in all structures which are shared
421 EVER use a typedef unless you can clearly match one of those rules.
428 ------------
437 case-statement, where you have to do lots of small things for a lot of
441 less-than-gifted first-year high-school student might not even
443 maximum limits all the more closely. Use helper functions with
444 descriptive names (you can ask the compiler to in-line them if you think
445 it's performance-critical, and it will probably do a better job of it
449 shouldn't exceed 5-10, or you're doing something wrong. Re-think the
459 .. code-block:: c
471 Do not use the ``extern`` keyword with function prototypes as this makes
476 -----------------------------------
487 Avoid using GW-BASIC names like ``err1:`` and ``err2:``, as you would have to
493 - unconditional statements are easier to understand and follow
494 - nesting is reduced
495 - errors by not updating individual exit points when making
497 - saves the compiler work to optimize redundant code away ;)
499 .. code-block:: c
508 return -ENOMEM;
525 .. code-block:: c
528 kfree(foo->bar);
536 .. code-block:: c
539 kfree(foo->bar);
548 -------------
550 Comments are good, but there is also a danger of over-commenting. NEVER
564 When commenting the kernel API functions, please use the kernel-doc format.
565 See the files at :ref:`Documentation/doc-guide/ <doc_guide>` and
566 ``scripts/kernel-doc`` for details.
568 The preferred style for long (multi-line) comments is:
570 .. code-block:: c
573 * This is the preferred style for multi-line
575 * Please use it consistently.
578 * with beginning and ending almost-blank lines.
581 For files in net/ and drivers/net/ the preferred style for long (multi-line)
584 .. code-block:: c
590 * but there is no initial almost-blank line.
594 types. To this end, use just one data declaration per line (no commas for
596 item, explaining its use.
600 ---------------------------
602 That's OK, we all do. You've probably been told by your long-time Unix
606 typing - an infinite number of monkeys typing into GNU emacs would never
609 So, you can either get rid of GNU emacs, or change it to use saner
612 .. code-block:: none
614 (defun c-lineup-arglist-tabs-only (ignored)
616 (let* ((anchor (c-langelem-pos c-syntactic-element))
617 (column (c-langelem-2nd-pos c-syntactic-element))
618 (offset (- (1+ column) anchor))
619 (steps (floor offset c-basic-offset)))
621 c-basic-offset)))
623 (dir-locals-set-class-variables
624 'linux-kernel
625 '((c-mode . (
626 (c-basic-offset . 8)
627 (c-label-minimum-indentation . 0)
628 (c-offsets-alist . (
629 (arglist-close . c-lineup-arglist-tabs-only)
630 (arglist-cont-nonempty .
631 (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only))
632 (arglist-intro . +)
633 (brace-list-intro . +)
634 (c . c-lineup-C-comments)
635 (case-label . 0)
636 (comment-intro . c-lineup-comment)
637 (cpp-define-intro . +)
638 (cpp-macro . -1000)
639 (cpp-macro-cont . +)
640 (defun-block-intro . +)
641 (else-clause . 0)
642 (func-decl-cont . +)
644 (inher-cont . c-lineup-multi-inher)
645 (knr-argdecl-intro . 0)
646 (label . -1000)
648 (statement-block-intro . +)
649 (statement-case-intro . +)
650 (statement-cont . +)
653 (indent-tabs-mode . t)
654 (show-trailing-whitespace . t)
657 (dir-locals-set-directory-class
658 (expand-file-name "~/src/linux-trees")
659 'linux-kernel)
662 files below ``~/src/linux-trees``.
665 everything is lost: use ``indent``.
667 Now, again, GNU indent has the same brain-dead settings that GNU emacs
672 options ``-kr -i8`` (stands for ``K&R, 8 character indents``), or use
676 re-formatting you may want to take a look at the man page. But
679 Note that you can also use the ``clang-format`` tool to help you with
680 these rules, to quickly re-format parts of your code automatically,
684 See the file :ref:`Documentation/process/clang-format.rst <clangformat>`
689 -------------------------------
702 logging of avc messages output). Does not do system-call
714 Documentation/kbuild/kconfig-language.rst.
718 -------------------
720 Data structures that have visibility outside the single-threaded
727 users to have access to the data structure in parallel - and not having
741 Examples of this kind of ``multi-level-reference-counting`` can be found in
750 -------------------------
754 .. code-block:: c
761 may be named in lower case.
765 Macros with multiple statements should be enclosed in a do - while block:
767 .. code-block:: c
779 .. code-block:: c
784 return -EBUGGERED; \
792 .. code-block:: c
799 3) macros with arguments that are used as l-values: FOO(x) = y; will
806 .. code-block:: c
814 .. code-block:: c
823 ret is a common name for a local variable - __foo_ret is less likely
831 ----------------------------
834 of kernel messages to make a good impression. Do not use incorrect
835 contractions like ``dont``; use ``do not`` or ``don't`` instead. Make the
843 which you should use to make sure messages are matched to the right device
851 debug message printing is handled differently than printing other non-debug
858 Many subsystems have Kconfig debug options to turn on -DDEBUG in the
861 already inside a debug-related #ifdef section, printk(KERN_DEBUG ...) can be
866 ---------------------
871 about them. :ref:`Documentation/core-api/memory-allocation.rst
876 .. code-block:: c
890 .. code-block:: c
896 .. code-block:: c
904 without __GFP_NOWARN so there is no use in emitting an additional failure
908 ----------------------
911 faster" speedup option called ``inline``. While the use of inlines can be
913 very often is not. Abundant use of the inline keyword leads to a much bigger
924 function away at compile time. For a good example of this later case, see
936 ------------------------------------
940 failed. Such a value can be represented as an error-code integer
941 (-Exxx = failure, 0 = success) or a ``succeeded`` boolean (0 = failure,
942 non-zero = success).
945 difficult-to-find bugs. If the C language included a strong distinction
951 the function should return an error-code integer. If the name
955 for success or -EBUSY for failure. In the same way, ``PCI device present`` is
965 this rule. Generally they indicate failure by returning some out-of-range
966 result. Typical examples would be functions that return pointers; they use
971 --------------
981 bool function return types and stack variables are always fine to use whenever
982 appropriate. Use of bool is encouraged to improve readability and is often a
985 Do not use bool if cache line layout or size of the value matters, as its size
987 optimized for alignment and size should not use bool.
995 readable alternative if the call-sites have naked true/false constants.
997 Otherwise limited use of bool in structures and arguments can improve
1000 18) Don't re-invent the kernel macros
1001 -------------------------------------
1004 you should use, rather than explicitly coding some variant of them yourself.
1008 .. code-block:: c
1012 Similarly, if you need to calculate the size of some structure member, use
1014 .. code-block:: c
1016 #define sizeof_field(t, f) (sizeof(((t*)0)->f))
1024 ------------------------------------
1030 .. code-block:: c
1032 -*- mode: c -*-
1036 .. code-block:: c
1040 compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
1046 .. code-block:: c
1052 includes markers for indentation and mode configuration. People may use their
1058 -------------------
1060 In architecture-specific code, you may need to use inline assembly to interface
1062 However, don't use inline assembly gratuitously when C can do the job. You can
1067 that inline assembly can use C parameters.
1069 Large, non-trivial assembly functions should go in .S files, with corresponding
1071 functions should use ``asmlinkage``.
1082 .. code-block:: c
1090 ---------------------------
1092 Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c
1094 use such conditionals in a header file defining functions for use in those .c
1095 files, providing no-op stub versions in the #else case, and then call those
1111 Within code, where possible, use the IS_ENABLED macro to convert a Kconfig
1112 symbol into a C boolean expression, and use it in a normal C conditional:
1114 .. code-block:: c
1120 The compiler will constant-fold the conditional away, and include or exclude
1124 references, etc). Thus, you still have to use an #ifdef if the code inside the
1127 At the end of any non-trivial #if or #ifdef block (more than a few lines),
1131 .. code-block:: c
1139 ----------------------
1144 ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
1148 Addison-Wesley, Inc., 1999.
1149 ISBN 0-201-61586-X.
1151 GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
1155 language C, URL: http://www.open-std.org/JTC1/SC22/WG14/
1157 Kernel :ref:`process/coding-style.rst <codingstyle>`, by greg@kroah.com at OLS 2002: