devmarks.io
Collections Pricing Login with GitHub

Create your own public collection of bookmarks to share with others by logging in with GitHub.

All Collections

code reviews

8


 

Bookmarks

Doing code review · Matt Layman

5 years, 9 months ago

Read more 

For Delightful Code Reviews, Say Nice Things

Read more 

How to Do Code Reviews Like a Human (Part One)

5 years, 11 months ago

Code reviews are an opportunity to share knowledge and make informed engineering decisions Arguments about style are a waste of time in reviews. A good style guide defines not only superficial elements like naming conventions or whitespace rules but also how to use the features of the given programming language More ▼ Code reviews are an opportunity to share knowledge and make informed engineering decisions Arguments about style are a waste of time in reviews. A good style guide defines not only superficial elements like naming conventions or whitespace rules but also how to use the features of the given programming language If you encounter a style issue your guide doesn’t cover and it’s important enough to discuss, hash it out with your team Treat code reviews as a high priority 🤯 I’ll often create my own branch of the code to demonstrate a large proof of concept to the author, such as breaking up a large function or adding a unit test to cover an additional edge case. never use the word “you” in a code review. Replace ‘you’ with ‘we’ Frame feedback as requests, not commands People like to feel in control of their own work. Making a request of the author gives them a sense of autonomy. When you give the author a note, explain both your suggested change and the reason for the change. Provide supporting evidence where possible in the form of links Less ▲
Read more 

How to Make Your Code Reviewer Fall in Love with You

2 years, 9 months ago

Notes from the article that I think are worth highlighting: Before sending code to your teammate, read it yourself. Don’t just check for mistakes — imagine reading the code for the first time. What might confuse you? Pay attention to your patterns of error, and think about creating systems to More ▼ Notes from the article that I think are worth highlighting: Before sending code to your teammate, read it yourself. Don’t just check for mistakes — imagine reading the code for the first time. What might confuse you? Pay attention to your patterns of error, and think about creating systems to prevent them Your changelist description should summarize any background knowledge the reader needs When your reviewer expresses confusion about how the code works, the solution isn’t to explain it to that one person. You need to explain it to everyone. [https://mtlynch.io/code-review-love/late-night-question.jpg](https://mtlynch.io/code-review-love/late-night-question.jpg) Separate functional and non-functional changes The fastest way to ruin a code review is to take feedback personally. Be patient when your reviewer is wrong. Even when your reviewer is mistaken, that’s still a red flag. If they misread it, will others make the same mistake? Establish conventions on your team that make it clear who’s “holding the baton” at any point. Whenever a reviewer gives me unclear feedback, I always respond with some variation of, “What would be helpful?” Once you send your code out, driving the review to completion should be your highest priority. Remember the golden rule: value your reviewer’s time. Less ▲
Read more 

Why code review beats testing: evidence from decades of programming research | Kevin Burke

11 years, 11 months ago

The key part of this article is expressed in the Conclusion: If you want to ship high quality code, you should invest in more than one of formal code review, design inspection, testing, and quality assurance. Testing catches fewer bugs per hour than human inspection of code, but it might More ▼ The key part of this article is expressed in the Conclusion: If you want to ship high quality code, you should invest in more than one of formal code review, design inspection, testing, and quality assurance. Testing catches fewer bugs per hour than human inspection of code, but it might be catching different types of bugs. You should definitely try to measure where you are finding bugs in your code and the percentage of bugs you are catching before release – 85% is poor, and 99% is exceptional. Less ▲
Read more 

The Standard of Code Review

I’m adding this mostly for completeness sake. The document talks a lot about `CL` and links to other pages that talk about `CL` without EVER explicitly stating what they actually are. Because of that I’m not sure that this is the best article on Code Reviews but 🤷🏼‍♂️
Read more 

◉ Writing Reviewable Code

The complexity of understanding, testing and reviewing a change often increases faster than its size: ten 200-line changes each doing one thing are often far easier to understand than one 2,000 line change doing ten things. The minimum size of a change should be a complete implementation of the simplest More ▼ The complexity of understanding, testing and reviewing a change often increases faster than its size: ten 200-line changes each doing one thing are often far easier to understand than one 2,000 line change doing ten things. The minimum size of a change should be a complete implementation of the simplest subproblem which works on its own and expresses an entire idea, not just part of an idea. The single most important thing is: commit messages should explain why you are making the change. * Have a title, briefly describing the change in one line. * Have a summary, describing the change in more detail. * Maybe have some other fields. the summary should explain why you're making the change and why you're choosing the implementation you're choosing I disagree with this bullet point: * Other sorts of pedantry not related to getting the context and reasons why a change is happening into the commit message. Less ▲
Read more 

ramblings on code review

Highlights from the article: If you let code go unreviewed, you are explicitly prioritizing your productivity over the productivity of the rest of the team. If you have nothing to say, then say that! If your name is on a review, you should at least acknowledge it with something like More ▼ Highlights from the article: If you let code go unreviewed, you are explicitly prioritizing your productivity over the productivity of the rest of the team. If you have nothing to say, then say that! If your name is on a review, you should at least acknowledge it with something like "LGTM, but I don't really know this code well." Minimally, your day should begin and end with clearing your code-review backlog In exchange for your reviewers making code review their top priority, make sending out a good code review yours. Do your best to acknowledge comments as quickly as you can, and particularly to ask for clarification if you don't understand the comment or want to push back on it. Less ▲
Read more 
  • 1

devmarks.io is Bookmarking for Developers. Automatically sync all your developer resources to one place.

Login with GitHub
  • Collections
  • Articles
  • Built by @adamghill
  • Unicorn,
    Coltrane, &
    django-fbv
  • Django
  • Feather Icons
  • Hero Icons
  • Bulma CSS
  • About
  • Pricing
  • Terms of Service
  • Privacy Policy