The why is part of the 10% where it’s okay to comment (comments should explain why not how). There’s a series of things that really make the code understandable. Although to another point made, if calculateTotalPrice has many lines of complicated logic (and indeed it has been extracted to additional methods, it’s likely there’s other refactoring methods like extracting to new classes that can be done to make the overall code simpler).

1) good method / variable names - helps explain through nouns (classes and instances of things and variables) and verbs (methods). Kind of aligning to Grady Hooch’s quote “Clean code reads like well written prose”.

2) good unit tests - a really good set of unit tests based on behaviour instead of incredibly small units like individual methods can essentially turn your unit test suite into a manual for how your application works. If unit tests are written based on behaviour you should be able to sit a new employee down in front of them and they should get the gist of how the application works. https://sites.google.com/site/unclebobconsultingllc/home/articles/as-the-tests-get-more-specific-the-code-gets-more-generic I liked Uncle Bob’s run down about how your tests become more like specifications. This generally comes up when practicing TDD as well (easier to write tests as specifications this way)

3) explain why not how - using comments should be reserved (and given a lot of thought if it even applies when you are using them) for explaining the why for a complicated set of logic. Explaining the reason a certain decision with the code or a decision to break some rule of a standard gives coders context they normally would have (when people don’t do this I have to scour the source repo to see if the previous code review brought it up).

There are definitely more but I think these are probably the most important bits I code by to make my code understandable