<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="c-coding-style" xml:lang="de">

  <info>
    <link type="guide" xref="index#general-guidelines"/>

    <credit type="author copyright">
      <name>Federico Mena-Quintero</name>
      <email its:translate="no">federico@gnome.org</email>
      <years>2013</years>
    </credit>
    <credit type="author copyright">
      <name>Das GTK-Team</name>
    </credit>

    <include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>

    <desc>Unsere Richtlinien für C-Code in GNOME</desc>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Mario Blättermann</mal:name>
      <mal:email>mario.blaettermann@gmail.com</mal:email>
      <mal:years>2016, 2018</mal:years>
    </mal:credit>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Christian Kirbach</mal:name>
      <mal:email>christian.kirbach@gmail.com</mal:email>
      <mal:years>2016, 2020</mal:years>
    </mal:credit>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Stefan Melmuk</mal:name>
      <mal:email>stefan.melmuk@gmail.com</mal:email>
      <mal:years>2018</mal:years>
    </mal:credit>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Tim Sabsch</mal:name>
      <mal:email>tim@sabsch.com</mal:email>
      <mal:years>2021</mal:years>
    </mal:credit>
  </info>

  <title>C-Programmierstil</title>

  <p>Dieses Dokument präsentiert den bevorzugten Programmierstil für C-Programme in GNOME. Auch wenn das eigentlich Geschmackssache ist, bevorzugen wir in GNOME einen Programmierstil der Konsistenz, Lesbarkeit und Wartbarkeit begünstigt.</p>

  <p>Wir präsentieren Beispiele mit guten Programmierstil sowie mit schlechtem Programmierstil, der in GNOME nicht annehmbar ist. Bitte versuchen Sie Patches einzureichen, die mit dem GNOME-Programmierstil übereinstimmen; das weist darauf hin, dass Sie Ihre Hausaufgaben gemacht haben, um das Projektziel der Langzeit-Wartbarkeit zu respektieren. Patches im GNOME-Programmierstil sind auch einfacher zu rezensieren!</p>

  <note>
    <p>Dieses Dokument bezieht sich auf C-Programmcode. Informationen zu anderen Sprachen finden Sie auf der <link xref="index">Hauptseite</link> der GNOME-Programmierrichtlinien.</p>
  </note>

  <p>Diese Richtlinien sind stark von GTKs CODING-STYLE-Dokument, dem Programmierstil vom Linux-Kernel und den GNU Coding Standards inspiriert. Dabei sind das jeweils leichte Variationen voneinander, mit bestimmten Anpassungen an die besonderen Bedürfnisse und Gepflogenheiten des jeweiligen Projekts und die GNOMEs Version ist dabei keine Ausnahme.</p>

  <section id="most-important-rule">
    <title>Die allerwichtigste Regel</title>

    <p>Die allerwichtigste Regel für das Schreiben von Code ist: <em>Untersuchen Sie den umgebenden Code und versuchen Sie, dessen Stil zu imitieren</em>.</p>

    <p>Für einen Maintainer ist es schrecklich, einen Patch zu bekommen, der vom umgebenden Code stilistisch stark abweicht. Das ist respektlos wie jemand, der in ein blitzsauberes Haus mit schlammigen Schuhen hineintrampelt.</p>

    <p>Was auch immer dieses Dokument empfiehlt, Ihr Stil sollte sich stets am Stil des bereits vorhandenen Codes orientieren, auch wenn es nicht <em>Ihr bevorzugter Stil</em> ist.</p>
  </section>

  <section id="line-width">
    <title>Zeilenbreite</title>

    <p>Versuchen Sie, Ihre Zeilen zwischen 80 und 120 Zeichen breit zu halten. Diese Breite passt am besten in die meisten Bildschirme mit einer vernünftigen Schriftgröße. Längere Zeilen sind schwerer zu lesen, außerdem sollten Sie sich in diesem Fall überlegen, ob Sie Ihren Code nicht anders beziehungsweise besser strukturieren sollten. Bei zu vielen Einrückungsebenen sollte Ihr Code ohnehin überarbeitet werden.</p>
  </section>

  <section id="indentation">
    <title>Einrückungen</title>

    <p>Allgemein gibt es zwei bevorzugte Einrückungsstile für Code in GNOME.</p>

    <list type="ordered">
      <item>
	<p>Linux-Kernel-Stil. Tabulatoren für Einrückungen sind 8 Zeichen breit, mit einer K&amp;R-Klammernplatzierung:</p>

	<code style="valid">
