Re: best practice for structure of code

For every situation, there is potentially a different solution.  Every
developer will have a different opinion.

I think you are headed in the right direction.  The separation of actions
into their own methods makes the code more readable.  Smaller methods are
more readable too.  I have heard some suggest that no method should be
longer than 10 statements.

Every independent action should have its own method.  I say independent
since dependent actions risk being executed in the wrong order if they are
separated into their own methods.  Usually, it is still worth the risk to
separate the methods and trust that they will be called in the right order.

I would prefer not to use any class attributes though.  Passing the values
as parameters results in self documenting code.  It can also reduce
confusion regarding where the values might be modified.  With attributes,
anyone could update your code such that a method modifies an attribute that
the next method relies on.

Of course, having too many parameters makes the code difficult to read.  In
that case, the use of final attributes can help.

Parameters are safest.  Attributes are convenient.  Statics are risky.  If
you are into extreme defect resolution ... use ThreadLocal.  Of course,
there are cases where each is appropriate.

   Harold Meder.

On Sat, Aug 30, 2008 at 6:41 PM, Douglas Ivers <[email protected]> wrote:

> If I need to execute a section of code more than once (not in a loop),
> then I of course create a named method so that I don't have multiple
> copies of the code.  On the other hand, I sometimes create methods
> that exist solely for readability and are only called once, see below
> for example.  Is there any drawback to this style of code?  Are there
> differences in opinion, or is there a widely accepted best practice?
>
> public void init() {
>        parseConfigFile()
>        loadImages()
>        loadData()
>        buildGui()
> }
>
> This often leads to class fields that could otherwise be local
> variables, which I see as a slight drawback.
>
> I've also experimented with unnecessary braces to improve readability,
> but I suspect this is very unconventional.  For example,
>
> public void init() {
>
>        { // parse config file
>                foo
>                bar
>                etc
>        }
>
>        { // load images
>                foo
>                bar
>                etc
>        }
>
>        ...
>
> Of course any variables defined within the braces are not visible
> outside the braces and working around that can reduce the readability
> somewhat.
>
>
>
> _______________________________________________
> Juglist mailing list
> [email protected]
> http://trijug.org/mailman/listinfo/juglist_trijug.org
>

_______________________________________________
Juglist mailing list
[email protected]
http://trijug.org/mailman/listinfo/juglist_trijug.org