General development information¶

If you are interested in becoming a committer on the CCNet project, please contact the CCNet project administrators http://sourceforge.net/projects/ccnet . Bestowing of commit rights is generally contingent on having a number of contributed patches accepted, participation in the CCNet community, and a demonstrated knowledge of the codebase and of how to do test-driven development.

Registration Process¶

1. If you have not already done so, please review and send an email expressing your acceptance of the CCNet Contributor License Agreement to the mailto:ccnet-contributors-agreement@googlegroups.com.
2. Create an account on Cruisecontrol.org and send your user id to the project administrator to receive write access to the wiki.
3. Register for the http://groups.google.com/group/ccnet-user and CCNet developers http://groups.google.com/group/ccnet-devel mailing lists.
4. Create an account on Github, and make a fork.

Starting development¶

Once you have completed registration, you are ready to start working on the code. Here is how to get started.

1. Please review the Developer Guidelines below. If you have any questions about the coding standards, please ask on the CCNet developers http://groups.google.com.ag/group/ccnet-devel/ mailing list.
2. If you are looking for something to work on, take a look through the issue list and pick up an issue.
3. If you're change(s) are done, send a pull request.

Getting information¶

You can always ask for help via the http://groups.google.com/group/ccnet-devel. Other places :

• RuWi blog
• Automated Coder
• the forums

Developer Guidelines¶

Development Practices¶

• Test-first development. Code without unit tests will not be accepted.
• Refactor mercilessly; however, notify the list before making large, broad-reaching refactorings.
• Small methods. Long methods will be collected and emailed to the list until a refactored solution is found.
• Use guard clauses.
• Write acceptance tests wherever possible.

TDD Standards (Unit Testing and Design)¶

These standards are ideals, and not necessarily the current state of the code

• No unit-testing of private methods. TDD implies it is unnecessary.
• Don't make methods public just so you can test them (see above)
• Use Constructor Dependency Injection where possible.
• Use Dynamic Mocks for Constructor Dependencies.
• Interface-first design is preferred (i.e. all Constructor Dependencies should be interfaces)
• DefaultXYZ as a name is a smell. What exact type of interface are you implementing?

Coding Standards¶

• Respect the brace style. Curly braces at the start of the line:
  

  1public Class Foo
  2{
  3  public Foo()
  4  {
  5      Console.WriteLine("Hello World!");
  6  }
  7}
  

• Use C# naming conventions: methods, properties, classes should all start with upper-case letters.
• Namespaces should be C# style. They should start with 'ThoughtWorks.CruiseControl.XYZ' where XYZ is the Visual Studio Project Name. Sub-namespaces should map to directories where source files are saved.
• One file, one class -- unless the inner class is private.
• All member variables should be prefixed with an underscore (ie. \_name).
• The ternary operator is fine as long as the conditions are very simple.
• Avoid assignment in conditionals -- extract to method instead
• Avoid magic numbers, use a nested enum or an inner class with public const members instead.
• Use spaces after punctuation such as commas and spaces, in accordance with standard written grammar. For example, please include spaces after semi-colons, between equals signs and after keywords
  

  1for (int i = 0; i < array.Count; i++):