Don’t write comments in the code!

Hold Your Horses: Why Comments Aren’t Always King

Comments are like sprinkles on your code sundae. They can add a bit of flavor and make things prettier, but you don’t want a codebase buried under a mountain of them.

While comments are ingrained in many programmer’s minds, there’s a growing movement towards clean, self-documenting code. Here’s why comments might not be the hero you think they are:

• Stale Comments: Code evolves, comments often don’t. A comment explaining a piece of code can become outdated and misleading if the code itself changes. This creates a maintenance nightmare!
• Noise vs. Clarity: Too many comments can clutter the code, making it harder to read and understand the actual logic.
• The Code Should Speak for Itself: Ideally, well-written code with descriptive variable names and functions is clear enough on its own. Comments should explain the “why” behind the code, not just the “what.”

But aren’t comments ever useful? Absolutely! Here are some times when comments can be your code’s best friend:

• Complex Algorithms: If you’re dealing with particularly tricky logic, a comment can unpack the thought process for future readers.
• Non-Obvious Choices: Explain why you chose a specific approach over another, especially if it might not be immediately apparent.
• Context for External Code: If you’re integrating external libraries or frameworks, comments can help explain their purpose and usage within your codebase.

The key takeaway? Comments are a tool, use them judiciously. Strive for clean, well-structured code that speaks for itself, and add comments only where they provide real value and clarity.

This guy has been making awesome videos, here this one is about comments. In a legacy project I am working now, there are tons of comments. When I see lots of comments, i can conclude that the code has no design.

Here is one about Dependency Injection, nicely explained.