Good programming as seen in: Fw: Is this possible in Python ?

[Chad Netzer]

On Sat, 2003-05-17 at 23:49, King Kuta wrote:

> I have to say thouhg that Chad answer (read fwd attachment, plz...) caught
> me a bit off guard.
> No "debbugging" ? Wow that sounds heaven if OOP could save me taht....

Alex was able to respond before I read this (A *beautiful* weekend, so I
wasn't reading the newsgroup).  And his points stand.  It isn't OOP that
will save you from debugging.  In fact, as Alex stated, nothing really
frees you from the burden of debugging.  But the need for a debugger
itself can be greatly reduced by using newer techniques (orthogonal to
whether or not you are using OOP).  In some sense, the effort is on
doing the debugging while you are developing the code, so that there
will be less of it later (where it can be more difficult and take
longer)

I would suggest you simply look in the standard library for the
unittests module, to get a feel for what it provides.  The idea is
simple.  When write a function that does a calculation, you also write
code that tests the common cases and extreme cases of that function for
correctness.  Some would even say that those tests *define* the behavior
of the function.

Now, if ever you change the implementation of the function, the tests
should immediately show if the new implementation is not correct.  Also,
if there is a bug in your program, you have some confidence, based on
the power of your tests, that the problem is not with that particular
function returning improper results.  By building up a large number of
tests like this, you can often quickly find the source of new bugs.

The trick, of course, is in writing good tests, and that is a skill that
has to be learned.  But, unlike being an expert with a debugger, as you
write more and better unit tests, they provide continuous protection
against new bugs being introduced into your program.


As far as "contracts" and asserts, that just means that you can put
assertions into your code to verify that your assumptions on how it
should be operated are correct.

If you, for whatever reason, have a function that should only be called
with positive numbers, you put an assertion like this near the top.

assert x >= 0

Now an error will be raised immediately, rather than propagating through
to some future point.  This is similar to running a debugger and setting
a breakpoint on a variable that triggers when that variable gets an
invalid value.  But with the assert, you've actually documented the
appropriate behavior (and with Python, you get a nice traceback showing
you exactly where that error occured).  Using this technique alone can
greatly reduce the need for a debugger.  "Design by contract" is a more
powerful extension of these ideas, and something worth Googling for.


Now, when you have an API that is published (ie. not just functions you
are using internally), you have to be more careful about properly
handling input and output (just raising an assertion error is kind of
rude).  I define arg_assert() to explictly raise an ArgumentError on
improper function argument values.  There are other techniques as well,
and hopefully the resources Alex mentioned will be of assistance.

In any case, hopefully this clarifies things a bit.  I'll venture to
guess that if you adopt some of these techniques (or others that you
pick up), you may not have as much desire to use a debugger.  And that
when that happens, you will NOT miss it. :)

-- 

Chad Netzer
(any opinion expressed is my own and not NASA's or my employer's)