Re: Style Guidelines

[Havoc Pennington <hp redhat com>]

Andy Tai <atai@ece.ucsd.edu> writes:
> (I believe it is) the GNU Coding Standards.
> 

Basically but with additions/modifications.

2-space indent with GNU brace style (braces on their own line). Emacs
in gnu mode will get indent and braces right.

Always put a space between parens and what's before them
(function/macros names).

Comments are either one line:
 /* foo */

or multiline:

/*  Foo 
 * blah blah
 */

Note position of closing "*/".

Function prototypes have to be lined up in the way you see in all the
GTK headers, we have an Emacs macro to do that.

The * of a pointer declaration is next to the variable name, e.g. 

  GtkWidget *widget;
  void foo (GtkWidget *widget);

Always use GLib types and data structures when appropriate.

Type names are in studly caps (GtkWidget), identifiers are in
lowercase/uscore notation (gtk_widget). All global symbols must be
prefixed with the library namespace (g_, gtk_, gdk_).

gchar* return values should never be const. gchar* function args must
be const.

Abbreviations should almost always be avoided.

Memory management should be friendly to language bindings, unless
efficiency strongly overrides this concern in which case you can
cheat, knowing that you will make language binding people do manual
workarounds. OK memory management: 

 - GObject, i.e. refcounted with at least one user_data slot

 - copy-by-value (can be copy-on-write internally as an optimization);
   copy must be cheap (GdkRectangle is an example)

 - static object, never freed (GdkVisual for example)

 - immutable refcounted object (refcounted with no mutators, in this
   case you can get away without a user data slot, because language 
   bindings can pretend it's a value object and get free "copy on
   write" since there is no write)


There are specific conventions for GObject headers, have a look at
some GObject headers to see those.


I'm sure Owen and Tim can add stuff, since they always fix my code. ;-)

The easiest thing to do is just read a good hunk of GTK code and get a
sense of it.

Havoc