3 ms·
> To make sure you don’t forget, you quickly add a comment explaining why event.stopPropagation() is there. You are hopeful that it will help save time for some
by tetha 4y ago
> To make sure you don’t forget, you quickly add a comment explaining why event.stopPropagation() is there. You are hopeful that it will help save time for someone in the future. That future someone might even be you.
This is something I've been training and forcing myself to do. If I spend 10 - 15 minutes thinking about some piece of code or infrastructure to understand why it's here and what it does... add whatever you learned and found out as a comment. Even, or especially if it wasn't fruitful, and your only answer is "the system is being weird here in the following way, and this mess is here to fix it, kind of, in most cases - and since you're here, I guess not in this case".
- hvs 4y agoI admit that I'm a terrible (descriptive) code commenter and that is after 25+ years as a professional programmer, BUT I always try to add a comment when I add some weird code to fix an odd bug or add some special case. And I can confidently say that pretty much every descriptive comment I've ever written was out-of-date shortly after it was written, but the "hey, this weird because of X and if you think you are going to optimize or fix something you need to be aware of this special case" have saved me numerous times.
- LilBytes 4y agoExactly, same here. I'll add a small amount of documentation to the actual code with a reference to a #Gotchas header or equivalent in the readme with verbose detail. Some times design decisions aren't immediately obvious but should be explained for both future colleagues and you.