Do you ever read your own pull requests? Or are you more of a >that’ll do< uploader?
I received my first code review with a lot, like a lot of annotations, including typos that I could have caught myself - that was embarrassing.
Since then I have established a short checklist that I follow before I submit a pull request for a code review.
1 Double check every file that I submit
I give myself a nice long break before submitting the PR - if possible I come back to my code on the next day, just so I am the most distanced I can be. Since the person that will review my code will have a very different perspective than I do, This will give me the chance of reading my code as the reviewer. Helping catch any error or unclear line of code that I could not have seen before. Since the person reviewing my PR will have a different perspective than I, this gives me a chance of reading my own code from their point of view. This type of distancing will make it easier to catch errors and any unclear lines of code that I may have missed before.
Bonus: It helps with exactly knowing what you did in this PR in order to write a nice summary.
2 Question variable names
While in the zone, I often don’t think a lot about naming my variables, although I’m not as terrible as just naming them
array. However, Naming variables can be decisive in making your code readable, So therefore the pull request PR is a good opportunity to question my variable names. the choice of names I have given. Same goes for method names - here I take my time and think about if that method might be used in another scope or scenario later and therefore should be named differently.
3 Watch out for typos
Especially if you’re dealing with any kind of text, a transactional email you were drafting, or an automated flash message - double check your spelling.
4 Run a linter
If you haven’t done so, now would also be the time to run a linter checking your style.
Those points might seem obvious, but I am sure following them religiously has spared my reviewers some comments.
Let me know what you are checking before you submit a PR for review.
Top comments (7)
That looks like a good checklist to go through before submitting a PR. We actually had a healthy discussion yesterday about what constitutes a "good" PR, as we're updating our company best practices for the same. One of them is that for new features, adding a GIF of the working feature is mandatory wherever applicable.
I love the ideas of GIFS - when I was at the beginning of my career I was terrified to submit PRs, I guess that would have lighten my mood a little bit.
I really do try to go over my own requests. That way I can check my own coding standards and try to catch any stupid logs I left in there.
Oh yeah, how often do I miss a
What are your own coding standards?
I've left so many
console.logsin code! Bah. For me, I mainly trying to avoid comments that make no sense. Especially when I changed the code to where the code is irrelevant.
We have two different sets of standards. One for the backend (which are PS-4 Symphony's coding standards) and one for the frontend (Airbnb's). They are trying to make it easier for people to read.
Always; plus, using another UI to review my code helps catching stuff I would have otherwise missed