Eclipse - Taking a long line

5 AM 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.)

By alang | # | Comments (2)
(Posted to javablogs)

Comments

At 07:01, 23 Jun 2006 Jeroen van Wilgenburg wrote:

In Eclipse 2.0 generics didn't exist yet so it probably didn't work there either.
I think it doesn't break the line because the equals sign is a strange place to split a line.

What might work is the Jalopy plugin (http://jalopy.sourceforge.net/)
I used that in an older Eclipse because of what you described in your first example.
Maybe there isn't a convention for splitting generics yet.

(#)
At 02:55, 24 Jun 2006 Richard wrote:

The eclipse 3.0 formatter has an annoying habit of only choosing one place to try and break a line. If your formatting rules prevent it from breaking the line there (eg within generic parameter lists), it doesn't go back and try and break the line anywhere else.

Add this to the fact that eclipse won't insert/remove brackets or braces where they should go*, and you've got a truely aweful formatter.

I've no idea how much improved the 3.2 formatter is, but for now I'll stick to Jalopy. I can at least understand and work with its quirks**.

*Surely your coding standard requires braces around if statements?
**The versions of Jalopy I've used are known to put a trailing space on empty lines within javadoc, when you let it reformat comments too. I've no idea if the commercial version (http://www.triemax.com/products/jalopy/) or if the latest and greatest OS versions fix it.

(#)

Add Comment




(Not displayed)






(Leave blank line between paragraphs. URLs converted to links. HTML stripped. Indented source code will be formatted with <pre> tags.)




© 2003-2006 Alan Green