Live data from Hacker News

Writing Well-Documented Code – Learn from Examples

codecatalog.org

1–10 of 153 posts

Re: Writing Well-Documented Code – Learn from Examples

#4

The first has an enormous amount of visual noise and it's definitely over commented. The second one is ok, but please don't follow the first one as a good example, it takes away the ability to scan the code

The "first things first" comment was bad, but I'd rather have it + the other comments than have none of them.

Re: Writing Well-Documented Code – Learn from Examples

#5
some types of comments are redundant.

These days I write my code as comments first and then write the code.

But for example this one

        // If either token bucket capacity or refill time is 0, disable limiting.
        if size == 0 || complete_refill_time_ms == 0 {
            return None;
        }
The comment is the same as the code. It is pointless. Instead I might say under what circumstances I expect them to be zero or why Im disabling limiting when they are zero.

This one is great, though at first glance I cant relate the actual code to the comment, at least I understand why the code is there.

            // We still have burst budget for *some* of the tokens requests.
            // The tokens left unfulfilled will be consumed from current `self.budget`.
            tokens -= self.one_time_burst;
            self.one_time_burst = 0;

Re: Writing Well-Documented Code – Learn from Examples

#6
Speaking of source code comments, antirez (of Redis fame) wrote a fantastic article[0] about that topic some time ago and I still recommend it to colleagues whenever they make the hollow statement that "code should and can be intelligible on its own, without any comments".

[0]: https://web.archive.org/web/20210226004600/http://antirez.co... (I still don't understand why he deleted his blog)

Re: Writing Well-Documented Code – Learn from Examples

#9

The first has an enormous amount of visual noise and it's definitely over commented. The second one is ok, but please don't follow the first one as a good example, it takes away the ability to scan the code

> The second one is ok, but please don't follow the first one as a good example, it takes away the ability to scan the code.

IMO if at all, this type of comment ("Why was X designed this way") should go to the very bottom of the file (maybe with a very short comment at the top of the file referencing it), so it doesn't bother anyone who works on the code on a regular basis. And one could (should) also decrease its verbosity.

EDIT: Confused first and second example

Re: Writing Well-Documented Code – Learn from Examples

#10
A lot of this I find to be kinda bad commenting, you've got to remember NOT to just directly comment on what the code is doing, but rather explaining why. With future updates your comments will eventually be wrong if they do anything other than give context.

If all your comment does is say what the code on the next line is doing, don't. Instead just try to make the next line more readable.

Post reply on HN