[-] nthcdr@emacs.ch 1 points 1 year ago* (last edited 1 year ago)

@TerrorBite

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.

@257m @programming

[-] nthcdr@emacs.ch 5 points 1 year ago* (last edited 1 year ago)

@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

joined 2 years ago