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!
That’s not what I said. I said that comments can often (but not always) be replaced with good and explicit names.
This can be pushed to some extreme by making functions that only get called at a single place in the code, just for the sake of being able to give a name to the code that’s inside (instead of inlining it and adding a comment that conveys the same informations as the function’s signature)
It’s definetly not for everyone, but for beginners/juniors it gives something objective they can aim for when trying to build good coding habits
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”.
That’s not what I said. I said that comments can often (but not always) be replaced with good and explicit names.
This can be pushed to some extreme by making functions that only get called at a single place in the code, just for the sake of being able to give a name to the code that’s inside (instead of inlining it and adding a comment that conveys the same informations as the function’s signature)
It’s definetly not for everyone, but for beginners/juniors it gives something objective they can aim for when trying to build good coding habits
I am going to disagree, comments should be an explanation.
The code is what’s being done, a comment should be why its being done.
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”.