Documentation/development-process/4.Coding

48 on it for other reasons, but coding style changes should not be made for
51 The coding style document also should not be read as an absolute law which
64 just as harmful as premature optimization.  Abstraction should be used to
75 patches to remove unused arguments; they should, in general, not be added
102 should be confined to header files whenever possible.
124 slow execution dramatically.  Inline functions, as a rule, should be quite
135 a given function should actually be inlined or not.  So the liberal
165 New code should be written with this requirement in mind; retrofitting
167 should take the time to understand the available locking primitives well
214 tools should be used whenever possible.
219 Code submitted for review should, as a rule, not produce any compiler
229 of these options should be turned on for any kernel used for development or
230 testing purposes.  In particular, you should turn on:
245    should be used on most development kernels.
252 should not be used all of the time.  But some time spent learning the
265 locking should be run with lockdep enabled before being submitted for
320 changelog.  Log entries should describe the problem being solved, the form
328 /proc files - should include documentation of that interface which enables
330 Documentation/ABI/README for a description of how this documentation should
334 boot-time parameters.  Any patch which adds new parameters should add the
343 a subsystem which has kerneldoc comments, you should maintain them and add
355 for verbosely-commented code.  The code should, itself, be readable, with
358 Certain things should always be commented.  Uses of memory barriers should
362 Non-obvious dependencies between separate bits of code should be pointed
378 to be well justified.  So any patch making an internal API change should be
380 necessary.  This kind of change should also be broken out into a separate
392 When making an incompatible API change, one should, whenever possible,