mirror of
https://github.com/ghostty-org/ghostty.git
synced 2025-07-14 15:56:13 +03:00
200 lines
4.1 KiB
Plaintext
Vendored
200 lines
4.1 KiB
Plaintext
Vendored
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,_,.,-,>
|
|
*/
|
|
|