Although you can get by doing live code reviews, I've found that using code review software has generally made my code reviews much more productive. There aren't a ton of code review software packages out there, but some of them are outstanding.
If you're
For those who attended this week's Nashville Java Users' Group and were interested in reviewing the slides from my lightning talk on Code Reviews, I put them up on SlideShare. For convenience, I'm also embedding the presentation here.
While preparing for that presentation, I also realized that I've got a few gaps to fill in from the initial series on code reviews, so I'll be adding to that series over the coming weeks.
Most of the time, I prefer using tools like Crucible for conducting code reviews because they allow you to think through the code on your own time, at your own desk. You can read a chunk of code, think about it, scroll around the file, and if you're so inclined, comment on it. And the next person can do the same.
But there are times when a code review needs to be done in person. Maybe you don't have code review software, or maybe the code change is urgent. For those cases,
Many development teams spend an inordinate amount of time arguing over styling and formatting preferences, such as:
Although these preferences are somewhat subjective, there's something to be said for consistency. Imagine you're reading a book where one page is double spaced and the next is single spaced. On one page, important terms are bolded, and on another page, important terms are underlined. As a reader, those types of inconsistencies can get between you and the content of the book. Likewise, in code, these types of styling and formatting preferences do make a difference.
Since styling comes up frequently during code reviews, it's a good idea to have a strategy in place for dealing with it. Here are three levels of maturity for dealing with code formatting on a development team.
Welcome to the second part in a series on best practices for code reviews. Last time, I explained why I believe it's important for everyone on the team to chime in on code reviews -- rather than having a single gatekeeper, it's important for everyone to share that responsibility.
Today I'm discussing the flip side of the coin -- everyone's code should be subject to review. I believe even the technical leads should submit their code for review. Of course, it's tempting to let their code slip by because, hey, if they don't write code that passes the team's standards, then who the heck does?!
But there are actually very good reasons to subject even the technical lead's code to review. Here are three of them:
Most programmers agree that it's easier to prevent technical debt than it is to pay it off. And one of the best ways to prevent sub-par code from ever seeing the light of day on a production box is to have a solid code review system in place. Over the years, I've discovered some practices that have really made a difference for me. Here's the first in a series.
Although it's traditional to have the technical lead be the "gatekeeper of the code", I believe everyone on the team should participate by reviewing the code. Here's why:
