Lines Matching full:code
32 the code move too far to the right, and makes it hard to read on a
45 .. code-block:: c
67 .. code-block:: c
74 .. code-block:: c
81 .. code-block:: c
129 .. code-block:: c
138 .. code-block:: c
154 .. code-block:: c
171 .. code-block:: c
179 .. code-block:: c
199 .. code-block:: c
206 .. code-block:: c
216 .. code-block:: c
227 .. code-block:: c
250 .. code-block:: c
258 .. code-block:: c
267 .. code-block:: c
295 appropriate, so you can start typing the next line of code right away.
297 putting a line of code there, such as if you leave a blank line. As a result,
354 or when updating code for an existing (as of 2020) hardware or protocol
365 .. code-block:: c
373 .. code-block:: c
423 permitted -- although they are not mandatory in new code of your
426 When editing existing code which already uses one or the other set
427 of types, you should conform to the existing choices in that code.
475 .. code-block:: c
548 - saves the compiler work to optimize redundant code away ;)
550 .. code-block:: c
576 .. code-block:: c
583 The bug in this code is that on some exit paths ``foo`` is NULL. Normally the
587 .. code-block:: c
602 try to explain HOW your code works in a comment: it's much better to
603 write the code so that the **working** is obvious, and it's a waste of
604 time to explain badly written code.
606 Generally, you want your comments to tell WHAT your code does, not HOW.
621 .. code-block:: c
625 * comments in the Linux kernel source code.
651 .. code-block:: elisp
719 these rules, to quickly re-format parts of your code automatically,
786 filesystem code (``struct super_block``: s_count and s_active).
797 .. code-block:: c
810 .. code-block:: c
821 .. code-block:: c
833 .. code-block:: c
845 .. code-block:: c
854 function; don't break the internal parsers of those who will read the code.
858 .. code-block:: c
863 code and it's prone to breakage from seemingly innocent changes.
872 .. code-block:: c
880 .. code-block:: c
943 .. code-block:: c
957 .. code-block:: c
963 .. code-block:: c
988 than 3 lines of code in them. An exception to this rule are the cases where
1007 failed. Such a value can be represented as an error-code integer
1018 the function should return an error-code integer. If the name
1075 .. code-block:: c
1081 .. code-block:: c
1087 defined that you shouldn't reproduce in your code.
1097 .. code-block:: c
1103 .. code-block:: c
1113 .. code-block:: c
1127 In architecture-specific code, you may need to use inline assembly to interface
1149 .. code-block:: c
1160 files; doing so makes code harder to read and logic harder to follow. Instead,
1164 any code for the stub calls, producing identical results, but the logic will
1178 Within code, where possible, use the IS_ENABLED macro to convert a Kconfig
1181 .. code-block:: c
1188 the block of code just as with an #ifdef, so this will not add any runtime
1189 overhead. However, this approach still allows the C compiler to see the code
1191 references, etc). Thus, you still have to use an #ifdef if the code inside the
1198 .. code-block:: c
1221 Do not add new code that uses any of the BUG() variants, such as BUG(),
1223 WARN_ON_ONCE(), and possibly with recovery code. Recovery code is not