An overarching goal is to develop tools that look and feel like the .NET framework. Therefore we should follow the standardized .NET convention e.g. as described in The Framework Design Guidelines Book (http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/0321545613) and as defined by the FxCop tool for Visual Studio or Gendarme for MONO. We also encourage following coding conventions defined by StyleCop.
All source code files should include the copyright notice header.
Contributors are encouraged note major code contributions and changes with a date in the header. This is primarily to help recognize contributions.
Our preferred language for the core components is C#. Extensions and applications can be written in C# or VB.NET or other .NET language.
U.S. English will be used for all internal documentation, exception strings, enumerations, and ToString methods in the core components. Internationalization will generally occur only at the application level.
Don't commit broken code.
Naming, Namespaces and Assembly Names
DotSpatial is the root of the namespace. Namespaces should be descriptive of function not of sub-project. In other words "Topology" not "NTS". This requires more integration of projects - but will also help meet the goal of a well-integrated project. Assemblies should be named to match the associated namespace - e.g. DotSpatial.Topology.dll should contain the DotSpatial.Topology namespace.
Extensions of a namespace can be compiled to a separate assembly such as DotSpatial.Topology.Foo.dll. Extensions might also include project names such as DotSpatial.Data.Raster.GDAL.dll as a wrapper for the GDAL unmanaged code/data provider.
Compiling and Build Settings
In Visual Studio 2010 Warning Level should be set to Level 4 and treat warnings as errors (find equivalent setting for Mono). We don't want code that generates lots of warnings.
Build Configurations: Build target... any cpu? need advice on this. Provide release and debug versions. Goal is to support both 32 and 64 bit OS's.
Unit Testing
We will write extensive unit tests for all functions to test functionality against appropriate standards.
Use of multiple data sets for testing.
Deployment
Our goal is zip file based deployment. In other words, all current assemblies can be downloaded in a single zip file for use by third party programmers.
Applications can/should be deployed using an installer (e.g. MSI, Click Once, Inno Setup)
Architecture Approach
Maintain clear separation (e.g. in namespacing and assemblies - following MVVM style) of GUI code from core functionality - this is to help support unit testing as well as UI portability (e.g. use of WPF versus Silverlight versus Windows forms)
Assembly and Versioning Info
All Assembly information should be provided in every DotSpatial assembly as follows (either in the VersionInfo.cs, AssemblyInfo.cs, AssemblyInfo.vb):
<Assembly: AssemblyCopyright("Copyright (C) 1998-2010 either OSGeo or DotSpatial Project - tbd")>
<Assembly: AssemblyTrademark("DotSpatial is a trademark of the project team/OSGeo tbd ")>
<Assembly: AssemblyConfiguration("32 bit versus 64 bit or any CPU build/release")
<Assembly: AssemblyCulture(if non-gui then state "Culture Neutral", otherwise state approach for handling languages)
<Assembly: ComVisible(false)>
<Assembly: CLSCompliant(true)>
Sample Code, Applications, and Programmer Documentation
Every assembly should have a short (paragraph) relatively static description on the CodePlex wiki.
All libraries and functions should have well documented sample code on the CodePlex web site.
A few small sample applications will be built that can be downloaded and explored as a means to study the API.
Internal code should be documented with the /// comment notation.
Communication
General discussions about use, role and application of DotNet in the Open Source GIS community should be sent through the OSGeo DotNet mailing list: [email protected] (http://lists.osgeo.org/mailman/listinfo/dotnet). This is an open list that anyone can join.
Discussions specific to the DotSpatial Developer community - including everyone with developer rights on the CodePlex site are held on this list: [email protected] which can only be joined/viewed by people who are members of the DotSpatial project on CodePlex.
Discussions relevant to the DotSpatial Steering Committee are held through: [email protected] which can only be joined/viewed by people who are members of the DotSpatial Project Steering Committee.
How to Join the Team
Individuals desiring to join the project team and developers should
Download and become familiar with the source code (only requires a CodePlex name, not project membership)
Look at the task and issues lists and identify opportunities for contributing
Existing developers will test the code contributions and if appropriate integrate it with the source repository.
After a developer makes 2 or 3 code contributions in this manner, then they can request code commit rights. The project coordinator(s) can decide to grant such rights based on feedback from developers and steering committee members.
Discussion points needing resolution:
Which unit testing system to use?
If, how, where to set up automated builds?
If and how should we link the sample code in the wiki pages to the automatic builds and unit tests to ensure that the sample code does not get out of date?
Version numbering. How and who decides when the version numbering changes? Should each library change independently? or should there be a global Version 1.x of the full DotSpatial package?