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
Do you write a comment before every for loop to explain how a for loop works? Do you write a comment above that to remind the reader that the next few lines are written in, say, Go, just like in the rest of the file? Do you write a comment explaining that the text appearing on the screen is actually digital and will disappear when you turn off the computer?
Obviously you don't, because you assume that the person reading that code has some level of knowledge. You don't say "well, it may not be obvious to everybody, so I need to explain everything".
I guess where we differ is that to me, a professional software developer should be able to understand good code. If they aren't, they are a junior who needs practice. But I am for designing tools for the professionals, not for the apprentices. The goal of an apprentice is to become a professional, not to remain an apprentice forever.