Skip to content

Checkstyle GSoC 2014 Project Ideas

Roman Ivanov edited this page Apr 20, 2024 · 64 revisions

We passed to gsoc 2014. 3 projects participated.

====================================

Project Name: ANTLR grammar for Java 8 features

Accepted student: Ilja Dubinin

Mentor: Ivan Sopov

Backup mentor: Roman Ivanov

Skills required:

Project type: changes in Checkstyle's Java syntax grammar and update of existing functionality in order to support introduced changes.

Project goal: update Java ANTLR grammar in Checkstyle to support Java 8 syntax changes.

Description:

Checkstyle is a project that helps software developers to conform with the predefined style in Java code formatting and some best practices. Validation process in Checkstyle relies on correct parsing of Java source file which helps to build an accurate parse tree.

Java8 introduces a few features (paragraph "Section 3: Contributions") that cause Java language syntax changes: Lambda, Annotations on Java Types.

The goal of this project is to add support of Java 8 syntax changes to Checkstyle and allow developers to keep on using it when switching to Java 8, as right now Checkstyle does not work on java files that use features introduced in Java8.

Updated grammar will be available for all other projects that are interested in parsing of Java files, as ANTLR grammar is common for all implementations and is not specific to Checkstyle.

If students finish this task before the dead line, the rest of the time will be spent on updating ANTLR library to version 4. There are already some attempts to create Java 7 grammar in ANTLR 4.

Prove of necessity: issue on github, results of open survey

====================================

###Project Name: ANTLR grammar for comments and Documentation comments (JavaDocs)

Accepted student: Baratali Izmailov

Mentor: Daniil Yaroslavtsev

Backup mentor: Terence Parr (author of ANTLR)

Skills required:

Project type: changes in Checkstyle's Java syntax grammar and update of existing functionality in order to support introduced changes.

Project goal: add reliable parsing support of comments and Documentation comments (special format of comments that is used by JavaDoc tool) to Checkstyle's Java grammar. Which will allow Checkstyle to validate comments usage in code and let other developers write their custom validation rules based on ready-to-use parse tree (as it is done with java code now).

Description:

There is an official recommendation from Oracle on how to write JavaDoc comments, but there is no tool that checks comments usage and restricts/enforces comments style/format. Oracle's tool DocCheck, that was used before is deprecated now.

Checkstyle has few validation rules for JavaDoc comments those implementation were done based on separate java file parsing with usage of Regular expressions, that is not reliable and error prone approach. Absence of comments and JavaDoc comments grammar in Checkstyle have purely issue of time. Today JavaDoc comments is must have documentation technique for most libraries and frameworks. This fact puts JavaDoc format to position which is very close Java language specification.

To implement reliable parsing we need add support of comments to grammar level, that will build accurate parse tree. This would let developers to implement validation rules to ensure best practices of comments usage and easily customize validation in accordance with specific to team requirements. Right now there a lot of recommendation written on paper in additon to Oracle's (Google C++ Style Guide, Doxygen documentation tool recommendations, Code Complete Second Edition, Steve McConnell, chapter #32, Javadoc coding standards, Stephen Colebourne), but there are no tools that ensure compliance with these recommendations.

If parse tree structure is changed we need to update all existing Checks to support new tree elements appearance.

Updated grammar will be available for all other projects that are interested in Java files parsing, as ANTRL grammar is common for all usages and is not specific to Checkstyle.

Prove of necessity: bugs on SourceForge,feature request on SourceForge,issues on github, results of open survey.

====================================

Project Name: Checkstyle configuration for Google's Java Style guide

Accepted student: Max Vetrenko

Mentor: Ruslan Diachenko

Backup mentor: Roman Ivanov

Skills required:

  • Java (good)
  • Experience in writing validation rules (Checks) for Checkstyle, awareness of existing Checkstyle functionality (good)

Project type: analysis of existing Checkstyle functionality, development of new validation rules (Checks).

Project goal: review requirements for Java Code Style from Google, create Checkstyle configuration for it, extend existing Checks or create new Checks to cover Google's requirements.

Description:

Google's style guide for Java is second most popular guide that is open for all in internet. Checkstyle already cover Sun/Oracle notation that is present as config file.

Checkstyle project could easily automatically check almost all rules of Google's Java Style guide - http://google-styleguide.googlecode.com/svn/trunk/javaguide.html.

During this project we need to create a wiki page that show:

  • what rules are covered already;
  • what rules could be covered by new Checks;
  • what rules could be covered by extending existing Checks;
  • what rules could not be covered due to limitations of Checkstyle design.

After completion of GSoC 2014 proposal for JavaDoc support for our project (see above), Checkstyle could cover requirements from chapters "4.8.6 Comments" and "7 Javadoc".

Additionally we need to create wiki page that show coverage of Oracle style guide, that will help user evaluate Checkstyle coverage in transparent view, to let them decide on using Checkstyle for their needs.

After completion of wiki pages it is required to create configuration that could be used by Java community, existing Checks have to be extended and new Checks have to be created to cover Google Style Guide requirements to the maximum.

Prove of necessity: github issue, mail-list, just another issue.

Clone this wiki locally