05.14.08
Posted in Eclipse, programmer productivity at 12:51 pm by ducky
Andrew Ko, whose papers I have mentioned before, observed in An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks that
When investigating [navigations back to previously-seen code fragments], nearly all seemed to be for the purpose of juxtaposing a set of code fragments while editing many dependent fragments. … Although Eclipse supports viewing multiple files side by side, placing any more than two files side by side would have incurred the interactive overhead of horizontal scrolling within each of the views.
Meanwhile, from my user study, I believe that the Package Explorer is usually not worth its screen real estate and the Outline View is probably harmful (which I will explain below). If I close the Package Explorer and the Outline View, on my 24″ monitor, I have oodles of room for two source files side-by-side. I think that is probably the way to go.
Package Explorer
Developers used the Package Explorer to find classes that had interesting strings in them. For example, in the Arrow task, they would do a “visual grep” to find classes that had the word “Arrow” or “Line” in them. Generally, however, they would explore the first class they found with “Arrow” or “Line” in it. While that happened to be okay in the Arrow task, it is easy to imagine situations where the first class could be uninteresting or even deceptive. I have come to the opinion that it is better in most cases to use Control-Shift-T to open the “Open Type” dialog, where you can enter in the string you are interested in. (Note that you can use wildcards, e.g. “*arrow” to find all Types that have the text “arrow” anywhere in their names.)
If you use the Open Type dialog, you will immediately (because it immediately displays matching type names as you type) have a very good idea of which / how many classes have that text in them. You are not going to miss one, and you are less likely to get distracted by the first one you see.
Now, I saw a very small number of cases where the Package Explorer was useful. For example, in the Output task, one guy looked at package names and guessed (successfully) that “proguard.io” might have something to do with IO. So I don’t think you should do away with the Package Explorer, but minimize it most of the time.
Outline View
As for the Outline View, you can search for strings in the method/field names using Control-O. Just like with the Open Type dialog, you can search for strings (including wildcards). Even better, with Control-O,Control-O, you can see what methods are inherited.
I don’t think I ever saw anyone wandering aimlessly (i.e. not doing a visual grep for a specific string) around the Outline View and having any good come of it. So I don’t think the Outline View is worth the screen real estate.
Permalink
05.06.08
Posted in Eclipse, programmer productivity at 4:06 pm by ducky
In previous posts, I talked about wanting a code-coverage tool to use while debugging, and how EclEmma did most of what I wanted. After my user study, where I dissected in detail how seven professional programmers did four twenty-minute programming tasks, I am even more convinced that a wonder tool would be highly, highly useful to people. I want the wonder tool to colour and present source based on whether code was executed between a user-defined start and stop point.
- As I mentioned in the first post, I’d like to be able to start and stop collecting code coverage information. It would be nice if I could set START LOGGING and STOP LOGGING breakpoints, so that lines of source would be coloured based on whether they were executed inside the “active” regions. Being able to do this would mean that I could greatly narrow down what code was involved in a particular feature, and not have all the code touched by initialization routines touched.
- I’d like the number of times that a method gets executed to influence the Mylyn degree of interest. I’d like Mylyn to restrict what classes/methods Eclipse showed me (initially) to only those which were executed between the START LOGGING and STOP LOGGING breakpoints.
For example, I could bring up a GUI application, hit the Suspend button, set a START LOGGING breakpoint, hit resume, and resize a window, and hit the STOP LOGGING button. The PackageExplorer would then only show me the methods involved in event handling and resizing a window. Most of the event-handling code would probably be done by .class files, so it probably would only be the code related to event handling.
I believe that this would have helped my user study subjects enormously. They overwhelmingly used static tracing (i.e. jumping to references or declarations of selected methods) to find where things happened in the code, but they frequently got caught by differences between what static tracing told them and what actually happened. Examples:
- All seven subjects searched for an unusual string related to the given task in a GUI, which seemed perfectly reasonable. However, that string appeared in a superclass of the object that was actually instantiated. Jumping to declarations (via F4 or hyperlinks) took them preferentially to methods in the superclass. Four of the seven subjects never noticed that there were interesting subclasses. If, however, they had been using my wonder tool, the first time they jumped to a method that the subclass overrode, they would have seen from the source code colouring that that method never got hit.
- In one task, important code was not broken, but flat-out missing. Subjects usually found the right method pretty quickly, but then assumed that — because that method didn’t have the needed code — that it didn’t get executed. “Oh, here’s where the start-of-line decoration code is, now I just have to figure out where the end-of-line decoration code is.” Had they seen that that method got executed, they might have realized faster that the end-of-line decoration code was simply missing.
- In another task related to incorrect output, to statically trace through to bug’s location meant going through six methods whose names and comments made it look like they were related only to input. Setting a START LOGGING breakpoint where it wrote “Writing output…” to stdout and a STOP LOGGING breakpoint at the next stdout status message, then the subjects would have been able to see that the “input” methods were involved in writing the output, so they might have been willing to push through them.
- One task that asked the subjects to do something when a pane got resized was so difficult that nobody solved it. In addition to problems with language (Is that pane a Window, a View, a Drawing, a Pane, or a Panel?), it can be tricky to get from the place where a GUI widget gets set up to where the event gets handled. (In this case, they needed to find what methods were executed when a pane was resized.)
With my wonder tool, subjects would be able to get a list of all the classes and methods that were involved in the resize. By browsing that list, they would have a better shot at finding a method that they could use.
I think it wouldn’t be too difficult to implement this — EclEmma has already done the lion’s share of the work — but I doubt it’s compatible with finishing my thesis. 
Permalink
04.17.08
Posted in Eclipse, robobait at 1:43 pm by ducky
Eclipse has incremental find!
Control-J will let you start typing to find the next occurrence of what you’re looking for; Shift-Control-J will do incremental find backwards. See Erik’s nice writeup on incremental find…
Permalink
04.16.08
Posted in Eclipse, Hacking, Technology trends at 5:42 pm by ducky
There are a zillion graphical IDEs out there, and I really don’t want to download and try each one. I don’t even want to try twenty of them. So, dear readers, care to help me?
All the IDEs that I’ve seen have a main center panel with the source of the file you’re looking at. Above that, they seem to all have a row of tabs, one per file that you’ve opened. (Does anybody have anything different?)
Here is a link to a screenshot of Eclipse. (Sorry, it was too wide for my blog.) Eclipse puts a little “>>” to show that there are more files (as pointed to by the ugly black arrow), with the number of hidden tabs next to it (”4″ in this case). Clicking on the “>>4″ gives a drop-down menu (shown here in yellow).
What happens in other IDEs when you have more tabs than will fit across the horizontal width of the source file? How does your IDE handle it? Or does your IDE have a different tabbing model altogether, e.g. it opens one window per file? I would greatly appreciate hearing from you.
You can either email me ducky at webfoot dot com or post in the comments; I’ll wait a few days and then summarize in another blog posting. Remember to tell me the name of your IDE.
Permalink
03.17.08
Posted in Eclipse, robobait at 2:34 pm by ducky
I’ve got two cool tricks for you today. Control-O opens up a “quick” view of the Outline View. Instead of looking in a separate pane, you can do it right inline. Furthermore, it has incremental search built in, so you can type a few letters to find methods that start with those letters. If you type in the normal Outline View, it will find the first method that starts with those letters but will continue to show you all the methods.
In the Quick Outline View, it will show only the methods that start with what you typed, so if you type “set”, the quick outline view will only show you setFoo(), setBar(), etc.
But wait, it gets cooler: you can use wildcards in the Quick Outline View and you can’t in the Outline View. For example, in the Quick Outline View, you can type “*Foo” to find getFoo(), setFoo(), etc.
But wait! It gets even cooler! If you have the Quick Outline View up and type control-O again, then it will show you the inherited methods as well as the ones in this class. Totally sweet.
Permalink
03.14.08
Posted in Eclipse, robobait at 9:35 pm by ducky
Several of the users in my study have complained about “tab spam” in Eclipse — having so many files open (at one tab per file) that they can’t keep track of them all.
If you want to limit the number of tabs in Eclipse that you have open at any one time, you can do this:
- go to Window->Preferences->General->Editors,
- put a check in the Close Editors automatically
- and select the number of editors (tabs) that you want open at once.
If you don’t want a tab to be reused, you can “pin” it. (On my toolbar, the “pin this” icon is at the far right, just to the right of the forward arrow, and has a little white-window-with-blue-taskbar underneath a green pushpin.)
This still cycles through editors, eliminating the least-recently-used, but at least you won’t get tab spam.
If you reuse editors, it is handy to use the Auto-Pin Editor Tabs Tweaklet. With that tweaklet installed, Eclipse will not reuse an editor (i.e. a tab) if the file within is dirty. (This will save you a bunch of annoying messages about needing to save files.) If all of the tabs are pinned, it will open a new one.
Permalink
03.13.08
Posted in Eclipse, robobait at 4:27 pm by ducky
One of my user study subjects pulled out a keyboard shortcut that I had never seen before: control-shift-u.
I didn’t get to talk to him about it much, but it pops up a menu with Identifier, Implementing Methods, and Throwing Exception options.
The Identifier seems to find occurrences of that Java element in this file. I guess you could do almost the same thing if you do a FileSearch for a element’s name in one particular file, but that would be a lot more work.
For the Implementing Methods selection, it appears to tell you which methods in this file override/implement methods in the type you had selected. (Note that the type needs to be something right after the keywords “extends” or “implements”. If not, you will get an error message “Cannot search for current selection. Please select a type behind ‘implements’ or ‘extends’.”
You can select an exception (e.g. IOException), press control-shift-u, and select Throwing Exception in order to see which lines of source cause that exception to be thrown. Maybe you knew that read() threw an IOException, but if you didn’t realize that skip() also throws an IOException; this would show you not just that skip() was what was throwing the exception, but the exact line where it was doing so.
Permalink
03.12.08
Posted in Eclipse, programmer productivity, robobait at 10:38 pm by ducky
Cool!
I am doing a observational study of people using Eclipse, and I saw one of the users doing something that looked really useful.
If you hover over a Java element (type, method, or field), then you see the Javadocs for that element. Yeah, old news. You do that seventy times per day already.
If you shift-hover over a Java element, then it shows you the method’s source intead of the Javadocs!
This is a great way to get a peek down a navigation path before commiting to it.
Permalink
08.17.07
Posted in Eclipse, Hacking, robobait at 10:40 am by ducky
It took me way longer than it should have to get setup for my current project. I need to change some very fundamental behaviours of Eclipse. There is a plugin that does 80% of what I want, so I need to modify it.
I checked the plugin out of Eclipse’s CVS, but I couldn’t get at the Eclipse source (e.g. when I tried to do F3 or control-click on a class or method). I tried downloading the entire Eclipse source, but
- I got tons of errors because the projects weren’t set up right to refer to each other, and setting them up by hand would have been a nightmare.
- Everything got dog-slow.
SOLUTION
It turns out that I needed to first download the plugin from CVS, then convert it to a plug-in project. (Right-click on the project, then select PDE Tools, then select Convert Projects to Plug-in Projects.)
That gave me access to a lot of source, but not all of what I needed. To get other source, I needed to do
File -> Import -> Plugin&Fragments -> Project with source folder
then select the packages that I wanted the source for, Add, and then Finish.
Keywords: eclipse development, all eclipse source, attach source eclipse
Permalink
08.14.07
Posted in Eclipse, Hacking, programmer productivity, robobait at 3:26 pm by ducky
Cool! Eclipse has keyboard macros! Eclipse calls them “Editor Templates”, and has a bunch of them predefined. For example, if you type
sysout Cntl-SPACE
it converts that into
System.out.println();
with the cursor in the middle of the parens. Similarly, if you type
for Cntl-SPACE
you’ll get a short menu of options; selecting the first one (”iterate over array”) magically converts into
for (int i = 0; i < array.length; i++) {
}
with the first “i” selected If you type in “fooIndex”, then all the “i”s in the line change to “fooIndex”. Pressing tab takes you to the “array”, where you can then type in the name of the array. Press return, and then you are sent to the middle of the curly braces.
Whoa!
My old housemate, Chris Beekhuis, once set up macros like this and said that it made his coding significantly faster. I’m very much looking forward to using Editor Templates, and am a little puzzled as to why their existence isn’t being shouted from the rooftops. (Or was it? Did I have my headphones in at the time?)
(To see all of the pre-defined macros — or to define your own — go to Window->Preferences->Java->Editor->Templates. Or press Control-3, type “template”, and Editor Templates will be one of the options.)
Permalink
« Previous entries
