What is it better to do, code reviews or testing?
Code review or software inspections are used to spot software errors, omissions and anomalies. The code review as the name implies is to look at the source code for errors and defects. To successful perform a code review a team of at least four people must be formed. The roles are:
- Author – programmer: the one who owns the code and is responsible for fixing the errors.
- Inspector: Inspects the code and/or the documentation to find errors – omissions.
- Reader: Presents the code – documentation
- Scriber: Writes the findings of the code review meeting.
- Moderator: Manages the process and facilitates the inspection.
It is very important to keep any questions or comment to the code and not to criticize the developer. When done correctly code review is a positive experience for the team and a learning tool for all levels of developers.
In order to initiate a code review you must:
- Have a complete and precise documentation of the code under inspection.
- The team must know the coding standards that the organization uses.
- The code must be updated and must compile, prior to the inspection. It is a waste of time to inspect code that does not compile.
During one hour of inspection about 120 lines of code are reviewed. It is not recommended for the code inspection to last more than one and a half hours.
It is very important during the inspection to read and translate the code in plain English, based on the specifications. This way everyone can examine the logic and validity of the code.
Why should somebody prefer code reviews from testing?
- During the testing, there is a possibility that an error can mask other errors.
- Testing does not guarantee the code quality and code efficiency.
- In applications that use threading errors cannot be caught with testing but only with a thorough code review.
An advice to software project managers:
I would recommend planning time for code reviews in every project. Code reviews is a great way to mitigate code related risks during the early stages of development.
References and useful links
- Rober Bogue (2006) Effective Code Reviews Without the pain http://www.developer.com/tech/article.php/3579756/Effective-Code-Reviews-Without-the-Pain
- Josh Poley(2007) Best Practices: Code Reviews http://msdn.microsoft.com/en-us/library/bb871031.aspx
- Sommerville I (2006) Software Engineering. Addison Wesley; 8th edition
- Wikipedia (2010) List of tools for static code analysis http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#.NET_.28C.23.2C_VB.NET_and_all_.NET_compatible_languages.29
6 Responses to “Code reviews or testing?”
April 22, 2010
JAY WAGNERI happened to see your post through digg.com.Wow, this is a very good one. very informative.I subscribed to your RSS feed by the way!Thanks, this is really cool!
April 23, 2010
JimI would add preparation from the review team is key:
* Prior to a code review, source code should be presented to the review team so that they can come in to the review prepared.
* If design artifacts are available, the review team should have access to those during their prep work
Then, add that using your tools to take out common hangups for code reviews:
* Static code analysis tools can find normal stuff. I see you’ve got them in your references, but you did not speak to them.
* An IDE can apply a standard code format to code. Don’t let the reviewers get hung up on use of whitespace, where the {}s are, etc. Let the IDE standardize that for the team.
Eclipse will let you distribute an xml of the standard formatting, then you just ctrl-shift-f to format a block or all; vim does the same with =, etc.
Speaking to code reviews with 4 people you’re thinking of the Fagan inspection. http://en.wikipedia.org/wiki/Fagan_inspection
I think both Design and Code reviews are important. Catching problems in Design makes it easier to fix them before they get to Code.
Can you eliminate Test? No, I don’t think so.
Can you eliminate some of what Test should catch by having good reviews? Yes.
May 2, 2010
gbJim, thank you for your input.
You are right I do not mention static code analysis tools in this article.
I will prepare a static code analysis tool article to address this.
For .NET you can use stylecop http://code.msdn.microsoft.com/sourceanalysis creating an XML file with the rules you want to enforce.
May 3, 2010
JimNot a .NET guy, so I don’t know the static testing tools there. My development environment is typically either Eclipse with plugins or vim plus cscope/ctags/valgrind which can handle both my Java and C++ needs.
When you write a static analysis article, don’t just echo Wikipedia. Speak to what works and what doesn’t, as well as what it has changed about how you write code now that a tool has shown you the error of your ways.
May 3, 2010
Jimugh. Static analysis, not Static testing.
March 27, 2017
DominikCavinI see your blog needs some fresh content. Writing manually is time consuming, but there is solution for this hard task.
Just search for – Miftolo’s tools rewriter