commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [math] Checkstyle too stringent?
Date Sun, 18 Mar 2012 13:10:41 GMT
2012/3/18 Sébastien Brisard <>:
> Hi,
> I'm trying to clean up the SymmLQ class (see MATH-761 [1]).
> The problem is the heart of the algorithm is very long (it would
> probably amount to more thatn 600 lines). When I first implemented it,
> I figured that I could split this algorithm in several methods:
> init(), update(), updateNorms(), refine(), etc... This makes the code
> somewhat more legible [2], with the difficulty that there is a lot of
> data to be shared between these methods. That's the reason why I
> created a simple nested, container class (namely, State) which holds
> all the variables which are updated at each iteration. In order to
> make checkstyle happy, all the fields of this nested class are
> private, which means that a lot of accessors should be created with a
> null benefit, since this class is nested anyway. I have to admit I
> forgot to create these accessors, so synthetic accessors are
> automatically generated at the present time. I'm not sure this is good
> practice, but I'm also reluctant to implement all those (useless in my
> view) accessors. So my question is two fold
> 1. Would it be acceptable to have public fields in a nested class?  If
> yes, the checkstyle rules should be modified.
> 2. Is it good practice otherwise to let the JVM generate synthetic
> accessors (which would probably get inlined anyway by modern JVMs?).

Why not put the methods and the data in the same class?

That would eliminate the need for accessors.

> I'm currently puzzled by the SymmLQ class. I feel the need for some
> cleaning up, but I do not really know where to start. So if anyone
> feels like reviewing the code, I would be grateful for some help. The
> good news is that unit tests are very extensive, so we can try drastic
> refactoring.
> Thanks for your help!
> Sébastien
> [1] Which is probably ill-named. Should be named "cleaning-up SymmLQ"
> [2] I have to say I have mixed feelings now: I'm wondering whether a
> 600-hundred lines method would not be better in that case, but I would
> probably not get a wide support...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message