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.