Lines Matching refs:t

7 linux kernel.  Coding style is very personal, and I won't **force** my
64 Don't put multiple statements on a single line unless you have
72 Don't use commas to avoid using braces:
88 Don't put multiple assignments on a single line either.  Kernel coding style
95 Get a decent editor and don't leave whitespace at the end of lines.
164 special anyway (you can't nest them in C).
362 Please don't use things like ``vps_t``.
465 shouldn't exceed 5-10, or you're doing something wrong.  Re-think the
491 lines longer and isn't strictly necessary.
704           (indent-tabs-mode . t)
705           (show-trailing-whitespace . t)
721 recognize the authority of K&R (the GNU people aren't evil, they are
773 reference counts.  In the kernel, garbage collection doesn't exist (and
796 Remember: if another thread can find your data structure, and you don't
839 function; don't break the internal parsers of those who will read the code.
886 contractions like ``dont``; use ``do not`` or ``don't`` instead. Make the
896 dev_info(), and so forth.  For messages that aren't associated with a
998 for us... but it doesn't.  To help prevent such bugs, always follow this
1008 finding a matching device or 0 if it doesn't.
1051 18) Don't re-invent the kernel macros
1067 	#define sizeof_field(t, f) (sizeof(((t*)0)->f))
1071 defined that you shouldn't reproduce in your code.
1112 with CPU or platform functionality.  Don't hesitate to do so when necessary.
1113 However, don't use inline assembly gratuitously when C can do the job.  You can
1125 removing it if GCC doesn't notice any side effects.  You don't always need to
1130 string, and end each string except the last with ``\n\t`` to properly indent
1135 	asm ("magic %reg1, #42\n\t"
1143 Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c