alphabetization in eclipse

[Anonymous]

is there functionality already in/available for eclipse that supports reorganizing sourcecode such that methods and/or attributes appear in alphabetical order?

i googled this, both looking for core functionality and for any plugins and was surprised when not much could be found.

[Jeanne Boyarsky]

Erick,
I don't know of a plugin for that. I believe Eclipse does natively show the elements alphabetically in the outline view. So people would look at that for alphabetical order rather than try to reorder the source code.

[Ilja Preuss]

In the source menu of Eclipse should be an entry along the lines of "sort members". It is highly configurable and should be able to do what you want.

[Tim Holloway]

Look for the tiny little "A/Z" icon!

[Anonymous]

nice! thanks guys! messed with configuration and got the result mighty close to exacty what i wanted. debugging disorganized code makes me nuts, really like that it can be cleaned up with a few clicks.

[Anonymous]

it'd be more slick if the eclipse config for sorting class members provided for clumping of like-types, and also for preference in what takes precedence: type or visibility. i prefer the latter, eclipse insists on the former.

[Ilja Preuss]

Originally posted by Erick Reid:
it'd be more slick if the eclipse config for sorting class members provided for clumping of like-types, and also for preference in what takes precedence: type or visibility. i prefer the latter, eclipse insists on the former.

Then you should probably post a feature request...

[Ernest Friedman-Hill]

Originally posted by Erick Reid:
debugging disorganized code makes me nuts,

The order of members in a source file stopped mattering to me as soon as IDEs got good enough to always navigate directly to the definition of any member with a single click. How come it drives you nuts? Can you explain why?

[Anonymous]

How come it drives you nuts? Can you explain why?

clean freak. it must not be too freaky given that my desire is met by core functionality in eclipse (source - sort members).

admittedly, i don't often use the alphabetized member navigation eclipse presents to jump into potentially jumbled code, and probably should start getting in the habit. like so much else in eclipse, this functionality is very nicely done. even after that becomes habit however, i'll likely still much prefer code that is equally well-organized.

[Ilja Preuss]

I also notice that I stop caring about member order once classes become reasonably small in size. So I'd probably see the desire to sort members as a kind of code smell. Your mileage may vary, of course.

[Anonymous]

ilja,

see the desire to sort members as a kind of code smell

indeed. good point. that is something not made explicit in previous posts: this resorting source code is something undertaken while debugging legacy swing code. there is no doc and the classes tend to be bloated.

the class being edited when i started this thread is not too bad as they go in this particular codebase: 700 LOC, 6 public methods, 29 private attributes (mostly sql strings), 28 private methods.

i like the alphabetization in part because it cleans up the code, and in part because doing so helps me get my head around what the heck is going on in the class (and why the heck is that checkbox not disabled like it should be?)

control freak?

why not refactor? that would be great, but many of the problems at hand are systemic, truly baked in, the result of design decisions from years ago. breaking the legacy code up into something to be truly happy with is not an option. much too risky and time-consuming, especially since plans to redesign the entire product are gaining stream.

p.s. you recommended "fearless change" in another thread you and i participated in. just checked it out from library last night.

[Ilja Preuss]

Originally posted by Erick Reid:
the class being edited when i started this thread is not too bad as they go in this particular codebase: 700 LOC, 6 public methods, 29 private attributes (mostly sql strings), 28 private methods.

Well, yes, I do see worse code, too... <sigh>

control freak?

Well, having the code under control is probably what pays your bills?

why not refactor? that would be great, but many of the problems at hand are systemic, truly baked in, the result of design decisions from years ago. breaking the legacy code up into something to be truly happy with is not an option. much too risky and time-consuming, especially since plans to redesign the entire product are gaining stream.

Be careful - a redesign project might be more painful than you imagine. It's a risky thing, too - mostly because until you have build a whole system that provides the same functionality as the old one, you are not providing any value to the customer. When given the choice, I will often decide to go the refactoring road to reduce the risk and provide ongoing value to the customer, even if it feels more painful. (Actually with some experience, it can be rather satisfying, too.)

p.s. you recommended "fearless change" in another thread you and i participated in. just checked it out from library last night.

I hope you'll enjoy it!

[Anonymous]

Be careful - a redesign project might be more painful than you imagine

word!

there are some very compelling reasons for redesign though:

having supported/sold the legacy app for years now, the partners are very aware of items of increased functionality that clients would like to see that the current app will not support.

an interesting flipside are the several cases where potential clients would be interested if features could come ala carte. there is no way to provide this (and thus no way to interest those would-be clients) with the current code.

the current app is thick client requiring client-site install, upgrade, troubleshoot, etc. an asp model is where the partners would like to see this thing head.

reasons given, it is indeed a very risky venture.

[Ilja Preuss]

This is interesting - I'd like to continue to discuss this redesign thing. But we should probably move that discussion to the OO forum... Are you interested?

[Tim Holloway]

I think maybe IntelliJ offers a source code re-ordering feature. Or maybe it was something like Jalopy. Pretty sure it's not part of Eclipse.

It'd be fairly easy to write an Eclipse plug-in to do this sort of stuff, though not trivial. And, of course, tastes vary. I like the static fields first, then the member fields, then the constructors, then the methods, and in classes that simply refuse to trim down neatly to 5 pages or less, I may also have special comments to divide the functional sections.

[Anonymous]

tim wrote:

tastes vary

definitely. the sorting functionality in eclipse, while configurable, does not match my (potentially fussy) desires... but it comes pretty darn close, and it provides a big improvement over the jumble the class in question was originally.

ilja wrote:

should probably move that discussion to the OO forum

certainly. the potential resign is not a front burner thing yet, and may not become so for a long while.

our current effort needs to complete its sea trials and start earning $$$ (and thus earn the developers some cred' with the partners) before a redesign of the bread-and-butter app is taken seriously.

on the redesign note, check out this entry in michael slattery's weblog and the links therein.