On Jun 9, 2008, at 18:46, Adrian Cumiskey wrote:
After looking more closely at this I think I may have been a little
hasty in my praise and Jeremias has a point, but Max's sentiment is
a right one.
On the subject of readability, there is much cleaning up and
refactoring that needs to be done to make the code base more simple
and easy to understand. This is especially the case in the areas
of layout (LayoutManager implementers) and rendering. Below is a
list of java classes and their current line count in trunk.
We currently have Checkstyle set FileLengthCheck to a maximum of
2000 lines. Of course I realize there is a necessary complexity in
the processing task, but IMO a class shouldn't really be more than
say 500-600 lines long.. otherwise its just doing too much and
should be delegating to another class. I would be interested to
hear your thoughts on this.
As a general rule, I agree that source files should be kept at a
reasonable line count. For some cases, like FOPropertyMapping, I
think it is not really necessary or desirable to chop that up in
separate classes just to respect a Checkstyle rule, though.
Exceptions to a rule are always possible. One class in over a
thousand counts as exceptional in my book. (That said, even 25 in a
thousand is still a rather small portion...)
A different matter for LineLayoutManager, for example. IIRC, in the
Temp_Interleaved_Page_Line_Breaking branch, Simon has already split
this class up. I had also started something like that locally.
LineLayoutManager mainly has some inner classes which can be migrated
to their own source file to alleviate this.
Something similar probably holds for some of the other classes, but I
can't say for sure without investigating.