User:Anotheridiot/10 Commandments
1. Thou Shalt Not Duplication. If you write the same damn interrupt handler twice, or copy-paste that memory allocation logic, then thou art creating a hellish landscape of inconsistencies and future bugs. Every line of code, every register write, every configuration bit, it all shall have one single source of truth. Duplication in the kernel is not just inefficient; it is a direct path to system instability and the dreaded triple fault.
2. Thou Shalt Name Things Explicitly. Thy reg_val or _tmp shall not pass! Every variable, every function, every structure, every bitfield in thy kernel must declare its purpose with absolute, unyielding clarity. If a name does not immediately scream its function, its scope, and its intended effect on the hardware, then thou hast failed. Vague naming in the kernel is a shortcut to buffer overflows and inexplicable crashes.
3. Thou Shalt Comment "Why," Never "What." Thou shalt not insult the intelligence of thy fellow (or future) developers by stating the obvious. The code, if it is not garbage, reveals what it does. But thy comments? They shall illuminate the dark corners of why this specific, non-obvious choice was made, why this hardware quirk dictates this dance, why this particular race condition is being avoided with such arcane magic. The "why" is the only comment that matters when you're wrestling with race conditions and timing issues.
4. Thou Shalt Keep Functions Atomically Small. If thy function touches more than one piece of hardware, or manipulates more than one logical concept, then it is a sprawling abomination. Thou shalt break down every routine, every handler, every driver entry point until each performs a single, indivisible task. Monolithic kernel functions are the fertile ground for deadlocks and unmanageable complexity.
5. Thou Shalt Embrace Minimal Dependencies with Vengeance. Every external module, every borrowed driver, every piece of "convenience" code from outside thy direct control is a gaping security hole, a performance bottleneck, or an ancient, unmaintained relic waiting to drag thy pristine kernel into the abyss. Thou shalt build only what is absolutely, critically necessary, and understand every byte of it. Trust no one, especially not third-party libraries in kernel space.
6. Thou Shalt Test Thy Code with Utmost Rigor. If thou hast written it, thou hast a sacred duty to break it. If thy code exists without a rigorous suite of tests—unit, integration, stress, and perverse edge cases—then it is but a theoretical construct, destined to fail in the wild. Kernel code untested is kernel code that will surely crash, and take everything with it.
7. Thou Shalt Handle Errors with Uncompromising Resolve. To catch an error and then merely shrug, or worse, to silently swallow it, is a sin punishable by endless debugging sessions. When the hardware screams, when memory fails, when an invalid state arises, thou shalt log it with precision, thou shalt report it, and thou shalt respond to it with the decisiveness of a surgeon. Unhandled errors in the kernel lead to silent corruption and bricked systems.
8. Thou Shalt Banish All Magic Numbers and Hardcoded Values. Thy hardcoded memory addresses, thy arbitrary loop counts, thy undocumented bitmasks—they are sorcery, and they shall lead thee astray. Every significant numerical or string literal shall be defined as a named constant, clearly documenting its purpose and its origin. Obscure values in kernel code guarantee catastrophic failures during future revisions or hardware changes.
9. Thou Shalt Ruthlessly Delete Unnecessary Code. The most stable, performant, and secure code is that which does not exist. If a function is unused, if a driver is obsolete, if a feature is abandoned, then thou shalt purge it from thy codebase with prejudice. Every line of dead code is a potential source of confusion, a vector for bugs, and a drain on understanding.
10. Thou Shalt Strive for Inhuman Simplicity. This is the bedrock, the very essence of reliable OS development. If thy solution is complex, convoluted, or requires mental gymnastics to comprehend, then it is fundamentally flawed. The most robust kernels are those built upon layers of elegant, straightforward simplicity. Reject needless abstraction, eschew cleverness for clarity, and always, always seek the simplest, most direct path to achieve thy goal. Complexity in the kernel is a personal failing that will manifest as system-wide catastrophe.