Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Recommenders/Attic/ContributorTopics

< Recommenders
Revision as of 14:12, 19 May 2011 by Bruch.st.informatik.tu-darmstadt.de (Talk | contribs) (Flexible Configuration of Content Assist lists)

"Clean Code" Method Sorter / Code Formatter for Eclipse

In Progress. Mateusz, Fabian; SS 2011

Coding conventions as discussed, for example, in Clean Code recommend that methods should be ordered in the sequence they get called. This drastically improves the readability of your code, since the amount of jumps in code required to understand the code are reduced to a minimum. Manual ordering is an annoying and time consuming task. During this hands-on you will develop an Eclipse Code Formatter that sorts a class' members according to Rober C. Martin's Clean Code style guide.

Developers who looked at this Java Elements frequently also visited these API Elements - Building an API Element Traversal Data Collector

Partially In Progress. Stefan works the selection listener as part of his GSOC; SS 2011

While developers learn how to solve a specific task they need to learn about the given API. Assuming they found a starting point they have to figure out if there are additional things they must know about or which would help them. This is something every developer will be confronted with again and again. For instance, if a developer is looking at the implementation of Wizard#addPages he might also be interested in looking the methods Wizard#addPage or Wizard#setNeedsProgressMonitor.

But how do you get the information what you should have a look at? Webshops like Amazon follow a pretty simple approach. They just look at how their users interact with their webapp and collect the information what the user looked (i.e., clicked) at and then run some mining techniques on this data to extract valuable data. During this hands-on you will create an Eclipse plug-in that collects the information what API elements developers investigated and publish this information to a central knowledge repository. In a subsequent step this data will be analyzed to find valuable patterns in this data - howerver, this is not part of the hands-on :)

Example Code-Search Engine 4 Eclipse

In Progress. Katrin; SS 2011

Finding good code examples is a difficult task. Code-search engines like Krugle or Google code-search aim to support developers during this task. However, their search capabilities are somewhat limited. Recently, the Code Recommenders project published a first prototype of next generation code search engine tightly integrated into Eclipse.

However, due to copyright and license issues some companies prohibit the use of code-search engines that work on untrusted codebases. Thus, during this hands-on you will design a local, lucene-based code-search engine that works on the local Eclipse installation an workspace only.

Query Builder for Code Search

In Progress. Niklas; SS 2011 In our current implementation of Code Search we use Code Completion as input to build search queries. This is an easy and intuitive way to create queries, but it is limited in flexibility and adjustment of terms. So we think that a view allowing developers to define the elements of the query in an intuitive way will be a necessary supplement.

Additionally it is possible for the client to determine which feature weights should be used for scoring on server side, but as a view is missing to edit those weights this feature is not usable, yet.

Flexible Configuration of Content Assist lists

In Progress. Thomas, Gerrit; SS 2011

The preference page for the Eclipse Completion Engines currently allows you to enable multiple engines on the default tab. But for cycling multiple tabs it is only possible to have one engine on each cycling tab. As Code Recommenders adds multiple engines, we faced the problem that we must aggregate our engines to provide useful configurations to developers. This change is filed and accepted as feature request by the JDT team. There are some adapted screenshots attached to the feature request to give a hint of how this could be implemented: https://bugs.eclipse.org/bugs/show_bug.cgi?id=340876

Indexed API Explorer

With Chain Completion we introduced how to get an instance of a needed type. Chain Completion uses the available declarations and searches the API for paths directing to the needed type. But this approach is limited to paths available by starting from types already used. Another approach is to first create an index of the whole API included in the current classpath and second if a specific type is needed just checking the index to get points where that type is given. We can then start to search for paths backwards. These points can be static variables or just constructors.

Back to the top