Developer Guidelines

Summary

The FlexWiki administrative staff have developed some guidelines to help ensure that FlexWiki continues to evolve as robust and reliable software

The goal of these developer guidelines is to encourage developers to create correct code in FlexWiki project which look and feel the unified way. We want to have simple and sound rules which are easy to follow. They are based on industry standards and recommendations and also on our personal development experience.

General

All contributed code must have a corresponding NUnit unit test. Code without sufficient test coverage will not be accepted.
Contributed code should follow the Design Guidelines for Developing Class Libraries.aspx. We're not going to be Draconian about it, but adopting a consistent style helps maintainability. Additionally, we may add FxCop enforcement to the build in the future, and following the guidelines goes a long way towards making FxCop happy.
Make sure you're subscribed to the FlexWikiDevelopersList
Make sure you have a WikiHomePage
Make sure you've read the DeveloperHome page for important information about how we do things
Before you commit, make absolutely sure that you aren't breaking anything

Run through reasonable manual testing
Make sure that all automated tests pass (see StandaloneTestingDetails)
Add your own automation tests
Run build.cmd to simulate the automated build

If you are fixing a BugReport or fulfilling a FeatureRequest, update the tracker on the SourceForgeProject site.
Every project should contain a link to the SharedAssemblyInfo file (follow the link to learn more)

Code file organization

You must place the LicenseStatementTemplate at the top of every source file.
One class/interface/enum per file, please: combining them makes it hard to find things.
Name C# files after the type they contain.
In class or struct declaration put members in the following order:

Fields
Constructors
Properties
Methods

Within these groups, public first, then protected, then internal, then private. Within each of those, sort members alphabetically. Combined with the built-in VS outline mode, this allows for very quick navigation directly to a particular member.
You can use the Regionerate tool with the FlexWiki RegionerateSettings to organise your files according to the above guidelines.

Naming guidelines

Follow the Microsoft Guidelines for Names.aspx. FxCop should be used to verify these guidelines as any other critical design issues.
The guidelines do not provide specification for private fields. So, we strongly suggest to use camelCase names with the following prefixes:

Instance private fields are prefixed with an underscore "_".
Static private fields are prefixed with "s_".
Private constants are prefixed with "c_".

Code formatting

Use automatic code formatting feature in Visual Studio (Ctrl+E, D) with default settings. Default formatting mode uses 4 spaces for indentation and starts curly braces at a new line.
Use curly braces always even if they can be omitted according to C# rules, i.e. prefer

if (Condition)
{
    DoSomething();
}

instead of

if (Condition)
    DoSomething();

Use of #region

#region should not be used at all to group members. That's because if you organize members as it described above, then it just gets in the way. Outline mode in VS (Ctrl+M, O) usually makes an entire class fit on one or two screens, and regions make navigation harder in that case, not easier.
Regions are useful within methods to collapse long sections of code, although one could argue that at that point a refactoring is due.
Use a #region at the beginning of a file to collapse the license/copyright statement.
Visual Studio automatically creates regions when it generates stubs for interface members’ implementation. These regions should be removed. If the interface is implemented implicitly, then the members are also members of the class, and get are sorted alphabetically. If the interface is implemented explicitly, then alphabetizing automatically groups them together anyway if you include the interface name as part of the member name. All interface members should be put together with public members of the type.

	Show Changes
	Edit
	Print
	Recent Changes
	Subscriptions
	Lost and Found
	Find References
	Rename
	Administration Page