Nobody said it was easy hehehe. I agree I've never seen a large codebase that was "cleanly written", as you said, things evolve and also people are lazy, so they just add some more lines to that already existing function instead of refactoring it. Things grow and become hard to understand, but I disagree that comments will help solve that problem. The rule of thumb is: if you're tempted to add a comment to explain what a few lines of code do, instead, make a new function and explain what the function does by giving it a good name! Yes, that sounds easier than it is, but it's still better than adding a comment that either explain what we can already see in the code, or even worse, it starts to drift in the codebase as people add new lines of code and don't update/move/remove the comment.
Nah, I am talking about meta-information that cannot be completely described through awesome, clearly named, and structured code alone.
You can give a some class in a hierarchy a clear name, and it will be obvious what this specific class is responsible for in its module or even in the entire service (this is the level of concrete realization). And this is the place where comments are usually serve as indicators of bad style, I am totally agree with you.
However, there are things like Abstract Data Types (ADTs) and internal parts of libraries that you would like to understand in place – what they are for in the overall system (this is the level of architecture).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nobody said it was easy hehehe. I agree I've never seen a large codebase that was "cleanly written", as you said, things evolve and also people are lazy, so they just add some more lines to that already existing function instead of refactoring it. Things grow and become hard to understand, but I disagree that comments will help solve that problem. The rule of thumb is: if you're tempted to add a comment to explain what a few lines of code do, instead, make a new function and explain what the function does by giving it a good name! Yes, that sounds easier than it is, but it's still better than adding a comment that either explain what we can already see in the code, or even worse, it starts to drift in the codebase as people add new lines of code and don't update/move/remove the comment.
Nah, I am talking about meta-information that cannot be completely described through awesome, clearly named, and structured code alone.
You can give a some class in a hierarchy a clear name, and it will be obvious what this specific class is responsible for in its module or even in the entire service (this is the level of concrete realization). And this is the place where comments are usually serve as indicators of bad style, I am totally agree with you.
However, there are things like Abstract Data Types (ADTs) and internal parts of libraries that you would like to understand in place – what they are for in the overall system (this is the level of architecture).