<?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="cs">

  <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>Tým GTK+</name>
    </credit>

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

    <desc>Naše pokyny pro psaní kódu v jazyce C pro GNOME</desc>
  </info>

  <title>Styl psaní kódu v C</title>

  <p>Dokument ukazuje preferovaný styl psaní kódu pro programy v jazyce C v GNOME. Ačkoliv je styl psaní kódu hodně záležitostí osobního vkusu, v GNOME dáváme přednost stylu, který poskytne jednotnost, čitelnost a půjde dobře spravovat.</p>

  <p>Ukážeme si příklady správného stylu kódu i příklady špatného stylu, který je v GNOME nepřijatelný. Snažte se prosím své příspěvky zasílat ve stylu, který GNOME vyhovuje. Dáte tím najevo, že jste svoji práci odvedli s úctou k cílům projektu, k nimž patří udržitelnost kódu. Takovéto příspěvky se také mnohem lépe kontrolují.</p>

  <note>
    <p>Tento dokument se týká kódu v jazyce C. Na další jazyky se podívejte na <link xref="index">hlavní stránku</link> pokynů k programování v GNOME.</p>
  </note>

  <p>Tato příručka je významně inspirována dokumenty GTK’s CODING-STYLE, Linux Kernel’s CodingStyle a GNU Coding Standards. Ty se od sebe navzájem lehce odlišují konkrétními úpravami pro konkrétní potřeby projektu a jeho kulturu, a verze pro GNOME v tom není výjimkou.</p>

  <section id="most-important-rule">
    <title>Jednoduché nejdůležitější pravidlo</title>

    <p>Prosté a přitom nejdůležitější pravidlo při psaní kódu je: <em>podívejte se na kód okolo a snažte se jej napodobit</em>.</p>

    <p>Správce bývá zděšen, když obdrží záplatu, která se vyloženě liší stylem kódování od okolního kódu. Je to bezohledné, jako když někdo vstoupí do uklizeného domu se zablácenými botami.</p>

    <p>Takže to, co tento dokument doporučuje, je, abyste při psaní záplaty pro již existující kód, zachovali jeho stávající styl jednotný, i přesto že to není zrovna váš oblíbený.</p>
  </section>

  <section id="line-width">
    <title>Šířka řádku</title>

    <p>Snažte se délku řádků v kódu udržet v rozmezí 80 až 120 znaků. Takové množství textu se vleze na většinu monitorů při použití slušné velikosti písma. Delší řádky může být obtížné číst a znamenají, že byste se měli zamyslet nad restrukturalizací svého kódu. Pokud mát příliš mnoho úrovní odsazení, rovněž to znamená, že byste měli svůj kód opravit.</p>
  </section>

  <section id="indentation">
    <title>Odsazení</title>

    <p>Obecně je v kódu GNOME dávána přednost dvěma stylům odsazení.</p>

    <list type="ordered">
      <item>
	<p>Styl linuxového jádra. K odsazení se používají tabulátory o šířce 8 znaků a složené závorky se umisťují neodsazené (tento styl bývá označován zkratkou K&amp;R podle autorů Kernighan a Ritchie kultovní knihy The C Programming Language):</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>Styl GNU. Každá nová úroveň je odsazena 2 mezerami, složené závorky jsou samostatně na novém řádku a rovněž jsou odsazené.</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>Oba styly mají své pro a proti. Nejdůležitější věcí ale je, aby okolní kód <em>byl jednotný</em>. Například knihovna GTK+, což je vývojářská sada pro widgety GNOME, je napsaná ve stylu GNU. Nautilus, což je správce souborů v GNOME, je napsán ve stylu linuxového jádra. Čitelné a jednotné jsou oba styly, ať použijete kterýkoliv z nich.</p>

    <p>Když musíte studovat kus cizího kódu, který nemá vámi oblíbený styl odsazování, nebo na něm dokonce pracovat, dělá se vám z toho zle. Měli byste ale překonat své touhy všchno odsazení předělat nebo použít ve své záplatě jiný styl odsazování. Pamatujte na první pravidlo: <em>dodržujte jednotnost</em> a respektujte zvyky daného kódu, a vaše záplata bude mít daleko větší šanci na přijetí, aniž byste museli vést dohady o tom, který styl odsazování je lepší.</p>
  </section>

  <section id="tab-characters">
    <title>Znaky tabulátor</title>

    <p><em>Nikdy neměňte šířku tabulátoru ve svém editoru</em>. Ponechte ji na 8 mezerách. Pokud byste ji změnili, budete mít kód, který jste nepsali vy, věčně rozházený.</p>

    <p>Místo toho si nastavte <em>šířku odsazení</em> odpovídající kódu, který upravujete. Když píšete v jiném stylu než linuxového jádra, můžete chtít říci svému editoru, aby automaticky převáděl všechny tabulátory na 8 mezer, takže nevzniknou žádné nejednoznačnosti týkající se množství mezer.</p>
  </section>

  <section id="braces">
    <title>Závorky</title>

    <p>Složené závorky by se neměly používat pro blok s jediným příkazem:</p>

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

	<p>Z tohoto pravidla existují čtyři výjimky:</p>

	<list type="ordered">
          <item>
            <p>Ve stylu GNU, když má jedna část výrazu if-else závorky, měly by je mít obě, aby měly i stejné odsazení:</p>

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

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

	  <item>
	    <p>Samostatný výraz roztažený přes více řádků, např. funkce s hodně argumenty, a následovaný <code>else</code> nebo <code>else if</code>:</p>

