A collection of Bad Code Smells in a Catalog form for Developers & Researchers. Code Smell is a typical bad code implementation, and learning these concepts immiedietly makes you a better developer!
I’m not sure how we disagree. At least, I don’t disagree with you. My whole comment was talking about “what” comments. “Why” comments are a very good thing to have where they’re needed
Let’s rephrase my opinion, so that we can (hopefully) agree on something : What I’m arguing against is the “ChatGPT-style” (or “tutorial-style”) comments that I’ve seen all over juniors’ code, even before LLMs got widespread
The “why”. Useful. Shows the purpose, and explains the context it may be used in.
Assuming the “why” is known is the mistake - and one I see from junior and mid level, I dont care what language it is, its the same. Using refactoring code as an example, without context - the why - can cause problems. What may be more efficient for one resulting value being presented can cause issues for others (let’s say precision as an example of why it could be a problem). Failing to include why something is being done is usually what introduces these problems, someone misses a different context than what they are looking at, and that belongs in a comment.
A comment on “why” isn’t just important - for any block of code - it is, IMO, a requirement. I have and will continue to respond with “add comments as to why and resubmit”.
I’m not sure how we disagree. At least, I don’t disagree with you. My whole comment was talking about “what” comments. “Why” comments are a very good thing to have where they’re needed
Not updating comments with code is what I’m talking about - that’s not a comment problem, thats a programmer problem.
If they aren’t updating the “why”, that programmer is the problem, not comments.
When refactoring, it’s often the “what” that changes, not the “why”
That really depends.
Especially for a function that may see use in a variety of scenarios.
I’m going to be firmly against anyone suggesting against proper comments - which, I’m sorry, but you are by your own statement.
Code will change for many, many, many reasons beyond just refactoring.
Edit: and why it was refactored is important as well.
There are just so many reasons, and yes, I will continue to be against this newer trend of “dont comment, make codes your comments”.
All that is, is a great way to make your code harder to manage later. It doesnt take much effort to explain why you’re doing something.
Let’s rephrase my opinion, so that we can (hopefully) agree on something : What I’m arguing against is the “ChatGPT-style” (or “tutorial-style”) comments that I’ve seen all over juniors’ code, even before LLMs got widespread
“Adds a and b”?
Sure, not useful. Thats a what, not a why.
“Combined value needed for these outputs”
The “why”. Useful. Shows the purpose, and explains the context it may be used in.
Assuming the “why” is known is the mistake - and one I see from junior and mid level, I dont care what language it is, its the same. Using refactoring code as an example, without context - the why - can cause problems. What may be more efficient for one resulting value being presented can cause issues for others (let’s say precision as an example of why it could be a problem). Failing to include why something is being done is usually what introduces these problems, someone misses a different context than what they are looking at, and that belongs in a comment.
A comment on “why” isn’t just important - for any block of code - it is, IMO, a requirement. I have and will continue to respond with “add comments as to why and resubmit”.