for (i = 0; i &lt; num_elements; i++) {
	foo[i] = foo[i] + 42;

	if (foo[i] &lt; 35) {
		printf ("Foo!");
		foo[i]--;
	} else {
		printf ("Bar!");
		foo[i]++;
	}
}</code>
      </item>

      <item>
	<p>GNU-Stil. Jede neue Ebene wird um zwei Leerzeichen eingerückt, Klammern werden in eine eigene Zeile gesetzt und ebenfalls eingerückt.</p>

	<code style="valid">
for (i = 0; i &lt; num_elements; i++)
  {
    foo[i] = foo[i] + 42;

    if (foo[i] &lt; 35)
      {
        printf ("Foo!");
        foo[i]--;
      }
    else
      {
        printf ("Bar!");
        foo[i]++;
      }
  }</code>
      </item>
    </list>


    <p>Beide Stile haben ihre Vor- und Nachteile. Der wichtigste Punkt ist die <em>Konsistenz</em> zum umgebenden Code. Zum Beispiel ist die GTK-Bibliothek als Widget-Toolkit für GNOME im GNU-Stil geschrieben. Nautilus dagegen, der Dateimanager von GNOME, folgt dem Linux-Kernel-Stil. Beide Stile sind bestens lesbar und konsistent, wenn Sie sie sich daran gewöhnen.</p>

    <p>Ihr erstes Gefühl bei der Arbeit an Programmcode, der nicht Ihrem bevorzugten Einrückungsstil folgt, könnte, sagen wir, qualvoll sein. Widerstehen Sie dem Drang, alles neu einrücken zu wollen oder für Ihren Patch einen inkonsistenten Stil zu verwenden. Erinnern Sie sich an die oberste Regel: <em>Konsistenz</em> und Respekt vor den Eigenheiten des fremden Codes und Ihre Patches haben eine ungleich größere Chance, ohne langatmige Diskussionen über den <em>richtigen</em> Einrückungsstil, angenommen zu werden.</p>
  </section>

  <section id="tab-characters">
    <title>Tabulatorzeichen</title>

    <p><em>Ändern Sie niemals die Tabulatorbreite in Ihrem Editor</em>. Bleiben Sie bei 8 Zeichen. Durch Änderungen der Tabulatorbreite wird Code, den Sie nicht selbst geschrieben haben, immer falsch ausgerichtet.</p>

    <p>Setzen Sie stattdessen die passende Einrückungsgröße für den Code, den Sie ändern. Wenn Sie nicht den Linux-Kernel-Stil verwenden, können Sie ihren Editor auch einstellen, alle Tabulatoren durch 8 Leerzeichen zu ersetzen, um Unklarheiten, wie viel Platz verwendet werden soll, zu vermeiden.</p>
  </section>

  <section id="braces">
    <title>Klammern</title>

    <p>Geschweifte Klammern sollten nicht für Blöcke mit einzelnen Anweisungen verwendet werden:</p>

<code style="valid">
/* valid */
if (condition)
	single_statement ();
else
	another_single_statement (arg1);</code>

	<p>Für die Regel »kein Block für einzelne Anweisungen« gibt es vier Ausnahmen:</p>

	<list type="ordered">
          <item>
            <p>Beim GNU-Stil sobald eine der beiden Seiten einer <code>if-else</code>-Anweisung eine geschwungene Klammer hat, sollte die andere Seite auch  eine bekommen, um die Einrückung anzupassen:</p>

<code style="valid">
/* valid GNU style */
if (condition)
  {
    foo ();
    bar ();
  }