<code style="valid">
/* platný styl linuxového jádra */
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);

/* platný styl GNU */
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>Když je podmínka rozdělená na více řádků:</p>

<code style="valid">
/* platný styl linuxového jádra */
if (condition1 ||
    (condition2 &amp;&amp; condition3) ||
    condition4 ||
    (condition5 &amp;&amp; (condition6 || condition7))) {
	a_single_statement ();
}

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

            <p>Uvědomte si ale, že takovéto dlouhé podmínky jsou náročné na porozumění. Proto je dobrým zvykem nastavit jednotlivé části podmínky do pravdivostních proměnných s popisnými názvy. Jinou možností je přesunout dlouhou podmínku do funkce.</p>
          </item>

          <item>
            <p>Vnořené <code>if</code> v případě, že má být blok umístěn v nadřazeném <code>if</code>:</p>

<code style="valid">
/* platný styl linuxového jádra */
if (condition) {
	if (another_condition)
		single_statement ();
	else
		another_single_statement ();
}

/* platný styl GNU */
if (condition)
  {
    if (another_condition)
      single_statement ();
    else
      another_single_statement ();
  }</code>

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

        <p>Obecně by nový blok měl být umístěn v nové úrovni odsazení, nějak takto:</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>I když mají být složené závorky pro definici funkce na novém řádku, neměly by být odsazené:</p>

        <code style="valid">
/* platný styl linuxového jádra*/
static void
my_function (int argument)
{
	do_my_things ();
}

/* platný styl GNU */
static void
my_function (int argument)
{
  do_my_things ();
}</code>

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

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

  <section id="conditions">
    <title>Podmínky</title>

    <p>U pravdivostních hodnot neprovádějte kontrolu na rovnost. Když ponecháte výchozí porovnání, bude výsledný kód čitelnější jakoby přirozená angličtina. Dalším logickým důvodem je, že skutečná hodnota „pravda“ nemusí nutně být totéž, co použití makra <code>TRUE</code>. Například:</p>

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

/* špatně */
if (found == FALSE)
	do_bar ();</code>

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

/* dobře */
if (!found)
	do_bar ();</code>

    <p>Jazyk C používá hodnotu 0 k mnoha účelům. Jako číselnou hodnotu, zakončení řetězce, prázdný ukazatel a pravdivostní hodnotu <code>FALSE</code>. Aby byl kód lépe čitelný, měli byste jej psát tak, aby byl konkrétní význam 0 zdůrazněn. Proto je při porovnávání dobré vědět, o jaký typ proměnné se jedná. U pravdivostních proměnných je výchozí porovnání v pořádku, protože se jedná o logický výraz. U ostatních typů samotných o logický výraz nejde, takže výslovné porovnání je lepší:</p>

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

