The controversy surrounding comments
Today we're focusing on a surprising topic: comments. Did you expect that after functions we would directly move on to classes and objects (small spoiler for later)? But as we learned on Day 2: "Functions are the first and smallest level of modularization in software" and already form a complete foundation before we progress to more complex concepts.
A radical thesis
The Clean Code philosophy on comments can actually be summarized in one provocative sentence: Clean Code is code without comments. This statement immediately triggers discussions. In my entire career, I've only been in a single project where this rule was strictly followed – and surprisingly, it worked excellently. Initially, I missed writing comments, but soon I continued developing the systems without even thinking about it. Just a matter of getting used to it? Not necessarily. The code was simply so well structured that comments became completely superfluous.
The deeper reason
An alternative perspective on this topic is: If a comment seems necessary, you may not have understood the domain well enough to represent it clearly in the code. Unfortunately, developers' first impulse is often to write a comment when they're uncertain about how something should be implemented. Instead, it's worth investing more time in understanding the requirements and the business domain.
Meaningful exceptions
Of course, there are legitimate exceptions here as well:
Legal notices
TODO comments (temporary)
Javadoc for public APIs
And other special cases that are better illustrated through concrete examples
The Clean Code approach
Today, try to think about meaningful function names instead of reflexively writing comments. If you must comment, follow Clean Code principles for those as well. Perhaps instead of a commented function flow, the Compose Method Pattern might help you more.
