Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > What Not To Do

Reply
Thread Tools

What Not To Do

 
 
Roedy Green
Guest
Posts: n/a
 
      01-03-2006
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.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
Reply With Quote
 
 
 
 
Alex Molochnikov
Guest
Posts: n/a
 
      01-04-2006
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


"Roedy Green" < > wrote in
message news:...
> 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.
>
> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.



 
Reply With Quote
 
 
 
 
Oliver Wong
Guest
Posts: n/a
 
      01-09-2006

"Roedy Green" < > wrote in
message news:...
>
> 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/...g/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


 
Reply With Quote
 
Alex
Guest
Posts: n/a
 
      01-09-2006
Yeah! I have nothing to do too ((
Alex.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
To be not, or not to be not? Ruby Freak Ruby 2 09-23-2008 08:04 AM
Why not 'foo = not f' instead of 'foo = (not f or 1) and 0'? Kristian Domke Python 11 01-23-2008 07:27 PM
'' is not a valid name. Make sure that it does not include invalid characters or punctuation and that it is not too long. rote ASP .Net 2 01-23-2008 03:07 PM
Cisco 3640 3620 3600 not detecting, not enabling, not working: NM-2FE2W Taki Soho Cisco 0 09-22-2004 07:28 AM
maintaining control with cookies (not strictly an ASP or even server side question. But not not either) Stephanie Stowe ASP General 2 04-07-2004 04:23 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57