A great article...
In order to be good, you have to realize how bad you are.
Interesting concept. I believe it to be 100% accurate. Everyone makes mistakes, all of the time. I like his overall approach, lots of assertions (now waiting for the emails/comments asking "what's an assertion" :) ), pick a language that makes sense - not one that is "just so cool", and as he says "be a testing masochist".
I would add one thing: make every other line of developed code some sort of debug/trace output, instrument to death. And keep it in for production - they do not actually let you drop in a debug version of your code there, you need to always be running the debug version (just like the Oracle database does...)
I really enjoyed his talk on exception handling. It drives me utterly nuts how people abuse (not use, abuse) error handling. He talks of a team that was plagued by runtime errors, so - what did they do?
... I’d joined a development project where the original developers had so many problems with run-time exceptions that they simply starting including “null exception handlers”, i.e., catch all unexpected exceptions, suppress them, and keep on going. Needless to say, the system would run fine for awhile, sometimes hours, and then slowly start to...hmm..."veer off". ...
Oh, if I could get them to remove "when others" from PL/SQL - I'd be a happy camper (at least in 11g, if you have a when others that is NOT followed by RAISE or RAISE_APPLICATION_ERROR(), the compiler will WARN YOU). You know how many times I've found bugs simply by looking for when others in code? If I had a nickel....
I'll join the chorus of comments on that article - My name is Tom and I'm a terrible programmer :)
(read the comments on that link, it is funny how many people did not get it.)
posted by Thomas Kyte at 10:20 AM
18 Comments:
meh there you go with your preaching on "when others" & instrumentation again
;)
Brilliant link - thanks, Tom.
If I know that I will fail and plan for it, there's a chance that the end result fail less often.
Personally I'm probably just a bad developer and not quite at the terrible level yet - I have this disturbing tendency to try and think out the code before touching the keyboard thus trying to be less terrible :-)
And the Terrible DBA equivalent - you will blow it, always be ready to recover!
I wonder how long until people start baring their souls in job interviews...
word: pigdoqkx
However, in order to profit from your mistakes you have to be aware of them. Goes back to the "Unskilled and Unaware of It" studies from Cornell (http://www.damninteresting.com/?p=406)
Is this article not a long version of : 'always remember Murphy's first law!' ?
The program language one uses has nothing to do with the whole point of the article.
Reagrds,
Rob Zijlstra
Okay, Tom.
Define assertions in the context of the article.
Define assertions in the context of the article.
in C, it would look like the following for a routine that expected a number between 1 and 5 as input:
[tkyte@dellpe ~]$ cat test.c
#include "stdlib.h"
#include "assert.h"
void foo( int x )
{
assert( x >= 1 && x <= 5 );
printf( "X=%d is OK!!\n", x );
}
int main( int argc, char * argv[] )
{
foo( 1 );
foo( 0 );
return 0;
}
[tkyte@dellpe ~]$ ./test
X=1 is OK!!
test: test.c:6: foo: Assertion `x >= 1 && x <= 5' failed.
Aborted
[tkyte@dellpe ~]$
the assertion failed, the program automagically bails - we got into a situation whereby we could not recover.
the equivalent of an ora-600
I like the reference to Ada - what is the mother of PL/SQL? Yes - Ada. And PL/SQL has most of Ada's good points.
I liked that article - but I do know several developers who would have complete reversed that C++ and Java comment. Java allows you to do some funny things and C++ is the "better" language. Anyone have a comment about that? I don't know..
Tom you must be thinking twice before putting such statements
“My name is Tom and I'm a terrible programmer :)” …
I can end it like this
“And that’s why I always put lots of bug in my code :( ...”
It some time’s becomes an excuse for our mistakes. Which is unacceptable right? We all are developers and we make our living by that and we should be good in what we do and always look to be “better”. BETTER is the work we should be holding on to.
I would like to say
“I am Karthick, and I am looking forward to become a better programmer today than what I was yesterday :)”
Also never believe on best there is nothing like that it’s just a myth.
One of the comments in the blog you referenced mentioned "Code Complete" by Steve McConnell.
This is a fantastic book. Anyone that writes any kind of code should have a copy, and read it.
Personally, I know I need to read it again. :)
This book focuses on C as a programming language, but the lessons taught go far beyond C.
to anonymous who wrote "I am Karthick"
I'm pretty sure you missed the point of the article.
The author is one of the best programmers out there.
The kind that knows they make mistakes.
The kind that knows "stuff happens - DO NOT HIDE IT WITH BAD EXCEPTION HANDLING"
The kind whose code I would not mind inheriting.
The kind with a spot of humbleness.
You entirely missed the point if you think the statement "and I'm a terrible programmer" was an excuse.
I think you either entirely did not get it - or - you did not read the article at all.
If you want to achieve the goal you stated:
"I am Karthick, and I am looking forward to become a better programmer today than what I was yesterday :)"
You should immediately go back, re-read that article, implement the ideas in it, add a heavy dose of instrumentation and you'll be well on your way.
He is simply saying "we make mistakes, we are not perfect, we should code DEFENSIVELY therefore".
And he is about as correct as a person can be.
Excellent...
Hi Tom, sorry off-topic here, but I saw this and thought of you...
http://xkcd.com/327/
Tom (or anyone): in PL/SQL when you have debug/trace/instrumentation every line or so, um, can you be more specific?
How do you turn it off and on in production?
Do you read a value in a debug table?
if #debug = TRUE then (do_stuff) end if;
Do you use DBMS_OUTPUT? (I doubt it) Preprocessor directives (unlikely) Recompilation?
-Steve
I use a 'hand written' package debug - with a "f" function (written up in Beginning Oracle Programming and Expert one on one Oracle).
today, you might use
log4plsql a bit of freeware.
WHEN OTHERS THEN...
If anybody thinks of ending that with "NULL" they should be shot on sight. Or at least be shown the error of their ways.
HOWEVER that doesn't mean the clause shouldn't exist.
I use the WHEN OTHERS clause to call my logging function [which wraps log4plsql :) ] with diagnostic information that would be useful in a production setting (i.e. when my log level isn't set to DEBUG).
And then I RAISE :)
Phil said...
Oh, trust me, I know there are valid uses of WHEN OTHERS
Just like there are valid uses of triggers.
Just like there are valid uses of autonomous transaction.
However, they are so universally misapplied - that the quality of code every where would rise a bit if they did not exist.
As the cliché goes "Just enough rope to hang themselves with..."
POST A COMMENT
<< Home