Four rules for effective collaboration – Guidelines for better commits

Re:Four rules for effective collaboration – Guidelines for b... by programmarchy on Wednesday March 07, 2018 @12:13PM (#16537848)

Then why not focus on writing readable code? And when you do need to write a workaround or something hard to understand, then document it in the code itself with a comment. It'll be recorded in the diff of the commit, plus it'll be more accessible when reading the codebase as a whole.

[ Parent | on HN ]

Re:Four rules for effective collaboration – Guidelines for b... by mabbo on Wednesday March 07, 2018 @12:49PM (#16538195)

These aren't mutually exclusive things. Write readable code so people can see how you did it. Write complete commit messages so that people understand why you did it. Especially with older codebase, hairier things you inherit that are full of monsters and WTFs, you need both.

It's more work for you, but it saves the rest of the team even more time. It helps the dev reading it in three years understand, when he git blames to figure out why you did this strange thing.

[ Parent | on HN ]