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
Replying to @jogbert
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

Jan 23, 2020 ยท 10:57 AM UTC

2
1
1
Replying to @dsilverstone
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
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`.
1
more replies
Replying to @dsilverstone
I should also note I got into the habit of using `git add -p` to review what I'm committing and stage chunks at a time, then `git diff --cached` to be really sure before I commit :-)
1
That is a good technique, and something I use too :D
1
more replies