I’ve also heard it said that if you can’t see an entire method at once in your editor, it’s time to refactor. The most basic thing to do in this case is to use “guard clauses,” or what is often called inversion. Deeply nested code often happens because there are a lot of nested if statements. But if you invert the if statement to “bail out if things aren’t right” rather than “keep asking if you can continue” pattern, you can avoid a lot of the brain-clogging boolean situations. Oftentimes, inversion can actually remove all of the nesting levels in a method.The other strategy is to always extract code to smaller methods, so that no code block ever gets too big. Senior developers aren’t afraid of lots of small classes and methods. And of course, all those classes will be descriptively named, right?
Senior developers don’t comment their code
I saved this one for last because I know many developers get bent out of shape at this notion. I am, though, quite adamant on this point. I’m a firm believer that 99.9% of comments are an indication of bad code, bad naming, or a lack of explaining variables. If you feel the need to comment your code, it is almost certainly because your code is not clear and easily understood. If your code is not clear and easily understood, then it needs to be rewritten until it is. (Naming well and using explaining variables will help.)
In addition, comments are not physically attached to the code they refer to, and can actually go adrift, causing no end of confusion.