What Not To Do

Discussion in 'Java' started by Roedy Green, Jan 3, 2006.

  1. Roedy Green

    Roedy Green Guest

    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.
    Roedy Green, Jan 3, 2006
    #1
    1. Advertising

  2. 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.
    Alex Molochnikov, Jan 4, 2006
    #2
    1. Advertising

  3. Roedy Green

    Oliver Wong Guest

    "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/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
    Oliver Wong, Jan 9, 2006
    #3
  4. Roedy Green

    Alex Guest

    Yeah! I have nothing to do too :(((
    Alex.
    Alex, Jan 9, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roxanne
    Replies:
    0
    Views:
    1,213
    Roxanne
    Jul 4, 2003
  2. Andy Elmhorst
    Replies:
    2
    Views:
    465
    Bassel Tabbara [MSFT]
    Jul 8, 2003
  3. Kristian Domke
    Replies:
    11
    Views:
    489
    George Sakkis
    Jan 23, 2008
  4. Stephanie Stowe
    Replies:
    2
    Views:
    196
    Peter X
    Apr 7, 2004
  5. Ruby Freak

    To be not, or not to be not?

    Ruby Freak, Sep 23, 2008, in forum: Ruby
    Replies:
    2
    Views:
    124
    Thomas B.
    Sep 23, 2008
Loading...

Share This Page