We've all been guilty of giving a shallow review: "Looks ok."
Given typical defect densities, any non-trivial design or code is going to contain some errors. Even seemingly trivial maintenance fixes are likely to be defective.
It's your job as a reviewer to find as many of these ...
This is the second half of an article I posted about using a checklist to prevent security errors. There, I said that you have 15 checklist items max, and you shouldn't waste any of those questions on silly things like "Does the code follow the coding standard?".
The 2009 CWE/SANS Top 25 Most Dangerous Programming Errors has been out for a while now. Maybe you've already eliminated all of these errors from your code. In case you haven't, this post will help you develop a checklist that you can use to eliminate these errors ...
Yesterday I posted twenty reasons to do code reviews, and I promised a list of code review tools. Here they are, in no particular order. I have not used all of them, so I can't comment on their relative merits. If there are some I missed, please leave a ...
Update [2008-12-31]: I posted the list of code review tools as promised below.
I tweeted this article on Five Reasons to Do Code Reviews from CIO.com last week,and realized that there are much more than the five reasons they give. So I came up with 20 more over ...
Great post on the cost of (not) testing software. The take-home lesson is "find defects early".
The main thing missing from the discussion is that there are better techniques for finding defects than testing. Like design and code reviews, and especially more attention to requirements. Catch defects as early as ...
Page 1 / 1