else
  {
    baz ();
  }</code>

<code style="invalid">
/* invalid */
if (condition)
  {
    foo ();
    bar ();
  }
else
  baz ();</code>
          </item>

	  <item>
	    <p>Wenn sich die einzelne Anweisung über mehrere Zeilen erstreckt (zum Beispiel bei Funktionen mit vielen Argumenten) und wenn darauf <code>else</code> oder <code>else if</code> folgt:</p>

<code style="valid">
/* valid Linux kernel style */
if (condition) {
	a_single_statement_with_many_arguments (some_lengthy_argument,
						another_lengthy_argument,
						and_another_one,
						plus_one);
} else
	another_single_statement (arg1, arg2);

/* valid GNU style */
if (condition)
  {
    a_single_statement_with_many_arguments (some_lengthy_argument,
                                            another_lengthy_argument,
                                            and_another_one,
                                            plus_one);
  }
else
  {
    another_single_statement (arg1, arg2);
  }</code>
          </item>

          <item>
            <p>Wenn die Bedingung aus mehreren Zeilen besteht:</p>

<code style="valid">
/* valid Linux kernel style */
if (condition1 ||
    (condition2 &amp;&amp; condition3) ||
    condition4 ||
    (condition5 &amp;&amp; (condition6 || condition7))) {
	a_single_statement ();
}

/* valid GNU style */
if (condition1 ||
    (condition2 &amp;&amp; condition3) ||
    condition4 ||
    (condition5 &amp;&amp; (condition6 || condition7)))
  {
    a_single_statement ();
  }</code>

            <p>Bedenken Sie, dass solche langen Bedingungen oft schwer verständlich sind. Eine gute Angewohnheit ist es, die Bedingung in eine boolesche Variable mit einem passenden Namen zu speichern. Eine weitere Möglichkeit wäre die Auslagerung der langen Bedingung in eine Funktion.</p>
          </item>

          <item>
            <p>Verschachtelte <code>if</code>s, wobei der Block im äußersten <code>if</code> platziert werden sollte:</p>

<code style="valid">
/* valid Linux kernel style */
if (condition) {
	if (another_condition)
		single_statement ();
	else
		another_single_statement ();
}

/* valid GNU style */
if (condition)
  {
    if (another_condition)
      single_statement ();
    else
      another_single_statement ();
  }</code>

<code style="invalid">
/* invalid */
if (condition)
	if (another_condition)
		single_statement ();
	else if (yet_another_condition)
		another_single_statement ();</code>
          </item>
        </list>

        <p>Generell sollten neue Blöcke in eine neue Einrückungsebene gesetzt werden, wie hier:</p>

        <code style="valid">
int retval = 0;

statement_1 ();
statement_2 ();

{
	int var1 = 42;
	gboolean res = FALSE;

	res = statement_3 (var1);

	retval = res ? -1 : 1;
}</code>

        <p>Während geschweifte Klammern für Funktionsdefinitionen in eine neue Zeile gehören, sollten sie nicht weiter eingerückt werden:</p>

        <code style="valid">
/* valid Linux kernel style*/
static void
my_function (int argument)
{
	do_my_things ();
}

/* valid GNU style*/
static void
my_function (int argument)
{
  do_my_things ();
}</code>

<code style="invalid">
/* invalid */
static void
my_function (int argument) {
	do_my_things ();
}

/* invalid */
static void
my_function (int argument)
  {
    do_my_things ();
  }</code>
  </section>

  <section id="conditions">
    <title>Bedingungen</title>

    <p>Überprüfen Sie boolesche Variablen nicht auf Gleichwertigkeit. Unter Verwendung von impliziten Vergleichen kann der resultierende Code mehr wie umgangssprachliches Englisch gelesen werden. Eine weitere Begründung ist, dass ein Wert, der als '<em>true</em>' evaluiert wird, nicht notwendigerweise mit dem <code>TRUE</code>-Makro gleichwertig ist. Zum Beispiel:</p>

    <code style="invalid">
