What Not To Do

[Roedy Green]

I decided to update a little program I wrote for my personal use. It
was very much a one-shot, quick and dirty.

But in coming back to do a simple change -- move the data from
internal to the program to external CSV files, the work took a lot
longer than it should have.

If I had this to do over:

1. always document variables. In particular I did not document
whether various arrays always had an entry for each day or just
selected days in a range.

2. When you have to do a theme and variations DON'T copy clone the
code and modify. Encapsulate the common part. Otherwise the common
part will gradually diverge over time and be harder and harder to
maintain.

3. keep asking yourself, is this piece of code even POTENTIALLY
reusable. If so, bundle it up, and keep the application specific code
out of it.

4. get very clear on responsibility areas and the interfaces between
them so you know exactly where any given piece of code belongs.
It is not good enough to get the code in the stream somewhere. It must
go at the right responsibility point.

5. Rather than displaying error messages, throw an exception you catch
at a higher level and treat them in a consistent way. Otherwise you
will find messages being ignored or sent to a mixture of System.out
and System.err.

 

[Alex Molochnikov]

All these amounts to:

- observe the OOP methodology
- document your work by (at least) commenting your code
- create reusable components

And the following tidbit for completeness:

- don't drink and drive

 

[Oliver Wong]

5. Rather than displaying error messages, throw an exception you catch
at a higher level and treat them in a consistent way. Otherwise you
will find messages being ignored or sent to a mixture of System.out
and System.err.

If you're going to display error/warning/informational messages to the
console, use a logger instead. Sun provides one
(http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Logger.html), and
there's a good one by Apache as well. The advantage of a logger is that you
can filter the messages based on their severity (info, warning, severe,
etc.) and based on where they are coming from (the GUI module, the DB
module, etc.) so can enable debugging messages during development, and
disable them in your release version.

You can also control where the messages go to. You could have them
display on standard out, or standard err, or to an XML file, or an ASCII
file, or you could have them sent to a central database for intranet
applications, etc.

- Oliver

 

[Alex]

Yeah! I have nothing to do too ((
Alex.