# Contributing

- About
- Checkstyle
- Documentation
- Release Notes
- Configuration
- Property Types
- Running
- Ant Task
- Command Line
- Available Checks
- Standard Checks
- Javadoc Comments
- Naming Conventions
- Headers
- Imports
- Size Violations
- Whitespace
- Modifiers
- Block Checks
- Coding
- Class Design
- Duplicate Code
- Metrics
- Miscellaneous
- Optional Checks
- J2EE Checks
- Extending Checkstyle
- Writing checks
- Writing filters
- Writing listeners
- Javadoc
- SourceForge
- Mailing Lists
- Bug Database
- Feature Requests
- Developers
- Project Page
- CVS Repository
- Contributing
- Introduction
- Quality matters
- Submitting your contribution

- Hosted by:

## Introduction

Hey, good to see you on this page. It means that you are considering a contribution of your own work to the Checkstyle project. We welcome anything: bugfixes, new check modules, unit tests, documentation improvements, build process simplification, etc.

This document assumes you are working with the CVS version of checkstyle and that you are familiar with some standard development tools (CVS, Ant, JUnit).

## Quality matters

The developer team of checkstyle is really a lazy bunch of people. We try to avoid work as best as we can, but most of all we try to avoid working on bugs that are reported by end users.

To that end, we use a set of development tools that ensure that the quality of our code is kept at a fairly high level. Like most projects today, we use JUnit to test our code. However we do take this one step further and measure the coverage of our unit tests using EMMA. This means it is not sufficient to pass all tests, but the tests should ideally execute each line in the code.

Besides using unit testing, we obviously also use checkstyle to check it's own code.

We have the build target gump in our Ant buildfile that builds checkstyle, executes all tests, and runs checkstyle on it's own code. That target should pass without errors.

If you add new end user features, remember to document them.

## Submitting your contribution

Once you have made sure that your changes pass the gump target, and everthing is documented, you are ready to submit your work.

If you have created new files, put them in a tgz file (or zip if you are on Windows). If you have changed existing files, create a unified diff using CVS. To do that, open a command line, cd to the home directory of checkstyle (where build.xml is located) and execute cvs diff -u > mychanges.patch.

Create a new item in our patch tracker and add the tgz/zip/patch files you created. Make sure the text in the tracker explains the purpose of your contribution. When you create a tracker entry, a notification email about your contribution will automatically be sent to the developer mailing list. Be prepared to answer questions and do some polishing work.

We are not only lazy but at times we are also busy with our day jobs. This means that you might not always get an immediate answer. You are not being ignored, and we value your work - we might just be too busy to review your code, especially if it is a bit complex. If you don't get a response within two weeks, feel free to send a reminder email about your tracker item.

Copyright © 2001-2005, Oliver Burn