/* invalid */
if (found == TRUE)
	do_foo ();

/* invalid */
if (found == FALSE)
	do_bar ();</code>

    <code style="valid">
/* valid */
if (found)
	do_foo ();

/* valid */
if (!found)
	do_bar ();</code>

    <p>Die Programmiersprache C verwendet den Wert 0 für zahlreiche Zwecke: als numerischen Wert, als Ende einer Zeichenkette, als Null-Zeiger oder für den booleschen Wert <code>FALSE</code>. Um hier etwas mehr Klarheit zu schaffen, sollte dieser Zweck in Ihrem Code entsprechend hervorgehoben werden. So kann bei Vergleichen der Variablentyp erkannt werden. Für boolesche Variablen ist ein impliziter Vergleich angemessen, da es bereits ein logischer Ausdruck ist. Andere Variablentypen sind nicht direkt logische Ausdrücke, so dass ein expliziter Vergleich besser erscheint:</p>

    <code style="valid">
/* valid */
if (some_pointer == NULL)
	do_blah ();

/* valid */
if (number == 0)
	do_foo ();

/* valid */
if (str != NULL &amp;&amp; *str != '\0')
	do_bar ();</code>

    <code style="invalid">
/* invalid */
if (!some_pointer)
	do_blah ();

/* invalid */
if (!number)
	do_foo ();

/* invalid */
if (str &amp;&amp; *str)
	do_bar ();</code>
  </section>

  <section id="functions">
    <title>Funktionen</title>

    <p>Funktionen sollten so deklariert werden, dass der Rückgabetyp in einer separaten Zeile vom Funktionsnamen abgesetzt wird:</p>

    <code style="valid">
void
my_function (void)
{
  …
}</code>

    <p>Die Liste der Argumente muss auf mehrere Zeilen aufgeteilt werden, so dass jedes Argument in einer Zeile ist, wobei die jeweiligen Bezeichner unter Berücksichtigung von Zeigern rechtsbündig ausgerichtet werden:</p>

    <code style="valid">
void
my_function (some_type_t      type,
             another_type_t  *a_pointer,
             double_ptr_t   **double_pointer,
             final_type_t     another_type)
{
  …
}</code>

    <p>Wenn Sie Emacs verwenden, können Sie mit <code>M-x align</code> diese Art der Ausrichtung automatisch erledigen lassen. Einfach den ganzen Funktionsprototypen markieren und den Befehl ausführen.</p>

    <p>Diese Ausrichtung gilt auch bei einem Funktionsaufruf, der die maximale Zeilenlänge nicht überschreiten würde:</p>

    <code style="valid">
align_function_arguments (first_argument,
                          second_argument,
                          third_argument);</code>
  </section>

  <section id="whitespace">
    <title>Leerzeichen</title>

    <p>Setzen Sie stets vor einer öffnenden Klammer ein Leerzeichen, aber niemals dahinter:</p>

    <code style="valid">
/* valid */
if (condition)
	do_my_things ();

/* valid */
switch (condition) {
}</code>

<code style="invalid">
/* invalid */
if(condition)
	do_my_things();

/* invalid */
if ( condition )
	do_my_things ( );</code>

    <p>Bei der Deklaration einer Struktur verwenden Sie einen Zeilenumbruch, um logische Abschnitte der Struktur zu trennen:</p>

    <code style="valid">
struct _GtkWrapBoxPrivate
{
	GtkOrientation        orientation;
	GtkWrapAllocationMode mode;

	GtkWrapBoxSpreading   horizontal_spreading;
	GtkWrapBoxSpreading   vertical_spreading;

	guint16               vertical_spacing;
	guint16               horizontal_spacing;

	guint16               minimum_line_children;
	guint16               natural_line_children;

	GList                *children;
};</code>

    <p>Entfernen Sie keine Leerzeichen und Zeilenumbrücke, nur weil etwas auch in eine einzelne Zeile passen würde:</p>

    <code style="invalid">
