I noticed we had to break up a function to satisfy
Checkstyle's max method length size of 150 (
 That seems too constricted for our use--it's may
force parameter passing of local variables where none
would otherwise be needed.  I would double the limit
to 300--the function above did not warrant
rewriting--a better option may be to remove the limit

Combined, the two case statement blocks tripped
Checkstyle's limit, causing Checkstyle to complain: 
so you placed both blocks into separate functions. 
But what if the second case statement was much
smaller?  Checkstyle wouldn't complain about the
method containing on the switch statement, so
*neither* of the two case statements would be placed
into their own function.  This seems too arbitrary:
something in addition to method size should play a
part in the decision to create new methods.


--- Victor Mote <[EMAIL PROTECTED]> wrote:
> Fellow fop devs:
> Our current checkstyle configuration has a setting
> for
> "checkstyle.pattern.publicmember" =
> "^f[A-Z][a-zA-Z0-9]*$", which is the
> checkstyle default. See (for example)
> datatypes/FODimension where public
> members "ipd" and "bpd" are flagged by checkstyle
> for not fitting this
> pattern. Changing "ipd" to "fIpd" fixes the problem.
> Before I refactor this
> kind of item:
> 1. was this really our intent?
> 2. does anyone know what the "f" stand for?
> 3. checkstyle actually suggests that "Variable 'ipd'
> must be private and
> have accessor methods." Perhaps this is our
> preferred solution?
> Victor Mote
> To unsubscribe, e-mail:
> For additional commands, email:

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to