|
|
| (28 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| − | == "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.
| |
| − |
| |
| − | == Callchain Completion ++==
| |
| − | '' In Progress. Christian, Ingo, SS 2011''
| |
| − |
| |
| − | == 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
| |
| − |
| |
| − | == Synonym based completion engine ==
| |
| − | ''Open.''
| |
| − |
| |
| − | When working with unknown APIs developers may use the code completion to search for methods applicable to what they currently want to do. Probably they already have a keyword they are looking for and just search the list of proposed methods matching that one. For example the developer already knows about arrays, but is new to collections and wants to know how many elements are contained in a collection. As known from arrays the developer starts to search for length and types in the prefix “len” to reduce the list of proposed completions. As we know there will be no proposals matching “len” as the method he is searching for is named size in collections. But if the completion engine would allow using synonyms it could propose size knowing that size and length are exchangeable words.
| |
| − |
| |
| − | == Highlighting of related methods ==
| |
| − | ''Open.''
| |
| − |
| |
| − | The eclipse editor already introduces highlighting for usages of the selected variable or method in the open document. Think of an extension to this concept that also highlights methods of interest based on similarity to the current selected method. Similarity of methods can be introduced by comparing what methods get called and which fields and types are used.
| |
| − |
| |
| − | == Web-Crawler for stacktraces ==
| |
| − | ''Open.''
| |
| − |
| |
| − | We are currently implementing a platform where developers got stuck on an error can search for their stacktrace to get help. Current search engines don’t fit very well with stacktraces. So we set up an optimized search with an index of stacktraces pointing to help resources on the web. To find those stacktraces on the web we need crawlers for all kind of structured resources. We currently have a crawler for bugzilla for example. An interesting type to crawl is a RSS-Feed as lots of discussion and help platforms provide them.
| |
| − |
| |
| − |
| |
| − | [[Category:Recommenders|ContributorTopics]]
| |
