Comment by palata
9 days ago
IMHO, you shouldn't have to justify yourself ("yeah yeah, this is not optimal, I know it because I am not an idiot"). Just write your code in O(n) if that's good enough now. Later, a developer may see that it needs to be optimised, and they should assume that the previous developer was not an idiot and that it was fine with O(n), but now it's not anymore.
Or do you think that your example comment brings knowledge other than "I want you to know that I know that it is not optimal, but it is fine, so don't judge me"?
A little bit of "Don't judge me" and a little bit of "I nearly fell into a trap here, and started writing O(log n) search, but realised that it was a waste of time and effort (and would actually slow things down) - so to save you from that trap here's a note"
The risk with that is that because it was not obvious to you does not necessarily mean it's not obvious to others.
Over the years, I have seen many, many juniors wrapping simple CLI invocations in a script because they just learned about them and thought they weren't obvious.
- clone_git_repo.sh
- run_docker_container.sh
I do agree that something actually tricky should be commented. But that's exceedingly rare.
I mean, the whole point of explicit being superior to implicit is because what's obvious to some isn't necessarily obvious to everyone.
Someone following me could look at it and go.. "well duh" and that's not going to hurt anyone, but if I didn't put that comment and someone refractometer, then we have someone redoing and then undoing, for no good reason.
There's that meme where people are told to update the number of hours wasted because people try to refactor some coffee and have to undo it because it doesn't work
6 replies →