[lug] can't make this stuff up, folks... My 2 lines of code, errr, I mean, my 2 cents....

[George Sexton]

I’ll throw in my thoughts. Code would be much more robust if programmers actually checked for error results coming out of their code and then handled it. I used to look at code in FoxPro a long time ago, and the norm for FoxBase/FoxPro programmers was to catch every error message, but then never report it. So, their code never threw an error. It just mysteriously failed. The first thing I did when I inherited this code was strip out the “handler” code so that the program actually threw errors.

 

Another issue is not planning for maintenance. Here’s a simple example of the kinds of things I do.

 

Switch (i) {

Case 1:

            Do blah

            Break;

Case 2:

            Do foo;

            Break;

Default:

            Throw new Exception(“Unhandled case! Value for i=”+i);

}

 

Now when someone feeds in bad data, or more likely another programmer adds in a new option somewhere in the code, the issue is immediately reported. It’s infinitely better to report the error. A great source for tips on this kind of thing is Steve Maguire’s “Writing Solid Code”. I know it has MS in the title, but the guy is a good programmer and it’s got a lot of useful information.

 

http://www.amazon.com/Writing-Solid-Code-Microsofts-Programming/dp/1556155514

 

 

Another technique is to actually get error reports back to the developer in a useful format. Let’s face it. A typical error report is: “I got an error in your program.” For Delphi programming, I use EurekaLog. It sends me a ton of information including a screenshot, stack trace, windows system info, etc. I can even attach files to the report.

 

http://www.eurekalog.com/

 

I’ve done this with other programs as well. I install an error handler. When the handler kicks, I post the error data to an HTML form on the internet. The form then Emails me the error data. Some day when I’m really motivated, I’ll modify the form handler to show the customer a resolution for the issue. 

 

The point here is that no code will be released error free. OTOH, if you put in good error reporting methods, then developers can easily find and repair defects. This is particularly important in strange “corner-case” errors.  Then, when you do your iterative code releases, you come out with a product that has fewer and fewer defects.

 

George Sexton
MH Software, Inc.
 <http://www.mhsoftware.com/> http://www.mhsoftware.com/
Voice: 303 438 9585
  

From: lug-bounces at lug.boulder.co.us [mailto:lug-bounces at lug.boulder.co.us] On Behalf Of stimits at comcast.net
Sent: Thursday, October 22, 2009 2:40 PM
To: Boulder (Colorado) Linux Users Group -- General Mailing List
Subject: Re: [lug] can't make this stuff up, folks... My 2 lines of code, errr, I mean, my 2 cents....

 

....
You still need deep tests on critical code but as you implied you can focus on the things where it really matters.
...

This particular thread is too entertaining to not add:

Often unit tests and other tests are more important just to make sure the programmers are thinking correctly. Writing tests can be time-consuming and difficult, and the first thing it does is make the programmer think about what is going on. Sometimes it seems so simple when we sit down and write code, but then when we sit to write a test, it suddenly becomes clear if there was something we had not thought of. Unit tests are as much for the wetware as they are for the software. A favorite unit test of mine is to see if I can put good comments in the code...in this case the unit being tested is me.

Dan Stimits, stimits AT comcast.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20091023/e6771032/attachment.html>