commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <sebastien.bris...@m4x.org>
Subject [math] Checkstyle too stringent?
Date Sun, 18 Mar 2012 09:19:15 GMT
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?).

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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message