I do agree, however, that it gets harder and harder as modern software relies more on very heavy object oriented standard libraries. But the color pens and free form scribbling on paper is still very important to me, although I use code inspection tools as a complement.

Thanks for the feedback and for sharing your thoughts and experience.

I think the most important parts of your comments refers to having a discussion about why a certain piece of code was written in a certain way. When I conduct code and design reviews I have two goals. The first is improving the product under review. The second is enriching the experience of the developers who wrote the code using their own code as the learning material. An open discussion about the code is clearly the way to do this.

I think your approach is great. Keep doing what you’re doing. You’re clearly on the right track, and your team is very lucky to have you as their lead.

Lidor

I currently review SQL stored procedures/functions as well as .Net/VB code. I usually review SQL against our coding standards as well as what I deem to be good practice.

For a .Net code review, I usually require that the code has been FXCop‘d - this cuts down on the search for un-used variables, as well as a certain amount of sloppiness and bad practices, leaving me to concentrate on overall design. I agree that this would be better served in the IDE rather than on paper.

The best code reviews are when we have a discussion about why a piece of code has been written in a certain way.

Great to read other people’s perspectives, thanks for sharing.

You’re completely right. The sooner a review happen the better.

I found weekly code reviews to be the most effective. A week is relatively small interval which allows the code to still be fresh in the developer’s mind. At the same time the code written in a single week is quite manageable from the reviewer’s perspective. A shorter interval might also be good but there is a chance that this will break the development flow.

You’re also right about osmosis. I treat code and design reviews as a mentoring platform: a platform through which knowledge and experience is spread among developers.

I invite you to read about my approach at:
http://lucidquality.qualityaspect.com/Overview/

Thanks for the feedback,
Lidor

One of the best experiences I ever had as a co-op student was spending weeks sitting in code reviews for with some very experienced coders. Osmosis is a great thing.

Much like how Microsoft Word has a mechanism for comments and change tracking from multiple users, it might be nice to have something similiar with an IDE.

Although, with good source control in place, it could be as simple as each person taking turns going over the code and adding comments with some metatags and then checking it in so the next person in the chain could review it, then having a round table at the end of it all.

Basically, you are right. C-style code is more linear in nature than modern object oriented code. However a reviewer can benefit from using an IDE or another code reading tool when reviewing C-style code as well.

With an advanced tool you can easily spot dead code, for example. You can also easily locate variables declaration and usage. And of course you can always use bookmarks to navigate between important lines of code.

All these capabilities are impossible to achieve when reading the code from paper. The fact that code is linear does not necessarily suggest that reading it should be linear too. Especially not for reviewing purposes.

Lidor

With the more object oriented code these days and all the programs in the web environment, I can completely agree with the notion of sticking to an IDE like eclipse that will allow you to follow workflow by clicking through the methods instead of working line for line.