Earlier quoted context omitted.
100%. It's amazing how many GitHub repos have little to no comments, not even file or function overview comments. The amount of time save by potential contributors reading and having to interpret the code is way longer than it would take for the author to write the comments in the first place. To each their own, but comments are generally a positive addition to code.
I think there are levels: Level 1: Garbage code with no or bad comment. Level 2: Garbage code with good comments. Level 3: Good code with comments Level 4: Code good enough that it doesn't need comments, with rare exceptions. Each level is better than the previous. You can't level up directly from 1 to 4. Still, 4 is the best level. I know it sounds weird if you haven't seen it.
Ask HN: Do you ever go back and admire a piece of code you wrote?
211–220 of 267 posts
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#212I have some stories about old code but this is a nice one: in my old job I've needed to write technical documentation about a GUI we had developed. This consisted in making numbered labels in pictures using Gimp, embedding the pictures in a LibreOffice document (at the time, OpenOffice) and writing what each item was about. I soon got tired of drawing circles and numbers and decided to write a quick Gimp plugin that…
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#213Earlier quoted context omitted.
Too many comments explain what is going on. That should be obvious from well-written code. But comments why it's done that way can be extremely valuable. And sometimes there is indeed something wrong with the code. In those cases, a comment saying so can save a lot of time analyzing what's wrong with the code.
The counter-argument I've heard is that commit messages are a better tool for those kinds of annotations, especially if there are multiple points across the codebase where a change was made for the same reason. That's exactly what commit messages are designed to do, too. I've seen plenty of comments in code that say "handle case X because of behavior in place Y", that's tied to changes in place Y. I find it more mean…
But if you leave a comment with what the issue is, and add a reference to the commit message, you've got the best of both worlds.
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#214Earlier quoted context omitted.
I came to write basically this exact thing FWIW. Always write the why, not the what. It's the clear difference between useful comments and excess noise.
There are particularly clever one liners that need a bit of unpacking on the what - Python is bad for this but anytime you are patting yourself on the back for the cleverness, a brief note (at least on the test) is probably warrented. I supposed one can code without cleverness but it's less fun :)
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#215All the time. The old joke is about us looking at code we wrote six months ago, and being horrified at what we see. And I've had more than my share of that. But what's ALSO happened, many times, is I look at old code I wrote... and I'm IMPRESSED. Just blown away by the beautiful elegance and power of the abstractions I came up with, the sheer intelligence of the approach, the insight and lucidity oozing from the code…
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#216Earlier quoted context omitted.
On a bit of a tangent here, but good commit messages are another thing I really appreciate 6 months later.
I love good commit messages as well, but it can be hard to convince people to write them. I always hear "Why? i don't use them" which is self propelling. You don't have good messages, so you don't read them when you want to know something, so you don't write good commit messages.
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#217Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#218Earlier quoted context omitted.
I find it's not useful to have comments in code that you are actively working on since they quickly get out of date. They are best added when one finishes work on a block of code.
I get the feeling, but I rarely think "I'm completely done now, time to comment!" Better to admit that and document a bit earlier than when it's "finished".
Re: Ask HN: Do you ever go back and admire a piece of code you wrote?
#219Earlier quoted context omitted.
Too many comments explain what is going on. That should be obvious from well-written code. But comments why it's done that way can be extremely valuable. And sometimes there is indeed something wrong with the code. In those cases, a comment saying so can save a lot of time analyzing what's wrong with the code.
The counter-argument I've heard is that commit messages are a better tool for those kinds of annotations, especially if there are multiple points across the codebase where a change was made for the same reason. That's exactly what commit messages are designed to do, too. I've seen plenty of comments in code that say "handle case X because of behavior in place Y", that's tied to changes in place Y. I find it more mean…