This repository has been archived by the owner on Jun 6, 2021. It is now read-only.
/
STYLE
65 lines (44 loc) · 2.12 KB
/
STYLE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
== Satori: Libraries and Tools for Epiphany ==
-- Style --
This is a guide to the general code style used in the Satori source base.
If you're contributing code to the project, you should make sure to
follow these. We are rather strict about these rules as we believe that
they help us keep a clean and consistent source base.
++ Indentation ++
We indent with 4 spaces, always, everywhere. Do not use hard tabs.
++ Spacing ++
One place where spacing is very important is in expressions. You should
always put a space on all sides of binary and ternary operators, for example.
Note that this is not necessary for unary operators.
Spacing is not necessary in function calls either (other than after a comma).
For example, you should do:
* foo()
* foo(bar)
* foo(bar, baz)
It's recommended to use empty lines between lines that are not closely
related. This helps a lot when skimming code.
++ Naming ++
We roughly follow the conventions used in most C# code:
* All types and methods are PascalCase.
* All parameters and variables are camelCase.
* All interfaces are IPascalCase.
* All type parameters are TPascalCase.
You should have a VERY good reason if you're going to deviate from these
naming rules. We want to keep Satori's interfaces consistent with most
other C# code so using it doesn't feel awkward.
++ Comments ++
Comments should be written in clear, concise English with correct grammar
(yes, this includes punctuation). Avoid using abbreviations and acronyms
unless they are generally well-understood in the context. Also, you should
avoid overly verbose comments (often referred to as literate programming),
as they make it harder to read the code. In general, don't comment on the
obvious or on things that are considered common sense.
Bad comments:
* // do some space opts
* // revert to prev tok
Good comments:
* // Do some space optimizations.
* // Revert to the previous token.
++ Documentation ++
Everything exposed as part of the public API should have XML documentation
attached to it, describing what the API does.