/* invalid */
if (condition) foo (); else bar ();</code>

    <p>Entfernen Sie stets angehängte Leerzeichen in jeder Zeile, vorzugsweise mittels separatem Patch oder Commit. Verwenden Sie keine Leerzeilen am Anfang oder am Ende einer Datei.</p>

    <p>Hier ist eine kleine Emacs-Funktion, mit der Sie Zeilen mit angehängten Leerzeichen bereinigen können:</p>

    <code>
(defun clean-line-ends ()
  (interactive)
  (if (not buffer-read-only)
      (save-excursion
	(goto-char (point-min))
	(let ((count 0))
	  (while (re-search-forward "[ 	]+$" nil t)
	    (setq count (+ count 1))
	    (replace-match "" t t))
	  (message "Cleaned %d lines" count)))))</code>
  </section>

  <section id="switch">
    <title>Die <code>switch</code>-Anweisung</title>

    <p>Ein <code>switch</code> sollte einen Block in einer neuen Einrückungsebene öffnen, und jedes <code>case</code> sollte in der gleichen Einrückungsebene beginnen wie die geschweiften Klammern, mit dem <code>case</code>-Block in einer neuen Einrückungsebene:</p>

    <code style="valid">
/* valid Linux kernel style */
switch (condition) {
case FOO:
	do_foo ();
	break;

case BAR:
	do_bar ();
	break;
}

/* valid GNU style */
switch (condition)
  {
  case FOO:
    do_foo ();
    break;

  case BAR:
    do_bar ();
    break;
  }</code>

<code style="invalid">
/* invalid */
switch (condition) {
  case FOO: do_foo (); break;
  case BAR: do_bar (); break;
}

/* invalid */
switch (condition)
  {
  case FOO: do_foo ();
    break;
  case BAR: do_bar ();
    break;
  }

/* invalid */
switch (condition)
  {
    case FOO:
    do_foo ();
    break;
    case BAR:
    do_bar ();
    break;
  }</code>

    <p>Es ist wünschenswert, wenn auch nicht zwingend notwendig, die unterschiedlichen Fälle durch Zeilenumbrüche voneinander zu trennen:</p>

    <code style="valid">
switch (condition) {
case FOO:
	do_foo ();
	break;

case BAR:
	do_bar ();
	break;

default:
	do_default ();
}</code>

    <p>Die <code>break</code>-Anweisung für den <code>default</code>-Fall ist nicht verpflichtend vorgeschrieben.</p>

    <p>Wenn mit <code>switch</code> über einen Aufzählungstyp geschalten wird, muss es für jeden zulässigen Wert der Aufzählung eine <code>case</code>-Anweisung geben. Für Werte, die nicht extra behandeln werden sollen, kann der jeweilige <code>case</code> zu <code>default</code> geschalten werden:</p>

    <code style="valid">
switch (enumerated_condition) {
case HANDLED_1:
	do_foo ();
	break;

case HANDLED_2:
	do_bar ();
	break;

case IGNORED_1:
case IGNORED_2:
default:
	do_default ();
}</code>

    <p>Wenn die meisten Aufzählungswerte nicht behandelt werden sollen, ist es ratsam eine <code>if</code>-Anweisung statt einem <code>switch</code> zu verwenden.</p>

    <p>Wenn ein <code>case</code>-Block neue Variablen deklarieren muss, gelten dieselben Regeln wie bei inneren Blöcken (siehe oben); die <code>break</code>-Anweisung sollte dabei außerhalb des inneren Blocks platziert werden:</p>

    <code style="valid">
/* valid GNU style */
switch (condition)
  {
  case FOO:
    {
      int foo;

      foo = do_foo ();
    }
    break;

  …
  }</code>
  </section>

  <section id="header-files">
    <title>Header-Dateien</title>

    <p>Die einzige größere Regel für Header ist, dass die Funktionsdefinition vertikal in drei Spalten ausgerichtet sein sollte:</p>

    <code style="valid">
