Filter
Exclude
Time range
-
Near
Remember when we put the #CodeReviewTip hashtag out there? It led to some pretty awesome insights. We couldn’t let them be forgotten. So we saved and categorised them all in a GitHub repository👇 reviewpad.com/blog/we-are-st…

4
4
#CodeReviewTip of the Day: Provide reviewers with the sources for the problems you just solved. It can be handy to understand your code. You can do it by documenting your code, or simply by commenting on your own review with those #StackOverflow links.
2
#CodeReviewTip of the Day: Sometimes is good to give a heads-up to the reviewer. You shouldn't do it all the time, but if you know the reviewer is busy, or if you're in a hurry, a heads-up goes a long way.
2
#CodeReviewTip of the Day: Split your pull request. It won't be that complex and it will make the review much easier.
2
#CodeReviewTip of the Day: If you're insecure about a specific part of your pull request, let the reviewers know when you request their review. That way they'll be prepared to give you more focused feedback.
1
2
#CodeReviewTip of the Day: Know when to stop a code review. As you get tired (and distracted) that last stretch of the code review can take ages. Learn to recognize when you're in that situation and consider a break, or simply take it up the next morning.
1
2
#CodeReviewTip of the Day: Anytime there's a useful discussion in a code review consider leaving it documented on the code. If a dev had that question now, probably it will happen again. Of course, if you use Reviewpad these discussions will automatically appear in the review 😉
1
3
#CodeReviewTip of the Day: Expect criticism and suggested changes in your reviews. Code review is a team effort and feedback is what you want to make better code. Don't take it personally, and remember, some developers might not be as nice as you, but that's ok.
1
3
#CodeReviewTip of the Day: Add junior devs as reviewers. You might not get a thorough review, but they will learn a lot.
3
#CodeReviewTip of the Day: Anticipate feedback for your PRs. It's a small thing, but you'll actually catch some bugs and missing things.
1
2
4
#CodeReviewTip of the Day: If you add too many reviewers, there's a high chance they will think somebody else will step forward to do the review.
2
6
#CodeReviewTip of the Day: If you're reviewing a big PR, it might be a good thing to let the author know that you've already started. On the other hand, if you're waiting for a review of your long PR, give the reviewer extra time.
1
3
#CodeReviewTip of the Day: Prioritise readability over fewer lines of code. Code readability is very important for the developer reviewing your code. You might write everything in only one line, but how easy will it be to review?
1
2
#CodeReviewTip of the Day: Develop a code review culture, don't just force one on your team.
1
1
3
#CodeReviewTip of the Day: "Good code is like a good joke: It needs no explanation" @russolsen
4
4
#CodeReviewTip of the Day: The goal code review is to make a better team code, not to make it as if you had written it.
1
3
#CodeReviewTip of the Day: Cut negativity as much as possible. If code reviews are charged with positivity developers will actually look forward to them.
1
1
3
#CodeReviewTip of the Day: The code should fit the project's style, not yours. Have this in mind when suggesting style changes.
3
#CodeReviewTip of the Day: Consider starting the review with a compliment. Developers take pride in their code, and this little tip can go a long way with your teammates.
1
#CodeReviewTip of the Day: Make educated guesses before checking something you’re reviewing. Over time you develop confidence and a sixth sense for bugs and patterns.
1
2