Comments on: You think your code don’t smell? http://www.hackinghat.com/index.php/article/you-think-your-code-dont-smell Wed, 01 Feb 2012 14:27:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Steve Knight http://www.hackinghat.com/index.php/article/you-think-your-code-dont-smell/comment-page-1#comment-1753 Steve Knight Thu, 15 Nov 2007 12:06:56 +0000 http://www.hackinghat.com/index.php/article/you-think-your-code-dont-smell#comment-1753 Hi Dion, >> I think your manager had the right idea, but had some implementation issues He had more than just implementation issues ;-) I agree with you about the complementary nature of reviews and testing. Indeed with the right tests and the right review the process should be pretty good. Perhaps the missing piece (to me at least) is that a review should where appropriate include new or updated tests. Hi Dion,

>> I think your manager had the right idea, but had some implementation issues

He had more than just implementation issues ;-)

I agree with you about the complementary nature of reviews and testing. Indeed with the right tests and the right review the process should be pretty good. Perhaps the missing piece (to me at least) is that a review should where appropriate include new or updated tests.

]]> By: Dion Dock http://www.hackinghat.com/index.php/article/you-think-your-code-dont-smell/comment-page-1#comment-1741 Dion Dock Wed, 14 Nov 2007 18:58:34 +0000 http://www.hackinghat.com/index.php/article/you-think-your-code-dont-smell#comment-1741 A poor code review is as helpful as a poor test. I don't think we should throw away the idea of reviewing based on bad reviews, and I don't think we should quit testing because a test didn't find a bug. Testing the program (or running it) finds a certain set of problems. Looking at the code finds another set. Done well, the two complement each other. I think your manager had the right idea, but had some implementation issues. (The greatest problem being, are they giving you an opinion that you can decline or an order that you must follow?) My experience with code reviews is * I find a bunch of things just preparing for the review. It forces me to look at before and after. * Someone reads the comments cold and tries to make sense of them. That's what's going to happen in 6 months. * Devs can't hide the "how". You might be really impressed that their bug tracker is working in a week, until you find out that it only runs on a machine named "potrazeebee" under user account "jsmith". You can't hide that from a review. A poor code review is as helpful as a poor test. I don’t think we should throw away the idea of reviewing based on bad reviews, and I don’t think we should quit testing because a test didn’t find a bug.

Testing the program (or running it) finds a certain set of problems. Looking at the code finds another set. Done well, the two complement each other.

I think your manager had the right idea, but had some implementation issues. (The greatest problem being, are they giving you an opinion that you can decline or an order that you must follow?)

My experience with code reviews is
* I find a bunch of things just preparing for the review. It forces me to look at before and after.
* Someone reads the comments cold and tries to make sense of them. That’s what’s going to happen in 6 months.
* Devs can’t hide the “how”. You might be really impressed that their bug tracker is working in a week, until you find out that it only runs on a machine named “potrazeebee” under user account “jsmith”. You can’t hide that from a review.

]]>