@25
Also, I personally feel like your choice of language and tooling helps a little with this.

I had to change the signature of a function in Dart yesterday. It took me about 15 seconds to change the signature and then the function body. After that, it was probably about 2 hours of (not exactly frenetic) work to change the rest of the code base, because the dart analyser wouldn't shut up about invalid calls to that function.

Admittedly this was only a small change, in a small app, but the point still stands.

Other than that, I suppose just to back Camlorn up: It's better to have written and learnt from 10000 lines of dodgy code, than to have nothing to show for 0 lines.

@28
Unit testing takes experience but is a good idea, though I'm not sure how to do so for a kernel.  I'm sure someone has solved this problem.

Synthizer has some, and it'll be getting more.  One thing that can be useful for the weird cases is gold master testing: don't test that thing x is right, instead check the output of thing x against the previous output of thing x and see if it changed.  This is what I plan to do for Synthizer, since it is entirely possible to say "yep this sounds right", then capture an audio file of it.

You may also look at libfuzzer and similar fuzzing technologies: if you can compile parts of the kernel outside the environment it needs to run in, e.g. network parsers or whatever, something like that can find crashes.

Clang-analyzer will run over the kernel no problem.  It's static analysis so running in the kernel's compiled environment isn't necessary.  This can tell you things like "there is definitely a memory leak here", though I don't know what you have to annotate with or anything if you're providing a custom allocator.

Ah, yeah.  Rust makes a great deal of this moot by the nature of being Rust, so eh.

But if you are in Rust you can easily unit test inline.  In the same file as the code:

#[cfg(test)]
mod tests {

#[test]
fn passes() {
}
}

which will have access to the private content of the module and can import dev dependencies, e.g. in your case you probably want proptest or quickcheck, but see also assert_json_diff if you're willing to annotate things with Serde (I believe there is a no-std version of Serde, but maybe not).