Contributors

Contributions Guidelines for Command Line Parser Library
Giacomo Stelluti Scala (gsscoder@gmail.com)
Last Mod.: 2013-04-26

Tools:
- MS FxCop (VSSTUDIO CodeAnalysis)
- MS StyleCop
- JetBrains R#

Premise
These are suggestions don't be stuck to send pull requests just because you think that something written here is not perfectly followed.
It is possible (or better is almost certain) that also the writer of this document violates some rule... but he tries to adhere!
The project tree includes also two ReSharper files that I try to keep in sync with StyleCop.

Code Formatting
- No tabs (\t), use for 4 spaces instead.
- Don't overuse spaces:
    void Method(param1, param2, param3) -> OK
    void Method ( param1, param2, param3 ) -> TOO SPACES!
- Align with one indentation:
    if (lonlongstuff1 == longlongstuff2 || (longlongstuff3 > 0 &&
        longlongstuff4 < 0)) -> OK
    if (lonlongstuff1 == longlongstuff2 || (longlongstuff3 > 0 &&
                                            longlongstuff4 < 0)) -> TOO INDENTATION!

Coding Style
- Adhere to .NET Framework Coding Guidelines (http://msdn.microsoft.com/en-us/library/ms229042.aspx) for public types.
- Kernel of 2.0+ has been rewritten following Functional Programming principles (http://en.wikipedia.org/wiki/Functional_programming).
- A minor use of side-effects could be allowed if isolated to "out-side" world (e.g.: see Tokenizer type).

Unit Tests
Personally 99% of times I write the unit tests before the desidered modification (TDD). Anyway please submit changes along with at least one unit test (this is also useful to let me understand what the change impacts).

PR etiquette
A not discussed PULL REQUEST could lead only to extra work for project coordinator;
PR are well accepted, anyway they should be result of new or open discussions.

Breaking Changes
Please discuss any important modification or something that breaks the Public API.

Not covered here
You can take existing code as a model or write me.