Skip to content

Commit 3e039b8

Browse files
committed
Add contribution notes.
1 parent c82e462 commit 3e039b8

2 files changed

Lines changed: 92 additions & 0 deletions

File tree

.editorconfig

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
# EditorConfig is awesome: http://EditorConfig.org
2+
3+
# top-most EditorConfig file
4+
root = true
5+
6+
# Unix-style newlines with a newline ending every file
7+
[*]
8+
# Note: T4 Editor cannot handle non-CRLF, so locally use CRLF and push as LF via git
9+
end_of_line = crlf
10+
insert_final_newline = true
11+
12+
# Matches multiple files with brace expansion notation
13+
# Set default charset
14+
[*]
15+
charset = utf-8
16+
17+
# 4 width tab indentation
18+
[*.{cs,tt,ttinclude}]
19+
indent_style = tab
20+
tab_width = 4
21+
22+
# 2 space indentation
23+
[*.{xml,csproj}]
24+
indent_style = space
25+
indent_size = 2

CONTRIBUTIONS.md

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
# Contributions
2+
3+
## You can contribute...
4+
5+
* Submit issues in github. But please ensure that your question is already described in wiki(š) or samples(š)
6+
* Pull-request. Note that your request might be rejected if it break existing test or it become applicable because of other fix(es).
7+
* Write wiki (documentation request in github issues is OK, but please note that telling why/what documentation needed is harder than code, so it is happy if you write the purpose and example for the request).
8+
* Improve unit tests more efficiently.
9+
* Patches for English are welcome :)
10+
* etc.
11+
12+
## Branching
13+
14+
MessagePack for CLIs branches are:
15+
* Version branch for every *.n release. Active branch is the latest minor version having release tags.
16+
** If the latest version branch does not have any tags, so it is developing branch.
17+
* Mater branch is synchronized with active branch when the new release is done.
18+
** You should submit pull-request for active branch. It will be merged newest develop branch and master branch in the future.
19+
20+
## Guidelines
21+
22+
### General Style
23+
24+
* Keep backward compatibility for published API.
25+
* Write Unit test for APIs, and optinally stable/complex internal module.
26+
* Think interoperability. If you want full-feature serializer only working on .NET, use `BinaryFormatter`. Interoperability for many languages is advantage of MessagePack.
27+
28+
### Coding Style
29+
30+
Follow existing styles, period. Please keep existing style because changing style is not so valuable, and out times should be spent to improve software itself unless the coding style causes observable and measurable impact.
31+
32+
#### Commonly Used Styles
33+
These rules are commonly acceptted rules I think, so I omit their rationale.
34+
35+
* Published APIs follows Framework Design Guidelines. See, T.B.D. This rule can be checked by FxCop (CodeAnasys feature in VS).
36+
* Allman style.
37+
* Locals uses camelCasing, fields uses camelCasing precding underscore like '_foo'.
38+
** Note that 's_', 'm_', 't_' prefixes are not used.
39+
* All methods are PascalCasing even if they are private. camelCasingName(...) expression should be delegate invocation except P/Invoke.
40+
41+
#### Specific Styles
42+
43+
These rules are not so common (at least, they are differ from .NET Core/Mono style), so I should describe their reason:
44+
45+
* Specify 'this' keyword to distinguish instance fields and static fields. I think [TheradStatic] and ThreadLocal<T> is rare than mutable statics, so these should be distinguished by field name like `xxxPerThread`.
46+
* Use PascalCasing for private constants. In reality, I do not have policy for this, just following R# default.
47+
* Put braces even if the statement is single line. It is multi-layer guard for a little but destroying bug.
48+
* Use tab for indentation. Most tools supports tabs, developer can be configure spacing for a tab usually, code formatting tools act better for tab.
49+
* Verbose spacing. It is a kind of multi-layer guard.
50+
51+
OK, use formatting files below:
52+
* Visual Studio š
53+
54+
### Unit Testing
55+
56+
* Please write unit testing to verify your reported issue is reproduced and solved.
57+
* If you add new feature, write unit testing with testing methodology like border value analysis.
58+
59+
## Trouble Shooting
60+
61+
* Q: I cannot build MsgPack.compat.sln on Mono w/ xbuild error.
62+
** A: Currently, this issue is not trucked, so use msbuild.exe to build unity lib and/or .NET 3.5 port.
63+
64+
* Q: I cannot run Windows Phone unit tests.
65+
** A: The tool looks like not so stable, but you ensure that:
66+
*** Recent Visual Studio Update is applied
67+
*** And recent Windows Phone Tools are applied http://www.microsoft.com/en-us/download/details.aspx?id=43719š

0 commit comments

Comments
 (0)