/* dobře */
if (number == 0)
	do_foo ();

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

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

/* špatně */
if (!number)
	do_foo ();

/* špatně */
if (str &amp;&amp; *str)
	do_bar ();</code>
  </section>

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

    <p>Funkce by měly být deklarovány s návratovou hodnotou umístěnou na zvláštní řádek před názvem funkce:</p>

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

    <p>Seznam argumentů musí být rozdělen na jednotlivé řádky pro každý z argumentů a názvy argumentů jsou správně zarovnané, přičemž se berou do úvahy ukazatele:</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>Pokud používáte Emacs, můžete vyžít <code>M-x align</code> k automatickému zarovnání tohoto typu. Stačí vložit okolo prototypu funkce bod a značku a vyvolat tento příkaz.</p>

    <p>Zarovnání se dodržuje i při vyvolání funkce, která neporušuje omezení délky řádku:</p>

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

  <section id="whitespace">
    <title>Bílé znaky</title>

    <p>Vždy dejte mezeru před otevírací závorku, ale nikdy ne za ni:</p>

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

/* dobře */
switch (condition) {
}</code>

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

/* špatně */
if ( condition )
	do_my_things ( );</code>

    <p>Při deklaraci struktury oddělte její logické části pomocí prázdného řádku:</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>Neodstraňujte bílé znaky a zalomení jen proto, že by se něco vlezlo na jeden řádek:</p>

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

    <p>Odstraňte bílé znaky na koncích řádků, hlavně u samostatných záplat nebo zařazení. Nikdy nepoužívejte prázdné řádky na začátku nebo na konci souboru.</p>

    <p>Zde je drobná funkce pro Emacs, kterou můžete použít k vyčištění bílých znaků na koncích řádků:</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>Výraz <code>switch</code></title>

    <p>Příkaz <code>switch</code> by měl otevírat blok na nové úrovni odsazení a každý <code>case</code> by měl začínat na stejné úrovni, jako složené závorky, s příslušným blokem na nové úrovni odsazení:</p>

    <code style="valid">
/* platný styl linuxového jádra */
switch (condition) {
case FOO:
	do_foo ();
	break;

case BAR:
	do_bar ();
	break;
}

