# Linux Kernel Authors - Linux Kernel Coding Style (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/56175546) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Linux Kernel Authors]] **Full Title**:: Linux Kernel Coding Style **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [github.com](https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst) **Host**:: [[github.com]] **Highlighted**:: [[2025-11-11]] **Created**:: [[2025-11-15]] ## Highlights - Tabs are 8 characters, and thus indentations are also 8 characters. ([View Highlight](https://read.readwise.io/read/01k9r5pf60yw8sa9hxf3d8cgej)) ^956332087 - Always uses braces for multiple statements ([View Highlight](https://read.readwise.io/read/01k9r5qr3g2key002geakk5307)) ^956332134 - Don't put multiple assignments on a single line either. Kernel coding style is super simple. Avoid tricky expressions. ([View Highlight](https://read.readwise.io/read/01k9r5r7s9am3qx77bj0mr6h5t)) ^956332157 - The preferred limit on the length of a single line is 80 columns. ([View Highlight](https://read.readwise.io/read/01k9r5rv78d5ab4e3r7jkgj42c)) ^956332300 - Statements longer than 80 columns should be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. ([View Highlight](https://read.readwise.io/read/01k9r5s049e7zvy92dzxq5eswp)) ^956332313 - However, never break user-visible strings such as printk messages because that breaks the ability to grep for them. ([View Highlight](https://read.readwise.io/read/01k9r5xmnrw66pg9zd8v3peekt)) ^956332730 - the preferred way, as shown to us by the prophets Kernighan and Ritchie, is to put the opening brace last on the line, and put the closing brace first ([View Highlight](https://read.readwise.io/read/01k9r5ynjrh83h50xpnsgyqaz1)) ^956332930 - However, there is one special case, namely functions: they have the opening brace at the beginning of the next line ([View Highlight](https://read.readwise.io/read/01k9r5yz34kt5m1e009mvhz0ep)) ^956332948 - Do not unnecessarily use braces where a single statement will do. ([View Highlight](https://read.readwise.io/read/01k9r5zspkbeqfdfb0b6ckbxya)) ^956332971 - This does not apply if only one branch of a conditional statement is a single statement; in the latter case use braces in both branches ([View Highlight](https://read.readwise.io/read/01k9r605knjpmgt8qwzkvwxt89)) ^956332980 - When declaring pointer data or a function that returns a pointer type, the preferred use of `*` is adjacent to the data name or function name and not adjacent to the type name. ([View Highlight](https://read.readwise.io/read/01k9r61sd6pvjfhqr3fx0jpq5e)) ^956333163 - Please don't use things like `vps_t`. It's a **mistake** to use typedef for structures and pointers. ([View Highlight](https://read.readwise.io/read/01k9r64mf9p3n0nvd22h88jm5y)) ^956333469 - If the function is exported, the **EXPORT** macro for it should follow immediately after the closing function brace line. ([View Highlight](https://read.readwise.io/read/01k9r660jzpnjjkfc9e2dcd3he)) ^956333504 - In function prototypes, include parameter names with their data types. ([View Highlight](https://read.readwise.io/read/01k9r69e8nhqyk3w5etw6b4jkw)) ^956333608 - The goto statement comes in handy when a function exits from multiple locations and some common work such as cleanup has to be done. If there is no cleanup needed then just return directly. ([View Highlight](https://read.readwise.io/read/01k9r6cqa7sb1z7g3egvzghxv8)) ^956333793 - Choose label names which say what the goto does or why the goto exists. ([View Highlight](https://read.readwise.io/read/01k9r6d9sey70ezmcw8h4tbzzy)) ^956333845 - NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the **working** is obvious, and it's a waste of time to explain badly written code. ([View Highlight](https://read.readwise.io/read/01k9r6fj29fe30w2r9kvxxgqg8)) ^956334449 - If the name of a function is an action or an imperative command, the function should return an error-code integer. If the name is a predicate, the function should return a "succeeded" boolean. ([View Highlight](https://read.readwise.io/read/01k9r6qy4vkw44x0hggpexaycw)) ^956334965 - Do not use bool if cache line layout or size of the value matters, as its size and alignment varies based on the compiled architecture. ([View Highlight](https://read.readwise.io/read/01k9r6sr301q37ejvxzw7hbgyf)) ^956335215 - WARN*() is intended for unexpected, this-should-never-happen situations. WARN*() macros are not to be used for anything that is expected to happen during normal operation. ([View Highlight](https://read.readwise.io/read/01k9r6wh6v09dq2pqer6ems15a)) ^956335359