June, 23 2006

The Eclipse code formatter discourages developers from writing statements that are longer than one line, through the simple mechanism of doing a really bad job. Take, for example this long statement:

   g2.drawImage(
        map,
        (int) bounds.getMinX(),
        (int) bounds.getMinY() + inset,
        (int) bounds.getMaxX(),
        (int) bounds.getMaxY() - inset,
        crop,
        0,
        map.getWidth() - crop,
        map.getHeight(),
        null);

Here is what the Eclipse 3.0 code formatter would do with that code, if I let it:

   g2.drawImage(map, (int) bounds.getMinX() + inset, (int) bounds
            .getMinY(), (int) bounds.getMaxX() - inset, (int) bounds
            .getMaxY(), 0, crop, map.getWidth(),
            map.getHeight() - crop, null);

The Eclipse 3.2 code formatter is slightly better:

    g2.drawImage(map, (int) bounds.getMinX(), (int) bounds.getMinY()
            + inset, (int) bounds.getMaxX(),
            (int) bounds.getMaxY() - inset, crop, 0, map.getWidth() - crop,
            map.getHeight(), null);

But then it completely chokes on this declaration, refusing to split the line at all:

    private Map<IPropertyChangeListener, Preferences.IPropertyChangeListener> listeners = new IdentityHashMap<IPropertyChangeListener, Preferences.IPropertyChangeListener>();

Funny thing is, I’m sure the Eclipse 2.0 formatter was a lot better at splitting lines in sensible places. Anybody else notice that?

More seriously, every time it happens, I’m remined of one the Angels’ best anthems. (Hear a crappy, low-bandwidth sample at Amazon.)

Sarah shares her knowledge of the US and UK cat-food industries. Of course the Australian industry would be completely different.