Thread (6 messages) flat view 6 messages, 4 authors, 2016-06-15

Re: [PATCH v2] Add Documentation/CodingStyle

From: Robin Rosenberg <hidden>
Date: 2016-06-15 22:43:48

onsdag 07 november 2007 skrev Johannes Schindelin:
quoted hunk ↗ jump to hunk
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
new file mode 100644
index 0000000..38a3d9f
--- /dev/null
+++ b/Documentation/CodingStyle
@@ -0,0 +1,103 @@
+As a popular project, we also have some guidelines to keep to the
+code.  For git in general, two rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+   screw your system that does not conform."  We live in the
+   real world.
Can we use less offensive wording in documentation than we do on the list or IRC?
I'm not hurt by it but it doesn't look serious.
+ - Try to keep to 80 characters per line
less than?
+
+ - When declaring pointers, the star sides with the variable name, i.e.
+   "char *string", not "char* string" or "char * string".  This makes
+   it easier to understand "char *string, c;"
Rationale: The C syntax is defined the way it is. C programmers should
understand it.

I'd amend: Don't mix different types in declarations.

Write:
	char *string;
	char c;

Rather than:

	char *string,c;
+ - Do not use curly brackets unnecessarily.  I.e.
+
+	if (bla) {
+		x = 1;
+	}
+
+   is frowned upon.  A gray area is when the statement extends over a
+   few lines, and/or you have a lengthy comment atop of it.
Avoid unnecessary curly brackets but use them if unsure. (This is less 
strict than "do not". There are cases where we do want "unnecessary"
brackets.

-- robin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help