60
Code Smells Catalog
(luzkan.github.io)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Jan 2025
60 points (90.5% liked)
Programming
17756 readers
557 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
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".