It’s a great pleasure for me to present the Eclipse Code Recommenders tool tomorrow (Wednesday) evening at Eclipse Tools Day @ JAX2010.
I’m very happy to talk about the ideas and concepts behind code recommenders ranging from intelligent code completion and mined Javadocs up to smart bug detectors that can identify “strange” API uses and warn developers in the case of serious programming mistakes…
I’m looking forward to see you – and I would be happy to take your questions :-)
Cheers,
Marcel
Time and Location: 05.05.2010 | 18:10 - 18:30 | Watfordsaal I
May 4, 2010
May 3, 2010
It’s all about intelligent code completion...
On the advantages of code completion
The code completion feature of modern integrated development environments (IDEs) is extensively used by developers, up to several times per minute. The reasons for their popularity are manifold.
First, usually only a limited number of actions are applicable in a given context. For instance, given a variable of type java.lang.String, the code completion system would only propose members of this class but none of, say, java.util.List. This way, the code completion prevents developers from writing incompilable code by proposing only those actions that are syntactically correct.
Second, developers frequently do not know exactly which method to invoke in their current context. Code completion systems like that of Eclipse use pop-up windows to present a list of all possible completions, allowing a developer to browse the proposals and to select the appropriate one from the list. In this case, code completion serves both as a convenient documentation and as an input method for the developer.
Another beneficial feature is that code completion encourages developers to use longer, more descriptive method names resulting in more readable and understandable code. Typing long names might be difficult, but code completion speeds up the typing by automating the typing after the developer has typed only a fraction of the name.
On the limitations of code completion
However, current mainstream code completion systems are fairly limited. Often, unnecessary and rarely used methods (including those inherited from superclasses high up in the inheritance hierarchy) are recommended. Current code completion systems are especially of little use when suggestions are needed for big (incoherent) classes with a lot of functionality that can be used in many different ways.
For illustration, consider the code snippet depicted in listing above. Let’s assume that the developer triggered code completion on the swtTextWidget variable in line 3. Take a break and think about what code completion should offer to the developer in this context…
Well, let’s see what it actually offers:
164 methods seems to be too much, right? We don’t need methods like getMonitor or removeDisposeListener here. But before continuing the discussion (and to make clear that I’m not bashing SWT :-)), let’s see how code completion looks like for SWING classes like, say, JButton, after we invoked the constructor on such an instance:
One can’t see an improvement, right? But let’s get back to the example.
Because of the overwhelming number of proposals, we looked at the source code of several Eclipse plug-ins to see how developers actually use instances of SWT Text in their code. Thereby we observed that developers rarely used more than five methods of Text (in the context of IDialogPage#createControl()) and typically only setText, setLayoutData, addModifyListener, and setFont. Thus, the remaining 160 methods unnecessarily bloated the code completion window making it hard for developers to see what is actually relevant for their task at hand.
Can we reduce the clutter in code completion?
The example above outlines the basic problem of current code completion systems. Our solution to this problem - a context-sensitive code completion - is shown in below. Instead of presenting all 164 potentially callable methods on the text variable, code completion only presents the most likely ones in this context to the user, i.e., setText, setLayoutData, and addModifyListener:
In a (very small) nutshell, the tool works as follows: (i) we grabbed a few Eclipse plug-ins, (ii) looked on how developers actually used Text widgets in their code, (iii) created a database from these usages, (iv) built an intelligent code completion engine that (every time code completion is triggered) looks up the appropriate methods a developer may be interested in, and (v) presents them to the user.
Of course, we Text is not the only class we examined. We created databases for Eclipse SWT, JFace and some parts of Eclipse UI – and if you are interested to check out the tool, visit our project page and see a demo screencast showing the Eclipse Code Recommenders tool in action.
Disclaimer ;-)
The intelligent code completion feature of the Eclipse Code Recommenders tool is a research prototype. And as such, we appreciate your comments about the idea, implementation issues and other cool ideas.
So, what’s your feeling about having such an intelligent code completion? Do you think having this in Eclipse would be a cool (and helpful) feature? Should we start a large-scale training for more Eclipse Frameworks?
All the best,
Marcel
The code completion feature of modern integrated development environments (IDEs) is extensively used by developers, up to several times per minute. The reasons for their popularity are manifold.
First, usually only a limited number of actions are applicable in a given context. For instance, given a variable of type java.lang.String, the code completion system would only propose members of this class but none of, say, java.util.List. This way, the code completion prevents developers from writing incompilable code by proposing only those actions that are syntactically correct.
Second, developers frequently do not know exactly which method to invoke in their current context. Code completion systems like that of Eclipse use pop-up windows to present a list of all possible completions, allowing a developer to browse the proposals and to select the appropriate one from the list. In this case, code completion serves both as a convenient documentation and as an input method for the developer.
Another beneficial feature is that code completion encourages developers to use longer, more descriptive method names resulting in more readable and understandable code. Typing long names might be difficult, but code completion speeds up the typing by automating the typing after the developer has typed only a fraction of the name.
On the limitations of code completion
However, current mainstream code completion systems are fairly limited. Often, unnecessary and rarely used methods (including those inherited from superclasses high up in the inheritance hierarchy) are recommended. Current code completion systems are especially of little use when suggestions are needed for big (incoherent) classes with a lot of functionality that can be used in many different ways.
For illustration, consider the code snippet depicted in listing above. Let’s assume that the developer triggered code completion on the swtTextWidget variable in line 3. Take a break and think about what code completion should offer to the developer in this context…
Well, let’s see what it actually offers:
164 methods seems to be too much, right? We don’t need methods like getMonitor or removeDisposeListener here. But before continuing the discussion (and to make clear that I’m not bashing SWT :-)), let’s see how code completion looks like for SWING classes like, say, JButton, after we invoked the constructor on such an instance:
One can’t see an improvement, right? But let’s get back to the example.
Because of the overwhelming number of proposals, we looked at the source code of several Eclipse plug-ins to see how developers actually use instances of SWT Text in their code. Thereby we observed that developers rarely used more than five methods of Text (in the context of IDialogPage#createControl()) and typically only setText, setLayoutData, addModifyListener, and setFont. Thus, the remaining 160 methods unnecessarily bloated the code completion window making it hard for developers to see what is actually relevant for their task at hand.
Can we reduce the clutter in code completion?
The example above outlines the basic problem of current code completion systems. Our solution to this problem - a context-sensitive code completion - is shown in below. Instead of presenting all 164 potentially callable methods on the text variable, code completion only presents the most likely ones in this context to the user, i.e., setText, setLayoutData, and addModifyListener:
In a (very small) nutshell, the tool works as follows: (i) we grabbed a few Eclipse plug-ins, (ii) looked on how developers actually used Text widgets in their code, (iii) created a database from these usages, (iv) built an intelligent code completion engine that (every time code completion is triggered) looks up the appropriate methods a developer may be interested in, and (v) presents them to the user.
Of course, we Text is not the only class we examined. We created databases for Eclipse SWT, JFace and some parts of Eclipse UI – and if you are interested to check out the tool, visit our project page and see a demo screencast showing the Eclipse Code Recommenders tool in action.
Disclaimer ;-)
The intelligent code completion feature of the Eclipse Code Recommenders tool is a research prototype. And as such, we appreciate your comments about the idea, implementation issues and other cool ideas.
So, what’s your feeling about having such an intelligent code completion? Do you think having this in Eclipse would be a cool (and helpful) feature? Should we start a large-scale training for more Eclipse Frameworks?
All the best,
Marcel
Subscribe to:
Posts (Atom)