Skip to content
Todd Schiller edited this page Apr 20, 2015 · 2 revisions

Introduction

Celeriac is developed and maintained by the Programming Languages and Software Engineering group at the University of Washington. We welcome feedback and contributions from developers, such as:

  • Enhancement requests and bug reports
  • Feedback on documentation
  • Tips and best practices to help new users
  • Example use cases
  • Feedback about supporting other languages targeting the CLR (e.g., IronPython)
  • Patches and features (if you'd like suggestions on what to work on, please contact us).

These can be submitted to the project coordinators Kellen Donohue and Todd Schiller, or via the Google User Group.

Building and Running

The project can be built from Microsoft Visual Studio 2010 or 2012 using the Celeriac solution.

Code Guidelines

In general, follow the MSDN C# guidelines.

Issue Tracking and Version Control

The Celeriac project uses GitHub for version control; we encourage new contributors to clone the project and submit a pull request. You may also request to be granted commit access.

All tasks should be tracked using the issue tracker. TODOs written in source code should include the associated issue number, preferably in the form "TODO(#XX): explanation of what is wrong / needs to be done", where XX is the issue tracker number. This single format makes it easy to search for the relevant code for a particular bug number.

When possible, commit messages should include the relevant issue #, similarly, when an issue is marked as fixed the comment should include the corresponding revision #.

Style

The project uses the style described in http://www.sourceformat.com/pdf/cs-coding-standard-bellware.pdf with the following exceptions:

  • Spaces are used instead of tabs; an indent is 2 spaces, and wrapped lines require are doubly indented. Use Visual Studio formatting (Ctrl+E, Ctrl+D) to enforce consistent formatting.
  • 100 character column limit.

Code Analysis

Code Analysis should give no warnings with the Microsoft Basic and Extended Correctness and Design Guidelines. It is OK to suppress a warning, however a reason should be included.

Test Suite

Before committing, ensure that you run and pass the [test suite](Running Tests)