/* platný styl GNU */
switch (condition)
  {
  case FOO:
    do_foo ();
    break;

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

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

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

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

    <p>Preferované, ale ne povinné, je oddělení různých případů prázdným řádkem:</p>

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

case BAR:
	do_bar ();
	break;

default:
	do_default ();
}</code>

    <p>Výraz <code>break</code> pro případ <code>default</code> není povinný.</p>

    <p>Pokud přepínáte podle výčtového typu, musí být výraz <code>case</code> uveden pro všechny hodnoty daného výčtu. Hodnoty, které není potřeba obsloužit, uveďte dohromady s případem <code>default</code>:</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>Pokud není potřeba obsloužit většinu z hodnot výčtu, měli byste pouvažovat spíš o výrazu <code>if</code> namísto <code>switch</code>.</p>

    <p>Když blok <code>case</code> potřebuje deklarovat nové proměnné, použije se stejné pravidlo jako pro vnitřní blok (viz výše). Příkaz <code>break</code> by měl být umístěn mimo vnitřní blok:</p>

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

      foo = do_foo ();
    }
    break;

  …
  }</code>
  </section>

  <section id="header-files">
    <title>Hlavičkové soubory</title>

    <p>Jediné hlavní pravidlo pro hlavičkové soubory je, že definici funkcí by měly být svisle zarovnané do tří sloupců:</p>

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

    <p>Maximální šířka jednotlivých sloupců je určena nejdelším prvkem ve sloupci:</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>Sloupce je možné zarovnávat také na nejbližší tabulátor:</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>Jak již bylo uvedeno dříve, můžete v editoru Emacs použít <code>M-x align</code>, aby se to provedlo automaticky.</p>

    <p>Když vytváříte veřejnou knihovnu, zkuste exportovat jediný veřejný hlavičkový soubor, ve kterém budou pomocí include vložené všechny menší hlavičkové soubory. Je to proto, aby veřejné hlavičky nikdy nebyly vložené přímo. Místo toho se v aplikacích použije jediná direktiva include. Například GTK+ ve svých hlavičkových souborech, který by neměl být aplikací vloženy přímo, používá následující:</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>U knihoven by všechny hlavičkové soubory měly mít ochranu proti vícenásobnému vložení (pro interní použití) a pro integraci s C++. Ta poskytuje magické <code>extern "C"</code>, které vyžaduje C++ při vložení hlavičkového souboru prostého C:</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>Třídy GObject</title>

    <p>Definice a implementace třídy GObject vyžadují pár doplňujících poznámek ke stylu kódování a vždy by měly mít uveden <link xref="namespacing#gobject">správný jmenný prostor</link>.</p>

    <p>Deklarace typedef by měly být umístěny na začátku souboru:</p>

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

    <p>Včetně výčtových typů:</p>

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

    <p>A typů zpětných volání:</p>

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

    <p>Struktury instance by měly být deklarovány pomocí <code>G_DECLARE_FINAL_TYPE</code> nebo <code>G_DECLARE_DERIVABLE_TYPE</code>:</p>

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

    <p>Pro konečné typy mohou být privátní data uchována ve struktuře, která by měla být definována v souboru C:</p>

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

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

    <p>Pro typy, z který lze odvozovat další typy, musí být privátní data uchována v privátní struktuře v souboru C, která je nastavena pomocí <code>G_DEFINE_TYPE_WITH_PRIVATE()</code> a dostanete se k ní pomocí funkce <code>_get_instance_private()</code>:</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>Vždy používejte makra <code>G_DEFINE_TYPE()</code>, <code>G_DEFINE_TYPE_WITH_PRIVATE()</code> a <code>G_DEFINE_TYPE_WITH_CODE()</code> nebo jejich abstraktní varianty <code>G_DEFINE_ABSTRACT_TYPE()</code>, <code>G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE()</code> a <code>G_DEFINE_ABSTRACT_TYPE_WITH_CODE()</code>. Podobná makra používejte také pro definování rozhraní a boxované typy.</p>

    <p>Mezi typy rozhraní by vždy měla být i vzorová definice typu pro účely přetypování:</p>

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

    <p>Struktura rozhraní by měla mít v definici typu k názvu přidáno „Interface“:</p>

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

    <p>Rozhraní musí mít následující makra:</p>

    <table>
      <thead>
	<tr>
	  <td><p>Makro</p></td>
	  <td><p>Rozbalí se na</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>Přidělování paměti</title>

    <p>Když dynamicky alokujete data na haldě, použijte <code>g_new()</code>.</p>

    <p>Veřejné typy struktur by měly být vraceny vždy vynulované, buď výslovně pro jednotlivé členy struktury nebo pomocí <code>g_new0()</code>.</p>

    <p>Další podrobnosti viz <link xref="memory-management"/>.</p>
  </section>

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

    <p>Snažte se vyhnout privátním makrům, pokud nejsou vysloveně nutná. Pamatujte na jejich zrušení pomocí <code>#undef</code> na konci bloku nebo funkce nebo série funkcí, které je potřebovali.</p>

    <p>Před makry je obvykle dávána přednost vloženým funkcím.</p>

    <p>Veřejná makra by se neměla používat, pokud nejsou vyhodnocována do konstanty.</p>
  </section>

  <section id="public-api">
    <title>Veřejné API</title>

    <p>Vyhněte se exportování proměnných jako veřejné API, protože na některých platformách to může být nevhodné. Vždy místo toho dejte přednost funkcím pro získání a nastavení hodnoty. Zkuste se také vyhnout globálním proměnným.</p>
  </section>

  <section id="private-api">
    <title>Privátní API</title>

    <p>Neexportované funkce, které jsou zapotřebí ve více než jednom zdrojovém souboru by měly mít prefix v podobě podtržítka („_“) a měly by být deklarovány v privátním hlavičkovém souboru. Například <code>_mylib_internal_foo()</code>.</p>

    <p>Funkce začínající podtržítkem nejsou nikdy exportovány.</p>

    <p>Neexportované funkce, které jsou zapotřebí jen v jednom zdrojovém souboru by měly být deklarované jako statické.</p>
  </section>
</page>