return_type          function_name           (type   argument,
                                              type   argument,
                                              type   argument);</code>

    <p>Die maximale Breite jeder Spalte wird durch das längste Element in der Spalte bestimmt:</p>

    <code style="valid">
void         gtk_type_set_property (GtkType      *type,
                                    const gchar  *value,
                                    GError      **error);
const gchar *gtk_type_get_property (GtkType      *type);</code>

    <p>Es ist auch möglich, die Spalten am nächsten Tabulator auszurichten:</p>

    <code style="valid">
void          gtk_type_set_prop           (GtkType *type,
                                           gfloat   value);
gfloat        gtk_type_get_prop           (GtkType *type);
gint          gtk_type_update_foobar      (GtkType *type);</code>

    <p>Wie schon erwähnt, erledigt Emacs dies mit <code>M-x align</code> automatisch.</p>

    <p>
      If you are creating a public library, try to export a single
      public header file that in turn includes all the smaller header
      files into it.  This is so that public headers are never
      included directly; rather a single include is used in
      applications.  For example, GTK+ uses the following in its
      header files that should not be included directly by
      applications:
    </p>

    <code style="valid">
#if !defined (__GTK_H_INSIDE__) &amp;&amp; !defined (GTK_COMPILATION)
#error "Only &lt;gtk/gtk.h&gt; can be included directly."
#endif</code>

    <p>
      For libraries, all headers should have inclusion guards (for
      internal usage) and C++ guards.  These provide the <code>extern
      "C"</code> magic that C++ requires to include plain C headers:
    </p>

    <code style="valid">
#ifndef MYLIB_FOO_H_
#define MYLIB_FOO_H_

#include &lt;gtk/gtk.h&gt;

G_BEGIN_DECLS

…

G_END_DECLS

#endif /* MYLIB_FOO_H_ */</code>
  </section>

  <section id="gobject">
    <title>GObject-Klassen</title>

    <p>GObject-Klassendefinitionen und -implementierungen erfordern zusätzliche Programmierstil-Hinweise und sollten immer im <link xref="namespacing#gobject">richtigen Namensraum</link> sein.</p>

    <p>Typedef-Deklarationen sollten am Anfang der Datei platziert werden:</p>

    <code style="valid">
typedef struct _GtkBoxedStruct       GtkBoxedStruct;
typedef struct _GtkMoreBoxedStruct   GtkMoreBoxedStruct;</code>

    <p>Hierzu gehören auch Aufzählungstypen:</p>

    <code style="valid">
typedef enum
{
  GTK_SIZE_REQUEST_WIDTH_FOR_HEIGHT,
  GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH
} GtkSizeRequestMode;</code>

    <p>Und Callback-Typen:</p>

    <code style="valid">
typedef void (* GtkCallback) (GtkWidget *widget,
                              gpointer   user_data);</code>

    <p>Instanzstrukturen sollten mit <code>G_DECLARE_FINAL_TYPE</code> oder <code>G_DECLARE_DERIVABLE_TYPE</code> deklariert werden:</p>

    <code style="valid">
#define GTK_TYPE_FOO (gtk_foo_get_type ())
G_DECLARE_FINAL_TYPE (GtkFoo, gtk_foo, GTK, FOO, GtkWidget)</code>

    <p>
      For final types, private data can be stored in the object struct, which
      should be defined in the C file:
    </p>

    <code style="valid">
struct _GtkFoo
{
  GObject   parent_instance;

  guint     private_data;
  gpointer  more_private_data;
};</code>

    <p>
      For derivable types, private data must be stored in a private struct in
      the C file, configured using <code>G_DEFINE_TYPE_WITH_PRIVATE()</code>
      and accessed using a <code>_get_instance_private()</code> function:
    </p>

    <code style="valid">
#define GTK_TYPE_FOO gtk_foo_get_type ()
G_DECLARE_DERIVABLE_TYPE (GtkFoo, gtk_foo, GTK, FOO, GtkWidget)

struct _GtkFooClass
{
  GtkWidgetClass parent_class;

  void (* handle_frob)  (GtkFrobber *frobber,
                         guint       n_frobs);

