Saturday, July 21, 2007

Eclipse's code style options are a bit messy

At work we have had an agreed upon coding style for a couple of years, but it hasn't been enforced so not everybody have followed it. When the style was established, everyone was using IntelliJ IDEA so the style was based on IDEA settings. Now it's a split between IDEA and Eclipse, so recently I was trying to create matching style settings in IDEA, Eclipse and CheckStyle -- the first two for automatic formatting and the latter for checking.

Both IDEA and Eclipse have some problems. For example Eclipse puts more whitespace in JavaDocs and I could not configure the JavaDoc formattings to be compatible so I just turned it off in IDEA. Eclipse tends to not respect the maximum line width setting for code very well -- occasionally a few characters will go beyond the limit. IDEA has the same problem for JavaDocs. Eclipse also has some problems with optimizing imports (note to self: should report /comment on bugs about those, maybe even contribute patches) that make it incompatible with IDEA.

But the biggest problem is that Eclipse doesn't have a very good user story for configuring all of this. The code formatter options (Java -> Code Style -> Formatter) are the oldest and they are pretty good -- easy to manage profiles and everything can be exported/imported. The same can be said about code clean up (Java -> Code Style -> Clean Up), but I would argue that these two separate concepts should be merged.
There is also a problem of redundancy: Java -> Editor -> Save Actions use the existing Formatter and Organize Imports settings, but they do not use the Code Clean Up settings, instead here you have to configure those again, in a non-shareable way.
However, Code Templates, Organize Imports and the general settings are worse -- they don't support different profiles, and Organize Imports does not export/import all settings (such as the number of static imports needed for .*). All of this makes it quite hard to share these settings between a team.

I think a good solution would be to replace the profiles and import/export in the different pages (formatter, clean up) with more general Code Style profiles and import/export that would cover every setting under Java -> Code Style. Then again, maybe more granular profiles are better for some reason that I fail to see, but I'm sure they could be retained somehow while solving the problem I just described.

And another idea: as Eclipse is becoming an IDE for more and more languages, and many of these language tools could possibly offer code formatters, compiler options etc., why not think of a generic code style settings UI that would be extensible by plug-ins for specific languages.

Friday, July 06, 2007

Rhythm in open source

Mark Shuttleworth (what an awesome last name, BTW) thinks that KDE, Gnome and OpenOffice.org would benefit from a common release schedule, preferably six months like Ubuntu. I'm wondering if Eclipse's annual release trains also influenced his opinion and whether these kind of coordinated/rhythmic releases have been done elsewhere in the open source world or are Eclipse and Ubuntu the only ones? I think it would be great for the open source community if the rhythm spread and releases became more predictable.

Wednesday, July 04, 2007

Eclipse 4.0 should be about usability and integration

Eclipse 4.0 Io is probably 2 years off now (or 3, if Io will in fact be 3.5?) , considering the very precise yearly release cycle that just brought us Europa and will bring Ganymede next year. And if there are going to be some more fundamental changes in 4.0 than the releases since 3.0 have had, I think it's time to start talking about this now. Really big changes can't happen during one release cycle.

So that it's understandable where I'm coming from: I've been following the Eclipse community for the past two and a half years, as an occasional hacker, but mostly a user and a somewhat objective observer. Or at least that's what I like to think -- I'm actually a pretty big fan of Eclipse so there definitely is some bias. I heard there was some discussion on Eclipse 4.0 already during EclipseCon 2007. Sadly, I couldn't attend EclipseCon myself. Note: I'm also linking to some old related discussions in this post -- I think some of them are still valid.

Even though Eclipse is growing very fast, I think there is still a lot of untapped potential in the projects hosted by The Eclipse Foundation. That potential lies in the integration of the various tools so that they can be composed into wholes that are greater than the sum of their parts -- creating synergy. To some extent this is already happening, but at the moment there are still a lot of areas where it feels like the tools should work better together, but they don't. There are endless possibilities for small improvements that span projects, but actually filling that potential may be somewhat hard to do.

The Callisto and Europa release trains have definitely been a big step in the right direction, but they have not set integration as a top priority and it would probably be too much to expect much greater strides towards this from Ganymede. But as a user, I'd like to see this become a priority for Eclipse 4.0 (or soon after). If Eclipse just keeps extending wider and wider into new, though definitely cool areas (which it must do, of course), while not paying much attention to keeping the expanding core cohesive, I fear it may eventually start losing focus.

In the past there has been some talk about "extensible frameworks and exemplary tools" and that the focus of Eclipse is sometimes a bit more on providing a platform rather than a great end-user tool. This focus may vary from project to project. But parts of Eclipse do make a great end-user tool (perhaps most notably JDT and PDE, but there are others too), and other parts less so. Of course this undoubtedly has to do with the maturity and age of the projects as it takes time to become an awesome tool.

But perhaps there should be more effort made in the area of usability and making a set of "core" projects better integrated and of a more uniform quality, whatever exactly the "core" would compose of -- probably platform + the more popular language tools + PDE + Mylyn + ECF + data + modeling + reporting + testing and some other projects as well. More focus should be put on the areas where these "core" projects touch. This would in turn probably put a lot of pressure on the platform itself, which may need to become even more flexible, even though it already is probably the most flexible and in my opinion the best application platform in the known universe.

Some examples of what I mean, but these may be somewhat superficial and don't really go deep into details:
* Mylyn bridges for more projects -- perhaps even all of the release train projects
* Taking advantage of potential communication/collaboration features offered by ECF and other projects (Corona comes to mind)
* More BIRT reports in other projects
* Make the static analysis from TPTP more prominent. IDEA has had this for years. How many users know that they can get static analysis and a profiler for Java by installing TPTP?
* Make Eclipse a competitive database design & administration tool
* Make Eclipse a competitive UML modeling tool
* ETC.

I hope not all of this will be left for vendors to do in their Eclipse based products -- that could make Eclipse itself lag behind.

Oh, and by the way, great work everyone who made Europa happen! You all deserve a vacation now, but don't go resting on your laurels! :)