0f5f4e8645
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
49 lines
1.7 KiB
Text
49 lines
1.7 KiB
Text
Cogl Coding Style
|
|
--------------------
|
|
|
|
This document is intended to be a short description of the preferred
|
|
coding style to be used for the Cogl source code.
|
|
|
|
Coding style is a matter of consistency, readability and maintainance;
|
|
coding style is also completely arbitrary and a matter of taste. This
|
|
document will use examples at the very least to provide authoritative
|
|
and consistent answers to common questions regarding the coding style,
|
|
and will also try to identify the allowed exceptions.
|
|
|
|
The Cogl coding style is currently defined relative to the Clutter
|
|
coding style, so please first read clutter/docs/CODING_STYLE.
|
|
|
|
Differences to the Clutter coding style:
|
|
|
|
+ Headers
|
|
|
|
Cogl headers are not exempt from the 80 characters limit as they are in
|
|
Clutter. Function prototypes should not be arranged into vertical
|
|
columns but should instead follow the "+ Functions" section of the
|
|
Clutter CODING_STYLE like:
|
|
|
|
void
|
|
my_function (CoglType type,
|
|
CoglType *a_pointer,
|
|
CoglType another_type);
|
|
|
|
+ Types
|
|
|
|
Avoid the use of redundant glib typedefs and wherever possible simply
|
|
use ANSI C types.
|
|
|
|
The following types should not be used:
|
|
gint, guint, gfloat, gdouble, glong, gulong, gchar and guchar
|
|
Instead use:
|
|
int, unsigned int, float, double, long, unsigned long, char, and
|
|
guint8/unsigned char
|
|
|
|
The glib types that we continue to use for portability are gboolean,
|
|
gint{8,16,32,64}, guint{8,16,32,64} and gsize. When ever you need a
|
|
byte size type for dealing with pixel data then guint8 should be used.
|
|
|
|
The general intention is that Cogl should look palatable to the widest
|
|
range of C programmers including those outside the Gnome community so
|
|
- especially for the public API - we want to minimize the number of
|
|
foreign looking typedefs.
|
|
|