Lines Matching refs:it
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.
25 at your screen for 20 straight hours, you'll find it a lot easier to see
29 the code move too far to the right, and makes it hard to read on a
130 the cases where it is followed by a continuation of the same statement,
255 "count_active_users()" or similar, you should _not_ call it "cntusr()".
259 check those, and it only confuses the programmer. No wonder MicroSoft
263 some random integer loop counter, it should probably be called "i".
264 Calling it "loop_counter" is non-productive, if there is no chance of it
280 in the source, what does it mean?
281 In contrast, if it says
301 whether it is "int" or "long".
311 but if there is a clear reason for why it under certain circumstances
321 Although it would only take a short amount of time for the eyes and
357 different cases, it's OK to have a longer function.
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
375 exported, the EXPORT* macro for it should follow immediately after the closing
385 Although this is not required by the C language, it is preferred in Linux
386 because it is a simple way to add valuable information for the reader.
433 A common type of bug to be aware of it "one err bugs" which look like this:
441 fix for this is to split it up into two error labels "err_bar:" and "err_foo:".
447 try to explain HOW your code works in a comment: it's much better to
448 write the code so that the _working_ is obvious, and it's a waste of
453 function is so complex that you need to separately comment parts of it,
457 of the function, telling people what it does, and possibly WHY it does
458 it.
472 * Please use it consistently.
494 Chapter 9: You've made a mess of it
498 you, and you've noticed that yes, it does do that, but the defaults it
503 So, you can either get rid of GNU emacs, or change it to use saner
543 has, which is why you need to give it a few command line options.
550 "indent" has a lot of options, and especially when it comes to comment
611 have a reference count on it, you almost certainly have a bug.
652 might look like a good thing, but it's confusing as hell when one reads the
653 code and it's prone to breakage from seemingly innocent changes.
704 pr_debug() does not; it is compiled out by default, unless either DEBUG is
711 when a debug message should be unconditionally printed, such as if it is
751 appropriate (for example as a means of replacing macros, see Chapter 12), it
755 available for the pagecache. Just think about it; a pagecache miss causes a
771 something it would have done anyway.
785 for us... but it doesn't. To help prevent such bugs, always follow this
794 a predicate, and the pci_dev_present() function returns 1 if it succeeds in
795 finding a matching device or 0 if it doesn't.
798 public functions. Private (static) functions need not, but it is
869 removing it if GCC doesn't notice any side effects. You don't always need to
899 going unused, mark the definition as __maybe_unused rather than wrapping it in
901 unused, delete it.)
904 symbol into a C boolean expression, and use it in a normal C conditional:
913 inside the block, and check it for correctness (syntax, types, symbol