aboutsummaryrefslogtreecommitdiff
path: root/STYLE
blob: 666ad2805b17ab958a19e0885970aee4e97c64c2 (plain)
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
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
This STYLE file taken directly from OpenRC, and based on the heritage of
netifrc, we are sticking to it.

==== Original file beyond this point.
This is the openrc style manual.  It governs the coding style of all code
in this repository.  Follow it.  Contact openrc@gentoo.org for any questions
or fixes you might notice.

##########
# C CODE #
##########

The BSD Kernel Normal Form (KNF) style is used:
	http://en.wikipedia.org/wiki/Indent_style#BSD_KNF_style
Basically, it's like K&R/LKML, but wrapped lines that are indented use 4 spaces.

Highlights:
	- no trailing whitespace
	- indented code use tabs (not line wrapped)
	- cuddle the braces (except for functions)
	- space after native statements and before paren (for/if/while/...)
	- no space between function and paren
	- pointer asterisk cuddles the variable, not the type

void foo(int c)
{
	int ret = 0;

	if (c > 1000)
		return;

	while (c--) {
		bar(c);
		ret++;
	}

	return ret;
}

##################
# COMMIT MESSAGES #
##################

The following is an example of a correctly formatted git commit message
for this repository. Most of this information came from this blog post
[1], so I would like to thank the author.

### cut here ###
Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug."  This convention matches up with commit messages generated by
commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, preceded by a
  single space, with blank lines in between, but conventions vary here

- Use a hanging indent

Reported-by: User Name <email>
X-[Distro]-Bug: BugID
X-[Distro]-Bug-URL: URL for the bug (on the distribution's web site typically)
### cut here ###

If you did not write the code and the patch does not include authorship
information in a format git can use, please use the --author option of the
git commit command to make the authorship correct.

The Reported-by tag is required if the person who reported the bug is
different from the author and committer.

  The X-[Distro]-Bug/Bug-URL tags are required if this commit is related
  to a bug reported to us by a specific distribution   of linux or a
  *BSD. Also, [Distro] should be replaced with the name of the
  distribution, e.g. X-Gentoo-Bug.

[1] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html