Code is never missing contexts. If what your code is doing is not obvious to the reader, it is bad code that needs to be fixed. Things like cryptic low-level expressions should be extracted to helper functions with descriptive names or even extracted into a class, and classes need to comply with the single responsibility principle.
This is demonstratably false. Case in point: all the code that does not require comments for developers to understand what it does.
> Some devs are so full of themselves they think their code is so good that it is obvious what their intent was. It never is obvious, and just ends up as tech debt.
That's why you need to address the problem in the PR stage and aggressively refactor code that fails to be clear.
This is not rocket science.
> Write comments.
No, that's just compounding the problem. Now you attached comment noise to cryptic code, which means not only do you still need to decipher the hot mess of a code you cannot parse on your own but you also have to parse the comment next to it to try to understand both.
And God forbid they get out of sync.
The solution is already known for over a decade: write clear and obvious code. Extract weird expressions into helper functions.
No, not really. You get spaghetti code by being unable to refactor your code to follow inconsistent level of detail across calls. That's the textbook definition.
Once you start to follow basic code quality and software engineering principles, you'll notice right away that your code becomes both easier to understand and to test.