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.
<snip />
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.



Reply via email to