Re^2: Perl Best Practices book: is this one a best practice or a dodgy practice?

"guess it's just as well that Chapter 18 suggests testing everything before you deploy it! ;-)"

It is kind of far-fecthed to talk about testing here. The best practice is to find "bugs" as earlier as possible, the later they are found/fixed, the higher the cost is.

The particular bad practice that we are discussing in this case, can be easily spotted as early as specification review (if the process requires one to document such details), or at least during peer code review. If a simple issue like this can actually pass all the guarding processes and go as far as testing, the processes should be reviewed.

Update: Read TheDamian's reply, now I have seen that big ;-) Okay, my fault, please ignore my first sentence in this post.

Comment on Re^2: Perl Best Practices book: is this one a best practice or a dodgy practice?

Replies are listed 'Best First'.
Re^3: Perl Best Practices book: is this one a best practice or a dodgy practice? by TheDamian (Vicar) on Sep 03, 2005 at 04:38 UTC
It is kind of far-fetched to talk about testing here. Hmmmmm. Maybe I didn't make the smiley big enough. Let's try again: guess it's just as well that Chapter 18 suggests testing everything before you deploy it! `;-)` The point I was trying to make is not that you should rely on the testing to catch this problem, but that, if you don't catch the problem earlier, the testing phase should still do so. In other words, (just exactly as you say) best practices ought to be an integrated process, so even if one practice introduces a problem, another practice should catch it. Which is precisely what my book advocates.	[reply]
Re^3: Perl Best Practices book: is this one a best practice or a dodgy practice? by kscaldef (Pilgrim) on Sep 03, 2005 at 04:32 UTC
One hopes that programmers do at least some testing _before_ code review.	[reply]


Syntactic Confectionery Delight
	PerlMonks