"Sort by type": is it really useful?

"Sort by type" doesn't work for me, and I wonder why, and if it can be
changed?!
Does is work for you? When? How do you use it?



Example:
-



I was "modernizing" (rewriting for Java 5.0) some old code, that looked
like this before:
("Sort by type" enabled)

... (5 classes)
class: Foo
... (20 classes)
]]>

Actually, 'Foo' was 3 classes in one :
FooLine
-- FooLine$Type
-- FooLine$TypeMapper

I moved the 2 internal classes out, and it became clearer.

... (5 classes)
class: FooLine
class: FooLineToTypeMapper
class: FooType <----


ok
... (20 classes)
]]>

As the class FooType was actually just an old style enum, I turned it
into a real Java 5.0 enum, and that's when it started annoying me:


... (5 classes)
class: FooLine
class: FooLineToTypeMapper
... (20 classes)
enum: FooType <<<----


it's out of sight.
]]>

Now, the enum is out of sight.


What I would like to see actually is:

... (5 classes)
class: FooLine
class: FooLineToTypeMapper
enum: FooType <<<----


ok
... (20 classes)

]]>



You could tell that I just used "Sort by type" to hide the tests, and
that "soon" we'll get a separate option for this.
True.
So, my question is :
Apart from moving the tests out of sight, what is "Sort by type" good for?


Alain

4 comments
Comment actions Permalink

Enums are sorted below classes in my packages & project panes and before test classes. If you find the original discussion, that is the order that sort by type uses. (I'm on 3326.)

Jon

0
Comment actions Permalink

I find "Sort by type" to be extremely useful. The overall goal is to make the project view more fully explicate my design. An alphabetically-sorted project view tells you nothing but containment (the least important form of program structuring), and isn't all that much more powerful than a standard file view. A type-sorted view tells a much richer story of your design, particularly with all of the new decorations. Assuming decent design, sorting by type (interfaces, then abstract, then concrete, then enums, then test cases) is a good approximation both of sorting by importance, and of sorting by suggested exploration order. With proper package structuring, it can really make your design intent come alive, and makes other people's projects easier to understand. As we've discussed, it would be richer with just a couple more file types (utility, singleton, servlet, constant), but I consider the present set to be pretty strong. Sort-by-type does make browsing for a particular file more difficult, but you were using Ctrl-N and Ctrl-B for that anyway, right?

What you seem to be looking for (beyond just 'hide the damn test cases') is some sort of clustered filtering, which keeps "related" types together. Possibly this might be done via metadata, or possibly using some sort of collaborative filtering tech ("Developers who used this this file, often used these files..."). A very cool idea, even more powerful and vivid than sorting by type. If JB would open up the project view sorting/filtering/rendering, I'd love to see a prototype plugin. Until then, sort-by-type and the new decorations are so much better than the previous project view that I'm not going to complain.

--Dave Griffith

0
Comment actions Permalink

Dave

> I find "Sort by type" to be extremely useful. The overall goal is
to make the
> project view more fully explicate my design.

A lot of my design choices is contained in the classes and packages
names. Alphabetical sort works fine for me, because it keeps related
classes together:
Foo
FooCreator
FooDestructor
FooType <------- 5.0 enum or 1.4 enum-in-a-class, I don't care.

Whether 'FooType' is an enum or a standard java class is just an
implementation details that is not important to me.

Seeing all the enums packed together, at the end of the classes list,
doesn't tell me anything that I don't know already.
On the other hand, not seeing FooType next to the 3 other FooXXX class,
deprives me from useful information.

Though, if the enum icons background colour and/or shape were different
from the class icons' ones, they would come forward, like interfaces do,
while staying next to their name-siblings.


Don't you thing
different enum colour + alphabetical sort
is a better combination than
same colour + type-based sort

?

Alain

0
Comment actions Permalink

I really do want my interfaces separated from my classes, my abstract base classes separated from my classes, and my exceptions separated from everything. If there are any couplings that cross those category lines so strong that I commonly need to see the coupled objects together, then I've made a design error. Similar reasoning applies with tests, servlets, utility classes, constant classes, and (possibly) singletons. Sorting by type is a quick and dirty proxy for the sort of internal layering that well-designed packages should have. Within type category, I do use and value the sort of name-based grouping you describe, so I like the fact that sort-by-type uses sort-by-name as a secondary key.

It's just like comments. Naming conventions that cross layering boundaries aren't a problem in themselves, but rather a sign that you've got other problems.

Enums are actually a weird edge case. Some of them should group with interfaces (those that are public and methodless) and some of them should group with concrete classes (those that are non-public, or include substantial amounts of business logic)and some should even group with annotations (if they are used as annotation arguments) There's no value In can see in grouping them with abstracts, or exception, or tests, or utility classes, no matter what their names are. That would be a clue to a layering violation.

If there were just some way of visualizing inter-package and intra-module layering as quick and clean as sort-by-type is for intra-package layering, I'd be a very happy man.

--Dave Griffith

0

Please sign in to leave a comment.