I just realized. The more you comment your code and make it understandable, the easier it is for other people to takeover and rewrite your code. This means that when you retire/pass-away, your code will likely be quickly overwritten and your legacy gone from the active code base.

So, if you write complex clever code with little to no documentation, your code is more likely to be immortalized in the code base as everyone will be too afraid to touch it and possibly break it.

I thought of this when looking into the Linux TTY code base

@rostedt drivers/tty is terrifying. I avoid it as much as possible.

@mansr And the authors of that code will forever have their legacy in the code base!

@rostedt Would it be possible to gradually replace it with something halfway sane?

@rostedt On the other hand your product has better chances to survive when it is maintainable and adjustable. Else it will soon become this legacy monster that everyone is trying to get rid of.

@rostedt wow, what a bad reason to get immortalized. Maybe when writing kernel code we should keep in mind that we are then potentially immortalized like a villain in a history book.

@rostedt $ git blame --all | grep rostedt
fatal: no such path '--all' in HEAD

On the other hand: if you document your code well enough that it can evolve, there will always be a trace of your code left. If you leave it an undocumented mess, someone is more likely to end up replacing it wholesale. :)

@rostedt we unfortunately acquired a corner in a drm driver which fits this description too 🙄

the only feasible changes we could pull off was to wrap a fixed uapi around it that made most of the internal objects invariant over their lifetimes. because there's just no way anyone will ever figure out how the locking actually works, or was meant to work. we could only pull this off because drm userspace is all open and well-known

no such option for tty

@mansr @rostedt

Thank you both, I needed something to fill me with horror and drag me closer to madness and this may finally be it.

@rostedt "It was hard to write so it should be hard to read".

@hergertme Sorry, I left screaming….

@llvm That’s why I added “pass-away” as that’s what I plan on doing for my retirement 🤪

@mansr @rostedt Looks like a good target for a rust rewrite at some point (when Rust is ready, TTI is critical).

@JosuGZ @rostedt The language has nothing to do with this.

@mansr @rostedt Yes of course! But rewriting is usually a bad idea. Unless you are aiming to get some benefits that can't be achieved by refactoring.

@JosuGZ @rostedt Have you looked at the monstrosity?

@mansr @rostedt No but that is the problem: how do you get a spec out of a monstruosity so you can do a rewrite?

It is a hard thing to do and chances are you might end up making another monstruosity as you start discovering the edge cases that originated the monstruosity on the first place 😂