Victor,
I noticed we had to break up a function to satisfy Checkstyle's max method length size of 150 ( http://marc.theaimsgroup.com/?l=fop-cvs&m=105806596213734&w=2). 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 entirely.
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.
Glen, Victor,
I tend to agree with Glen on this one. The limit seems too restrictive, and it is only a guideline - as are many of the other strictures of Checkstyle. They flag things which may make the code problematical, but they do not have the same simplicity as, e.g., tab width or format of names. If we follow them slavishly, we lose perspective on the code. I don't think things like method length should even be warnings; rather info flags, to indicate that something needs to be looked at.
Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
