Live data from Hacker News

Ask HN: Do you ever go back and admire a piece of code you wrote?

news.ycombinator.com

211–220 of 267 posts

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#211
post #96

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.

I still think a file should have at least some small comment at the top to help orient the reader and set expectations.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#212

I 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…

I made the script-fu to generate a color hex triplet before it was part of the color dialog box. It was the first time I write scheme as well. I still love scheme even though I never got to use it

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#213
post #90

Earlier 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…

That's a false dichotomy. You can do both. The problem with relying only on commit messages, is that someone examining the code does not see it. You need to dig through the history. People don't do that nearly as often as reading the code.

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?

#214

Earlier 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 :)

Cleverness that hurts readability is not good. Sometimes you can do a lot in a single line without hurting readability (it may even be more readable), but sometimes there's indeed so much to unpack that it's better to show the steps.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#215

All 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…

Of course, when there's a subtle bug in that wonderful, beautiful code, it's a real bear to understand and catch…

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#216

Earlier 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.

I don't really do comments all that often (generally, only for "Chesterton's fence-esque" things) but I do really rely on good commit messages. They are really helpful when going back in history and trying to get a general idea why something changed.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#217
Definitely. I wrote a React application that had a large amount of flexibility requirements for a client. They would need to re-purpose this application to deploy on multiple client sites with a variety of contextual content. I built a sort of navigator wrapper that would allow arbitrary content, but meet a pretty extensive list of contextual requirements as well. It was a fun elegant solution and they were expecting new child pages to take days to add, I showed them how a decent developer could add them in minutes.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#218
post #156

Earlier 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".

I frequently think just before committing/pushing, "Time to add some comments!" That doesn't mean the code is fully finished, but it does provide a clear point in time to add them (when needed).

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#219
post #90

Earlier 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…

Sometimes context should really be next to the code it applies to. If I'm adding pull-to-refresh functionality I might have a commit with ten changed files; there's no reason to put "use a dispatch_async to the main queue here so the animation gets put on the next runloop" in the commit message.

Re: Ask HN: Do you ever go back and admire a piece of code you wrote?

#220
I resonate with the feeling of joy of having translated thoughts into a concrete result :) More often though I find all sorts of loopholes and alternative ways I could've done the same thing. Perhaps, it's because we're viewing an older thought process, and have sufficiently dissociated ourselves with it, so we're able to neutrally critique it.
Post reply on HN