76
Self-documenting Code
(lackofimagination.org)
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 21 Oct 2024
76 points (85.2% liked)
Programming
17241 readers
263 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 1 year ago
MODERATORS
Fair. I guess in this case, it's a manner of gauging who you're working with. I'd much rather answer a question once in a while than over-comment (since refactors often make comments worthless and they're so easy to miss..), but if it's a regular occurrence, yeah it would get on my nerves. Read the fuckin name of the function! Or better yet go check out what the function does!
Worse, refactors make comments wrong. And there is nothing more annoying then having the comment conflict with the code. Which is right? Is it a bug or did someone just forget to update the comments... The latter is far more common.
Comments that just repeat the code mean you now have two places to update and keep in sync - a pointless waste of time and confusion.
Yes- exactly, they make comments wrong. But comments aren't always a waste of time, like in legacy code, or just in general code that isn't gonna change (mathematical equations too)
Comments are not always a waste of time, but comments that repeat or tell you what the code is doing (rather than why) are a waste. For legacy code you generally don't have comments anyway and the code is hard to read/understand.
But if you can understand the code enough to write a comment you can likely refactor the code to just make it more readable to start with.
For code that does not change generally does not need to be read much so does not need comments to describe what it is doing. And again, if you understand it enough to write a comment to explain what it is doing you can refactor it to be readable to begin with. Even for mathematical equations I would either expect the reader to be able to read them or link to documentation that describes what it is in much more detail to name the function enough that the reader can look it up to understand the principals behind it.
You make some great points. Using smaller functions and breaking up your code in readable bits makes a huge difference and you will likely never need comments if you do it right ๐๐ป
Creating functions is IMO not the first thing you should do. Giving variables better names or naming temporaries/intermediate steps is often all you really need to do to make things clearer. Creating smaller functions tends to be my last resort and I would avoid it when I can as splitting the code up can make things harder to understand as you have to jump around more often.
I hear ya. As always, it's a balance between having functions that are too long, and many too small functions. Matter of team preferences too.