Skip to main content
Jump to: navigation, search

Difference between revisions of "Recommenders/Attic/ContributorTopics"

m (Automatic Method Ordering)
m (Collecting relevant items while developrs traverse APIs)
Line 3: Line 3:
 
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.
 
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.
  
== Collecting relevant items while developrs traverse APIs ==
+
== Developers how looked at this Java Elements frequently also visited these API Elements - Building an API Element Traversal Data Collector ==
  
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. What we can do is to store what a developer was looking at, so we can extract interesting points and show them others which hit the same starting point. So what we finally want to have is an Eclipse plug-in collecting information about API traversal and a view that shows the collected data, so that others can see information like “Developers who looked at this method also looked at…”
+
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 :)
  
 
== Local Code Search ==
 
== Local Code Search ==

Revision as of 12:50, 4 April 2011

"Clean Code" Method Sorter / Code Formatter for Eclipse

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 how looked at this Java Elements frequently also visited these API Elements - Building an API Element Traversal Data Collector

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 :)

Local Code Search

We introduced the first version of our Code Search plug-in and found parties interested in local versions. Due to copyright and license problems some parties are not allowed to use any Code Search, but they would be able to use them if the provided sources will only contain their own code. As this code base can be potentially large, developers benefit even in this case. So what we need is a plug-in creating the index for our Code Search from local sources.

Query Builder for Code Search

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

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