Yes there need to be some assumption that your co-workers write reasonable commit message even if they have their lapses now and then.
Another problem with comments in code is that they tend to be short because nobody likes to read code interspersed by walls of prose. But many times if something really needs explaining you also need a little more room doing it. Thus when committing in code people tend to gloss over important detail.
Then of course there is literate programming. The other end of the spectrum, but then we're talking code in documentation not comments in code.
@TerrorBite @257m @programming
Comments are for revision control systems. We have a strictly no comments in code policy because comments too often end up being wrong or misleading throwing everyone believing in them for a wild ride. The only thing that is worse than bad code is bad comments.
When you read sensible and thorough commit messages you generally have the notion that whatever it says was probably true at the time of the commit, whereas when you read comments in code it can still be correct or just plain utterly wrong.
nthcdr @emacs.ch Long time Emacs user who tries to battle 21th century complexity with the help of parenthesis.
I'm also passionate about: archery, art and spicy food among other things.
In the future I will: live in a remote tiny house.
I am an optimistic nihilist.