  gpointer padding[12];
};</code>

    <p>
      Always use the <code>G_DEFINE_TYPE()</code>,
      <code>G_DEFINE_TYPE_WITH_PRIVATE()</code>, and
      <code>G_DEFINE_TYPE_WITH_CODE()</code> macros, or their abstract variants
      <code>G_DEFINE_ABSTRACT_TYPE()</code>,
      <code>G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE()</code>,
      and <code>G_DEFINE_ABSTRACT_TYPE_WITH_CODE()</code>; also, use the similar
      macros for defining interfaces and boxed types.
    </p>

    <p>
      Interface types should always have the dummy typedef for cast
      purposes:
    </p>

    <code style="valid">
typedef struct _GtkFooable          GtkFooable;</code>

    <p>
      The interface structure should have ‘Interface’ postfixed to the
      dummy typedef:
    </p>

    <code style="valid">
typedef struct _GtkFooableInterface     GtkFooableInterface;</code>

    <p>Für Schnittstellen sind die folgenden Makros zu verwenden:</p>

    <table>
      <thead>
	<tr>
	  <td><p>Makro</p></td>
	  <td><p>Expandiert zu</p></td>
	</tr>
      </thead>
      <tbody>
	<tr>
	  <td><p><code>GTK_TYPE_<var>iface_name</var></code></p></td>
	  <td><p><code><var>iface_name</var>_get_type</code></p></td>
	</tr>
	<tr>
	  <td><p><code>GTK_<var>iface_name</var></code></p></td>
	  <td><p><code>G_TYPE_CHECK_INSTANCE_CAST</code></p></td>
	</tr>
	<tr>
	  <td><p><code>GTK_IS_<var>iface_name</var></code></p></td>
          <td><p><code>G_TYPE_CHECK_INSTANCE_TYPE</code></p></td>
	</tr>
	<tr>
	  <td><p><code>GTK_<var>iface_name</var>_GET_IFACE</code></p></td>
          <td><p><code>G_TYPE_INSTANCE_GET_INTERFACE</code></p></td>
	</tr>
      </tbody>
    </table>

  </section>

  <section id="memory-allocation">
    <title>Speicherreservierung</title>

    <p>Verwenden Sie <code>g_new()</code> zum Reservieren von dynamischen Speicher.</p>

    <p>
      Public structure types should always be returned after being
      zero-ed, either explicitly for each member, or by using
      <code>g_new0()</code>.
    </p>

    <p>In <link xref="memory-management"/> finden Sie weitere Details.</p>
  </section>

  <section id="macros">
    <title>Makros</title>

    <p>Versuchen Sie, auf private Makros zu verzichten, wenn diese nicht zwingend notwendig sind. Denken Sie an das <code>#undef</code> am Ende eines Blocks oder einer Serie an Funktionen, die die Makros benötigen.</p>

    <p>Im Allgemeinen sind Inlinefunktionen gegenüber privaten Makros zu bevorzugen.</p>

    <p>Auf öffentliche Makros sollten Sie außer zum Evaluieren einer Konstante verzichten.</p>
  </section>

  <section id="public-api">
    <title>Öffentliche API</title>

    <p>Vermeiden Sie das Exportieren von Variablen als öffentliche API, da dies auf einigen Plattformen umständlich ist. Fügen Sie stattdessen Getter und Setter hinzu. Vermeiden Sie generell globale Variablen.</p>
  </section>

  <section id="private-api">
    <title>Private API</title>

    <p>Nicht exportierten Funktionen, die in mehr als einer Quelldatei benötigt werden, sollte ein Unterstrich (_) vorangestellt und diese in der privaten Header-Datei deklariert werden. Zum Beispiel <code>_mylib_internal_foo()</code>.</p>

    <p>Funktionen mit vorangestelltem Unterstrich werden niemals exportiert.</p>

    <p>Nicht-exportierte Funktionen, die nur in einer Quelldatei benötigt werden, sollten als statisch deklariert werden.</p>
  </section>
</page>