IABSD.fr/xenocara/lib/pixman/CODING_STYLE

Branch : - branch - master - tag -

• Show log

  Commit

• Author : matthieu
  Date : 2025-08-12 16:39:28
  Hash : 81405b23
  Message : Update to pixman 0.46.4. tested in a bulk ports build and ok jca@ runs of the tests on differents by gkoeler@, jca@ and others.

• lib/pixman/CODING_STYLE

• Pixman coding style.
  ====================
  
  The pixman coding style is close to cairo's with one exception: 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();
          }
  
  
  
  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.
  
  
  Comments
  ========
  
  For comments either like this:
  
          /* One line comment */
  
  or like this:
  
  	/* This is a multi-line comment
  	 *
           * It extends over multiple lines
  	 */
  
  Generally comments should say things that aren't clear from the code
  itself. If too many comments say obvious things, then people will just
  stop reading all comments, including the good ones.
  
  
  Whitespace
  ==========
  
  * Put a single space after commas
  
  * Put spaces around arithmetic operators such a +, -, *, /:
  
          y * stride + x
  
          x / unit_x
  
  * Do not put spaces after the address-of operator, the * when used as
    a pointer derefernce or the ! and ~ operators:
  
       &foo;
  
       ~0x00000000
  
       !condition
  
       *result = 100
  
  * Break up long lines (> ~80 characters) and use whitespace to align
    things nicely. This is one way:
  
    	 some_very_long_function name (
  	 	implementation, op, src, mask, dest, 
  		src_x, src_y, mask_x, mask_y, dest_x, dest_y,
  		width, height);
  
    This is another:
  
          some_very_long_function_name (implementation, op,
                                        src, mask, dest,
  				      src_x, src_y,
  				      mask_x, mask_y,
  				      dest_x, dest_y,
  				      width, height);
  
  * 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! */
  
  
  Function Definitions
  ====================
  
  Function definitions should take the following form:
  
  	void
  	my_function (int argument)
  	{
  	    do_my_things ();
  	}
  
  If all the parameters to a function fit naturally on one line, format
  them that way. Otherwise, put one argument on each line, adding
  whitespace so that the parameter names are aligned with each other.
  
  I.e., do either this:
  
          void
          short_arguments (const char *str, int x, int y, int z)
          {
          }
  
  or this:
  
  	void
  	long_arguments (const char *char_star_arg,
  			int	    int_arg,
  			double	   *double_star_arg,
  			double	    double_arg)
  	{
  	}
  
  
  Mode lines
  ==========
  
  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,_,.,-,>
   */