3 ms·
Imo the big takeaway from the story is that the code probably needed an explanation (aka comment) to prevent others for making the same faulty assumption that t
by cjblomqvist 6y ago
Imo the big takeaway from the story is that the code probably needed an explanation (aka comment) to prevent others for making the same faulty assumption that the images were inlined for no reason and wasting the same amount of time "refactoring".
In other words, it could/needed still to be improved for better maintainability, not just in the obvious way (Chesterton's fence, as mentioned by another commenter)
- rawoke083600 6y agoYea, there are many schools of thought on what/how to comment "properly". But I have found this simple rule to cover most of the cases, it's not perfect but better than most: "The code is the HOW, the comments are the WHY"
- TeMPOraL 6y agoThat's a good rule of thumb. Personally, I also add comments for the HOWs that may be relevant to users of a function/class, that cannot be easily expressed in code in the function signature or class declaration. Things like, "relative ordering of results is not preserved", or "this function is O(n^3)".