pixman: Branch 'master'

[Søren Sandmann Pedersen]

 CODING_STYLE |  153 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 153 insertions(+)

New commits:
commit 2abd56e9e3d012fcb0b7c6d459ed4831464c0f2f
Author: Søren Sandmann Pedersen <sandmann at redhat.com>
Date:   Tue Jul 28 04:05:26 2009 -0400

    Add a CODING_STYLE document based on the one from cairo.

diff --git a/CODING_STYLE b/CODING_STYLE
new file mode 100644
index 0000000..0b851c0
--- /dev/null
+++ b/CODING_STYLE
@@ -0,0 +1,153 @@
+Pixman coding style.
+
+The pixman coding style is close to cairo's. There is one exception
+though: braces go on their own line, rather than on the line of the
+if/while/for:
+
+	if (condition)
+	{
+	    do_something();
+	    do_something_else();
+	}
+
+not
+
+	if (condition) {
+	    do_something();
+	    do_something_else();
+        }
+
+Specific guidelines:
+
+Indentation
+===========
+
+Each new level is indented four spaces:
+
+	if (condition)
+	    do_something();
+
+This may be achieved with space characters or with a combination of
+tab characters and space characters. Tab characters are interpreted as
+
+	Advance to the next column which is a multiple of 8.
+
+Names
+=====
+
+In all names, words are separated with underscores. Do not use
+CamelCase for any names.
+
+Macros have ALL_CAPITAL_NAMES
+
+Type names are in lower case and end with "_t". For example
+pixman_image_t.
+
+Labels, functions and variables have lower case names.
+
+Braces
+======
+
+Braces always go on their own line:
+
+	if (condition)
+	{
+	    do_this ();
+	    do_that ();
+	}
+	else
+	{
+	    do_the_other ();
+	}
+
+Rules for braces and substatements of if/while/for/do:
+
+* If a substatement spans multiple lines, then there must be braces
+  around it.
+
+* If the condition of an if/while/for spans multiple lines, then 
+  braces must be used for the substatements.
+
+* If one substatement of an if statement has braces, then the other
+  must too.
+
+* Otherwise, don't add braces.
+
+Whitespace
+==========
+
+Separate logically distinct chunks with a single newline. This
+obviously applies between functions, but also applies within a
+function or block or structure definition.
+
+Use a newline after a block of variable declarations.
+
+Use a single space before a left parenthesis, except where the
+standard will not allow it, (eg. when defining a parameterized macro).
+
+Don't eliminate newlines just because things would still fit on one
+line. This breaks the expected visual structure of the code making it
+much harder to read and understand:
+
+	if (condition) foo (); else bar ();	/* Yuck! */
+
+Do eliminate trailing whitespace (space or tab characters) on any
+line. Also, avoid putting initial or final blank lines into any file,
+and never use multiple blank lines instead of a single blank line.
+
+Do enable the default git pre-commit hook that detect trailing
+whitespace for you and help you to avoid corrupting cairo's tree with
+it. Do that as follows:
+
+	chmod a+x .git/hooks/pre-commit
+
+You might also find the git-stripspace utility helpful which acts as a
+filter to remove trailing whitespace as well as initial, final, and
+duplicate blank lines.
+
+Break up long lines (> ~80 characters) and use whitespace to align
+things nicely. For example the arguments in a long list to a function
+call should all be aligned with each other:
+
+	align_function_arguments (argument_the_first,
+				  argument_the_second,
+				  argument_the_third);
+
+Function prototypes and definitions can be formatted in two ways. If
+all parameters fit naturally on one line, then format them on one
+line:
+
+
+	int
+	some_function (int x, int y, int z)
+	{
+	}
+
+If the parameters do not fit on one line, then whitespace should be
+inserted between the parameter types and names so that the names are
+aligned:
+
+	void
+	align_parameter_names_in_prototypes (const char *char_star_arg,
+					     int	 int_arg,
+					     double	*double_star_arg,
+					     double	 double_arg);
+
+The return type and associated specifiers and qualifiers should always
+be on a line above the function, so that the function name is flush
+left.
+
+
+Mode lines
+==========
+
+So given the rules above, what is the best way to simplify one's life as
+a code monkey? Get your editor to do most of the tedious work of
+beautifying your code!
+
+As a reward for reading this far, here are some mode lines for the more
+popular editors:
+/*
+ * vim:sw=4:sts=4:ts=8:tw=78:fo=tcroq:cindent:cino=\:0,(0
+ * vim:isk=a-z,A-Z,48-57,_,.,-,>
+ */