-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Checkstyle GSoC 2019 Project Ideas
We did not pass to gsoc 2019
-
Optimization of distance between methods in single Java class
-
Reconcile formatters of Eclipse , NetBeans and IntelijIdea IDEs by Checkstyle config
-
Generation of web site content for all Checkstyle Modules from Javadoc
Skills required: basic Java and experience with syntax analysis.
Project type: new feature implementation.
Project goal: to update core library to the latest version in order to simplify Java grammar support.
Mentors: Roman Ivanov, Richard Veach, Ilja Dubinin, Pavel Bludov
Description: Checkstyle needs to have new Java grammar that is based on ANTLR4 version. This task is very difficult but it is critical for Checkstyle as ANTLR2 library is not supported (from 2006) and is far less efficient. Old version has a bunch of syntax analysis limitations that have already been resolved in ANTLR4. Our team is already experiencing difficulties with support of current grammar as it is too complicated due to limited parsing abilities of ANTLR2.
New features of ANTLR4 that we need:
- Antlr4 got support of direct left recursion that will simplify grammar significantly. We already have a lot of warnings of non-deterministic behaviour that is not possible to resolve in ANTLR2, example.
- Antlr4 has a bunch of UI tools that helps user to debug grammar and see how parser will work: IDE plugins, Parse Tree Inspector UI application from ANTLR distribution package.
Prove of necessity: results of open survey , Example of annoying warnings during the build
Skills required: basic Java , good analytical abilities, good background in mathematics.
Project type: new feature implementation.
Project goal: to make quality practices automated and publicly available.
Mentors: Roman Ivanov, Ruslan Diachenko, Timur Tibeyev
Description:
This task is ambitious attempt to improve code read-ability by minimizing user jump/scrolls in source file to look at details of method implementation when user looks at method first usage.
It is required to analyse a lot of code and find a model to minimize distance between methods first usage and method declaration in the same file and respect users preferences to keep grouped overloaded and overridden methods together. Some other preferences may appear during investigation of open-source projects.
First step is already done by our team, we created a web service that already calculate distances between methods and make DSM matrix to ease analysis - methods-distance. We already practice it in our project.
As a second step it is required to use a matrix of distances between methods and optimize it by some empiric algorithm to allow user define expected model of class by arguments. This will allow to use this algorithm as a Check to enforce code structure automatically during build time.
Results of the project:
- article with all details of analysis and algorithm details;
- new Checkstyle's Check with optimization algorithm to share the algorithm with whole java community.
Prove of necessity: we have a number of PRs where contributors put new methods at any possible place in a class but better place is close to first usage. Example #1, Example #2, Example #3, ....
Project Name: Reconcile formatters of Eclipse , NetBeans and IntelliJ IDEA IDEs by Checkstyle config.
Skills required: basic Java.
Project type: new feature implementation, analysis of existing IDE features.
Project goal: to make well-known quality practices publicly available.
Mentors: Roman Ivanov, Ilja Dubinin, Pavel Bludov
Description:
Usage of different IDEs in the same team is already a serious problem, as different IDEs format code base on their own rules and configurations. Unwanted formatting changes happen to code which complicate code-review process. Problem become more acute when project use static analysis tool like Checkstyle that has a wide range of code formatting Checks.
It is required to make it possible to use the same Checkstyle config to work in IDEs without conflicts with IDEs internal formatters. This will help team members be independent on IDE choice but at the same time keep the same format and code style throughout the team.
Main focus of this project is the analysis of formatting abilities of IDEs (indentation, imports order, declaration order, separator/operator wrap, .....) . Update existing Checkstyle Rules to be able to work in the similar and non-conflicting way.
Results of the project:
- create configuration for IDEs for Checkstyle project to let Checkstyle team use it and auto-format code to conform with checkstyle_check.xml file that is used by Continuous Integration.
- create Checkstyle config that follows default Eclipse formatting + inspection rules
- create Checkstyle config that follows default IntelliJ IDEA formatting + inspection rules
- create Checkstyle config that follows default NetBeans formatting + inspection rules
Prove of necessity: mail-list post #1, mail-list post #2, mail-list post #3 , discussion #1
Skills required: basic Java.
Project type: new feature implementation.
Project goal: to make well-known quality practices publicly available.
Mentors: Roman Ivanov, Richard Veach, Timur Tibeyev
Description:
Sun Code Convention was one of the first guidelines on how to write Java code. Sun Code Convention is marked as outdated (because of date of last update made in it) but best practices described there do not have an expiration date. [OpenJDK Java Style Guidelines] (http://cr.openjdk.java.net/~alundblad/styleguide/) is close to the final version and most likely will be successor of Sun Code Convention. But there is a number of projects in Apache that still follow Sun rules, so both configurations are in need by community.
Sun Code Convention is already partly covered by Checkstyle. A lot of validation Rules were added and changed in Checkstyle from the time when Sun's configuration was created (2004 year).
During the project it is required to review both documents in detail and prove publicly that Checkstyle covers all guideline rules. Missed functionality needs to be created, blocking bugs need to be fixed. Page Sun's Java Style Checkstyle Coverage needs to be updated. New page "OpenJDK's Java Style Checkstyle Coverage" need to be created. Both pages need to be formatted in the same way as it is done for Google's Java Style Checkstyle Coverage.
Prove of necessity: javadoc issues on github; results of open survey.
Skills required: basic Java.
Project type: new feature implementation.
Project goal: to make well-known quality practices publicly available.
Mentors: Roman Ivanov, Baratali Izmailov, Andrew Selkin
Description:
Project will mainly be focusing on automation of Documentation Comments (javadoc) guidelines by Checkstyle Checks. Reliable comments parsing was a major improvement in Checkstyle during GSoC 2014, archived results need to be reused to reliably implement automation of Javadoc best practices.
Separate configuration file with newly created Checks need to be created. Best practices in documentation make sense not for all projects. Javadoc validation matters only for library projects that need to expose online documentation in web publicly.
The result of this project will be a configuration file with the maximum possible coverage of Comment style guide. Report should look like Google's Java Style Checkstyle Coverage.
Prove of necessity: javadoc issues on github.
Skills required: intermediate Java.
Project type: new feature implementation.
Project goal: implement spell checking for java code for all identifiers .
Mentors: Roman Ivanov, Ruslan Diachenko, Baratali Izmailov
Description:
The correct spelling of words in code is very important, since a typo in the name of method that is part of API could result in serious problem.
Mistakes in names also make reading of code frustrating and misleading, especially when a typo in one letter makes developer to read javadoc or even implementation of the method.
Two most popular IDEs (Eclipse and IntelliJ IDEA) already have spell-check ability. It will be beneficial for Checkstyle to have the same functionality that could be used in any Continuous Integration system by Command Line Interface or as part of build tool (maven, ant, gradle, ....) with wide range of options to customize to users needs.
Features of existing spell-checkers need to be analysed -
IntelliJ IDEA Spellchecking ,
[Eclipse Spelling] (http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-36.htm).
There are numbers of open-source projects that do spell-check. It is ok to reuse them if licence is compatible. Examples: https://code.google.com/archive/p/bspell/ , http://www.softcorporation.com/products/spellcheck/, ...
Skills required: basic Java.
Project type: new feature implementation.
Project goal: simplification of Checkstyle development process .
Mentors: Roman Ivanov, Richard Veach, Andrew Selkin
Description:
There are two places in Checkstyle code base where developer put documentation in: Javadoc and Xdoc-maven files. One of the example is for ConstantNameCheck - Javadoc in source, Xdoc source. Site generation results in generated html javadoc, generated html page. Synchronisation of these two files is responsibility of either the author of the module or the author of change.
Right now that process is manual, time consuming and error prone. This leads to mistakes in documentation so users are seriously affected by missed details of Checkstyle's Checks implementation. This problem becomes even more acute when during patch acceptance(code-review) and testing process, functionality is changed a few times but documentation in Xdoc files left unchanged.
It is required to create:
- tool that does generation of xdoc files from javadoc comments of modules.
- tool needs to become part of Chekstyle build system to generate site content during "site" phase of build.
Prove of necessity: discussion #1, in all commits author need to update javadoc and then do the same update in xdoc manually. discussion #2 with real mock of how it should be done