Pre-pull request self code review: Why did I call this function that? Why did I put those functions in this file instead of that file where they obviously belong? This other block clearly doesn't do what the spec defined. Guess I'll wait on that pull request then.
1
1
Programming is a lot like sending an email. Read what you wrote three times before sending.
3
2
That you do that pre-PR code review for yourself is a wonderful thing. Encouraging my colleagues to actually *look* at what they're proposing before they ask others to review it has been a theme of my last 2 years of work :D
2
1
1
There's no point trying to rush things through. Being un-thorough will just make the PR review throw up hundreds of comments and requests for change. I'm also a stickler for good commit messages. I generally reject one-liners.
1
Replying to @jogbert
Heck yes, good commit messages are valuable, though sometimes a one-liner is sufficient tbf. What I hate is people who don't clean up their commits, I view commits as a way to break down a change to understand it better; and as a forward-view to when you have to `git blame`.

Jan 23, 2020 ยท 11:06 AM UTC

1
Replying to @dsilverstone
Oh sure, there are times when one-liners are fine don't need more clarity. More often I see colleagues rewrite an entire feature and don't explain it in the commit. I write them for "future me" because I won't remember why I did a thing.
1
1
Past me was a dick who wrote bad commit messages. Present me is trying to do better so that future me doesn't hate present me quite so much when he's past me :D
1
1
more replies