Writing Well-Documented Code – Learn from Examples
codecatalog.org
Writing Well-Documented Code – Learn from Examples
1–10 of 153 posts
Re: Writing Well-Documented Code – Learn from Examples
#2Re: Writing Well-Documented Code – Learn from Examples
#3The 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
Re: Writing Well-Documented Code – Learn from Examples
#4The 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
Re: Writing Well-Documented Code – Learn from Examples
#5These 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[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
#7Re: Writing Well-Documented Code – Learn from Examples
#8Re: Writing Well-Documented Code – Learn from Examples
#9The 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
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
#10If 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.