repo_zf1/documentation/manual/nl/ref/coding_standard.xml

<appendix id="coding-standard">
  <title>Zend Framework Programmeer Standaard</title>

  <sect1 id="coding-standard.overview">
    <title>Overzicht</title>

    <sect2 id="coding-standard.overview.scope">
      <title>Bereik</title>

      <para>Dit document beschrijft de richtlijnen en
      hulpmiddelen voor softwareontwikkelaars en teams die programmeren met
      behulp van of die programmeren op het Zend Framework. De volgende onderwerpen zullen aan de orde komen:</para>

      <para><itemizedlist>
          <listitem>
            <para revisionflag="changed">PHP bestandsformattering</para>
          </listitem>

          <listitem>
            <para revisionflag="changed">Benamingsovereenkomst</para>
          </listitem>

          <listitem>
            <para revisionflag="changed">Codestijl</para>
          </listitem>

          <listitem>
            <para>Inline Documentatie</para>
          </listitem>
        </itemizedlist></para>
    </sect2>

    <sect2 id="coding-standard.overview.goals">
      <title>Doelen</title>

      <para>Goede coderichtlijnen zijn belangrijk in
      alle ontwikkelingsprojecten, in het bijzonder wanneer meerdere
      programmeurs aan eenzelfde project werken. De coderichtlijnen spelen een
      grote rol in het produceren van kwaliteitscode met minder bugs en die
      gemakkelijker kan worden onderhouden.</para>
    </sect2>
  </sect1>

  <sect1 id="coding-standard.php-file-formatting">
    <title>PHP Bestandsformattering</title>

    <sect2 id="coding-standard.php-file-formatting.general">
      <title>Algemeen</title>

      <para>Voor bestanden die alleen PHP code bevatten
      is de sluitende tag ("?&gt;") nooit toegelaten. Die wordt niet geëist
      door PHP. Het niet schrijven van deze afbakening voorkomt het toevoegen
      van spaties in de output.</para>

      <para><emphasis>BELANGRIJK</emphasis>: Toevoegen van binaire gegevens
      zoals toegelaten door <code>__HALT_COMPILER()</code> is niet toegelaten
      in eender welk Zend Framework PHP bestand of bestanden die daarvan zijn
      afgeleid. Het gebruik van deze mogelijkheid is alleen toegelaten in
      speciale installatie scripts.</para>
    </sect2>

    <sect2 id="coding-standard.php-file-formatting.indentation">
      <title>Indenting</title>

      <para>Gebruik een indent van 4 spaties, zonder tabulatie</para>
    </sect2>

    <sect2 id="coding-standard.php-file-formatting.max-line-length">
      <title>Maximale regellengte</title>

      <para>De doellengte voor een regel is 80 tekens,
      dus ontwikkelaars zouden moeten proberen om zo dicht mogelijk bij de 80
      kolommengrens te blijven èn praktisch te blijven. Langere regels zijn
      aanvaardbaar. De maximale lengte voor eender welke regel code in PHP is
      120 tekens.</para>
    </sect2>

    <sect2 id="coding-standard.php-file-formatting.line-termination">
      <title>Regeleinde</title>

      <para>Regeleindes worden geschreven volgens de
      Unix standaard. Regels moeten eindigen op één enkele linefeed (LF). Een
      linefeed is een ordinal 10, of een hexadecimale 0x0A.</para>

      <para>Gebruik geen carriage returns (CR) zoals
      Macintosh computers (0x0D).</para>

      <para>Gebruik geen carriage return/linefeed
      combinatie (CRLF) zoals Windows computers (0x0D, 0x0A).</para>
    </sect2>
  </sect1>

  <sect1 id="coding-standard.naming-conventions">
    <title>Benamingsovereenkomst</title>

    <sect2 id="coding-standard.naming-conventions.classes">
      <title>Klassen</title>

      <para>Het Zend Framework gebruikt een
      klassebenamingsovereenkomst waarbij de namen van de klassen direct
      overeenkomen met de mappen waarin ze zijn opgeslagen. De root directory
      van de Zend Framework is de "Zend" map, waaronder alle klassen
      hiërarchisch zijn ondergebracht.</para>

      <para>Klassenamen mogen alleen alfanumerieke tekens bevatten.
      Nummers zijn toegelaten in klassename maar worden afgeraden. Underscores
      zijn alleen toegelaten als vervanging van een padscheider -- de
      bestandsnaam "Zend/Db/Table.php" moet overeenkomen met de klassenaam
      "Zend_Db_Table".</para>

      <para>Indien een klassenaam bestaat uit meer dan één woord
      moet de eerste letter van elk woord een hoofdletter zijn. Opeenvolgende
      hoofdletters zijn niet toegestaan, bv. een klasse "Zend_PDF" is niet
      toegestaan terwijl "Zend_Pdf" aanvaardbaar is.</para>

      <para>Zend Framework klassenamen waarvan Zend of één van de
      bijdragende partners de auteur is en die met het Framework worden
      verzonden moeten altijd beginnen met "Zend_" en moeten in de "Zend/" map
      hiërarchie worden opgeslagen.</para>

      <para>Dit zijn voorbeelden van aanvaardbare
      klassenamen:</para>

      <para><programlisting role="php">Zend_Db

Zend_View

Zend_View_Helper
</programlisting> <emphasis>BELANGRIJK:</emphasis> Code die werkt met het Framework maar er geen
      deel van is, bv. code geschreven door een Frameworkgebruiker en niet
      door Zend of één van de Framework partnerbedrijven, mogen nooit
      beginnen met "Zend_".</para>
    </sect2>

    <sect2 id="coding-standard.naming-conventions.interfaces">
      <title>Interfaces</title>

      <para>Interface klassen moeten dezelfde overeenkomsten
      respecteren als andere klassen (zie hierboven), maar moeten bovendien
      eindigen op het woord "interface", zoals in deze
      voorbeelden:</para>

      <para><programlisting role="php">Zend_Log_Adapter_Interface
Zend_Controller_Dispatcher_Interface</programlisting></para>
    </sect2>

    <sect2 id="coding-standard.naming-conventions.filenames">
      <title>Bestandsnamen</title>

      <para>Voor alle andere bestanden zijn alleen alfanumerieke
      tekens, underscores en het min teken ("-") toegestaan. Spaties zijn
      verboden.</para>

      <para>Elk bestand dat PHP code bevat moet eindigen op de
      extensie ".php". Deze voorbeelden tonen aanvaardbare bestandsnamen voor
      bestanden die klassen bevatten uit de voorbeelden in de vorige
      sectie:</para>

      <para><programlisting role="php">Zend/Db.php

Zend/Controller/Front.php

Zend/View/Helper/FormRadio.php</programlisting> Bestandsnamen moeten de
      overeenkomst met de klassenamen respecteren, zoals hierboven
      beschreven.</para>
    </sect2>

    <sect2 id="coding-standard.naming-conventions.functions-and-methods">
      <title>Functies en methodes</title>

      <para>Functienamen mogen alleen alfanumerieke tekens bevatten.
      Underscores zijn niet toegestaan. Nummers zijn toegestaan in
      functienamen maar worden afgeraden.</para>

      <para>Functienamen moeten altijd met een kleine letter
      beginnen. Indien een functienaam bestaat uit meer dan één woord, moet de
      eerste letter van elk nieuw woord een hoofdletter zijn. Dit wordt
      de "studlyCaps" of "camelCaps" methode
      genoemd.</para>

      <para>Langsprekendheid wordt aangeraden. Functienamen zouden
      zoveel woorden moeten bevatten als praktisch is om het begrijpen van de
      code te vergemakkelijken.</para>

      <para>Dit zijn voorbeelden van aanvaardbare
      functienamen: <programlisting role="php">filterInput()

getElementById()

widgetFactory()</programlisting></para>

      <para>Voor objectgeoriënteerd programmeren zouden
      databenaderingsmethodes altijd met "get" of "set" moeten worden
      voorafgegaan. Bij het gebruik van ontwerppatronen, zoals het singleton
      of factory patroon, zou de naam van de methode de patroonnaam moeten
      bevatten indien mogelijk. Dit om het gebruik van het patroon
      gemakkelijker herkenbaar te maken.</para>

      <para>Functies in het globale bereik ("drijvende
      functies") zijn toegestaan maar afgeraden. Het is aanbevolen deze
      functies in een statische klasse te wikkelen.</para>
    </sect2>

    <sect2 id="coding-standard.naming-conventions.variables">
      <title>Variabelen</title>

      <para>Namen van variabelen mogen alleen bestaan uit alfanumerieke
      tekens. Underscores zijn niet toegestaan. Nummers zijn toegestaan maar
      worden afgeraden.</para>

      <para>Voor eigenschappen die verklaard worden met het "private" of
      "protected" concept moet het eerste teken van de functienaam een
      enkele underscore zijn. Dit is het enige aanvaardbare gebruik van de
      underscore in een functienaam. Eigenschappen verklaard als "public" mogen
      nooit met een underscore beginnen.</para>

      <para>Zoals functienamen (zie sectie 3.3, hierboven) moeten
      namen van variabelen altijd met een kleine letter beginnen en volgen ze de
      "camelCaps" behoofdletteringsovereenkomst.</para>

      <para>Langsprekendheid is aangeraden. Variabelen zouden zoveel
      woorden moeten bevatten als praktisch is. Beknopte variabelnamen zoals
      "$i" en "$n" worden afgeraden voor alles behalve de kleinst mogelijke
      loops. Als een loop meer dan 20 coderegels bevat, moeten de index
      variabelen meer beschrijvende namen hebben.</para>
    </sect2>

    <sect2 id="coding-standard.naming-conventions.constants">
      <title>Constanten</title>

      <para>Namen voor constanten mogen zowel alfanumerieke tekens
      als de underscore bevatten. Nummers zijn toegelaten in
      constantnamen.</para>

      <para>constantnamen moeten altijd alleen bestaan uit
      hoofdletters wat de alfanumerieke tekens betreft.</para>

      <para>Constanten moeten worden gedefinieerd als klasseleden
      door het concept "const" te gebruiken. Constanten verklaren in het
      globale bereik met "define" is toegelaten maar wordt afgeraden.</para>
    </sect2>
  </sect1>

  <sect1 id="coding-standard.coding-style">
    <title>Codestijl</title>

    <sect2 id="coding-standard.coding-style.php-code-demarcation">
      <title>PHP Code Afbakening</title>

      <para>PHP code moet altijd worden afgebakend met de volledige standaard PHP
      markeringen: <programlisting role="php">
&lt;?php

?&gt;</programlisting></para>

      <para>Korte markeringen zijn nooit toegelaten</para>
    </sect2>

    <sect2 id="coding-standard.coding-style.strings">
      <title>Strings</title>

      <sect3 id="coding-standard.coding-style.strings.literals">
        <title>String Literals</title>

        <para>Wanneer een string letterlijk is (hij bevat geen variabelvervanging),
        moet altijd de apostroof of "enkele quote" gebruikt worden om de string
        af te bakenen: <programlisting role="php">
$a = 'Voorbeeld String';</programlisting></para>
      </sect3>

      <sect3 id="coding-standard.coding-style.strings.literals-containing-apostrophes">
        <title>Letterlijke strings die apostrofen bevatten</title>

        <para>Wanneer een letterlijke string zelf apostrofen bevat is het
        toegelaten de string af te bakenen met aanhalingstekens ("double
        quotes"). Dit is dringend aangeraden voor SQL verklaringen:
        <programlisting role="php">
$sql = "SELECT `id`, `name` from `people` WHERE `name`='Fred' OR `name`='Susan'";</programlisting>
        De bovenstaande syntax is verkozen boven het "escapen" van de apostrofen.</para>
      </sect3>

      <sect3 id="coding-standard.coding-style.strings.variable-substitution">
        <title>Variabelvervanging</title>

        <para>Variabelvervanging is toegestaan met respect voor de volgende vormen: <programlisting role="php">
$greeting = "Hello $name, welcome back!";

$greeting = "Hello {$name}, welcome back!";</programlisting></para>

        <para>Om uniformiteit te respecteren is deze vorm niet toegestaan: <programlisting
        role="php">
$greeting = "Hello ${name}, welcome back!";</programlisting></para>
      </sect3>

      <sect3 id="coding-standard.coding-style.strings.string-concatenation">
        <title>String samenvoeging</title>

        <para>Strings kunnen samengevoegd worden met de "." operator. Er moet steeds een spatie
        vòòr en na de "." operator worden ingevoegd om de leesbaarheid te verbeteren: <programlisting role="php">
$company = 'Zend' . 'Technologies';</programlisting></para>

        <para>Wanneer men strings samenvoegt met de "." operator is het toegelaten
        de verklaring in meerdere regels op te breken om de leesbaarheid te vergroten.
        In dat geval moet elke opeenvolgende regel met spaties worden opgevuld zodat
        de "." operator uitgelijnd is onder de "=" operator: <programlisting role="php">
$sql = "SELECT `id`, `name` FROM `people` "
     . "WHERE `name` = 'Susan' "
     . "ORDER BY `name` ASC ";</programlisting></para>
      </sect3>
    </sect2>

    <sect2 id="coding-standard.coding-style.arrays">
      <title>Arrays</title>

      <sect3 id="coding-standard.coding-style.arrays.numerically-indexed">
        <title>Numeriek Geïndexeerde Arrays</title>

        <para>Negatieve nummers zijn verboden voor indexen.</para>

        <para>Een geïndexeerde array mag starten met eender welk niet negatief nummer.
        Dit wordt evenwel afgeraden. Het is aangeraden dat alle arrays een
        basisindex van 0 hebben.</para>

        <para>Wanneer men een geïndexeerde array definieert met het <code>array</code>
        concept moet er een spatie worden ingevoegd na elke komma afbakening om
        de leesbaarheid te verbeteren: <programlisting role="php">
$sampleArray = array(1, 2, 3, 'Zend', 'Studio');</programlisting></para>

        <para>Het is ook toegelaten om een geïndexeerde array op meerdere
        regels te definieren. In dat geval moet elke opeenvolgende regel met spaties
        worden opgevuld zodanig dat het begin van elke regel als volgt is uitgelijnd:
        <programlisting role="php">
$sampleArray = array(1, 2, 3, 'Zend', 'Studio',
                     $a, $b, $c,
                     56.44, $d, 500);</programlisting></para>
      </sect3>

      <sect3 id="coding-standard.coding-style.arrays.associative">
        <title>Associatieve Arrays</title>

        <para>Wanneer men associatieve arrays met het <code>array</code>
        concept definieert is het aangeraden de verklaring in meerdere regels op te
        breken. In dat geval moet elke opeenvolgende regel met spaties worden
        opgevuld zodat de indexen (keys) en waarden (values) uitgelijnd zijn:
        <programlisting role="php">
$sampleArray = array('firstKey'  =&gt; 'firstValue',
                     'secondKey' =&gt; 'secondValue');</programlisting></para>
      </sect3>
    </sect2>

    <sect2 id="coding-standard.coding-style.classes">
      <title>Klassen</title>

      <sect3 id="coding-standard.coding-style.classes.declaration">
        <title>Klasse Verklaring</title>

        <para>Klassebenaming moet de volgende overeenkomsten volgen.</para>

        <para>De accolade wordt steeds op de regel onder de klassenaam geschreven
        ("one true brace" vorm).</para>

        <para>Elke klasse moet een documentatieblok hebben dat de PHPDocumentor
        standaard volgt.</para>

        <para>Code in een klasse moet geïndenteerd zijn met vier spaties.</para>

        <para>Eén klasse, éen bestand.</para>

        <para>Bijkomende code schrijven in een klassebestand is toegelaten maar wordt
        afgeraden. Indien men het toch doet moet de bijkomende code met twee lege
        regels worden gescheiden van de klassecode.</para>

        <para>Dit is een voorbeeld van een aanvaardbare klasseverklaring:
        <programlisting role="php">
/**
 * Documentatie Blok Hier
 */
class SampleClass
{
    // de gehele inhoud van de klasse
    // moet geindenteerd worden met vier spaties
}</programlisting></para>
      </sect3>

      <sect3 id="coding-standard.coding-style.classes.member-variables">
        <title>Klasse lidvariabelen</title>

        <para>Lidvariabelen moeten benaamd worden volgens de variabele
        benamingsovereenkomst.</para>

        <para>Variabelen die in de klasse worden verklaard moeten bovenaan
        in de klasse worden opgesomd, vòòrdat functies worden verklaard.</para>

        <para>Het concept <code>var</code> is niet toegestaan. Lidvariabelen
        moeten steeds hun zichtbaarheid verklaren door één van de <code>private</code>,
        <code>protected</code>, of <code>public</code> concepten te gebruiken.
        Toegang verlenen aan lidvariabelen door hen publiek te maken is toegestaan
        maar wordt afgeraden ten voordele van de databenaderingsmethodes (set/get).</para>
      </sect3>
    </sect2>

    <sect2 id="coding-standard.coding-style.functions-and-methods">
      <title>Functies en Methodes</title>

      <sect3 id="coding-standard.coding-style.functions-and-methods.declaration">
        <title>Functie en Methode Verklaring</title>

        <para>Functiebenaming moet de benamingsovereenkomsten volgen.</para>

        <para>Functies binnen klasses moeten steeds hun zichtbaarheid verklaren
        door één van de <code>private</code>, <code>protected</code>, of
        <code>public</code> concepten te gebruiken.</para>

        <para>Net zoals klassen, moet de accolade steeds op de regel onder de functienaam
        worden geschreven ("one true brace" vorm). Er is geen spatie tussen de functienaam
        en de haakjes voor de argumenten. Er is één spatie tussen de sluitende haakjes en de
        accolade.</para>

        <para>Functies in het globale bereik zijn zeer sterk afgeraden.</para>

        <para>Dit is een voorbeeld van een aanvaardbare verklaring van een functie in een klasse:
        <programlisting role="php">
/*
 * Documentatie blok hier
 */
function sampleMethod($a)
{
    // de gehele inhoud van de functie
    // moet geindenteerd worden met vier spaties
}</programlisting></para>

        <para><emphasis>NOTA:</emphasis> Doorgeven per verwijzing (pass by reference) is
        alleen toegestaan in de functieverklaring: <programlisting role="php">
function sampleMethod(&amp;$a)
{}</programlisting></para>

        <para>Call-time pass by reference is verboden.</para>

        <para>De terugkeerwaarde mag niet tussen haakjes worden ingesloten.
        Dat kan de leesbaarheid hinderen en kan ook de code breken indien een
        methode later wordt veranderd om per verwijzing terug te sturen.
        <programlisting role="php">
function foo()
{
    // FOUT
    return($this-&gt;bar);

    // GOED
    return $this-&gt;bar;
}</programlisting></para>
      </sect3>

      <sect3 id="coding-standard.coding-style.functions-and-methods.usage">
        <title>Functie- en Methodegebruik</title>

        <para>Functie-argumenten worden gescheiden door één enkele spatie
        na de komma afbakening. Dit is een voorbeeld van een aanvaardbare
        functie-aanroep voor een functie die drie argumenten heeft:
        <programlisting role="php">
threeArguments(1, 2, 3);</programlisting></para>

        <para>Call-time pass by reference is verboden. Zie de sectie over
        functieverklaringen voor de juiste wijze om argumenten per verwijzing door te
        sturen.</para>

        <para>Voor functies welke arrays als argument aanvaardden mag de
        functieaanroep het "array" concept bevatten en kan deze in meerdere
        regels worden opgesplitst om de leesbaarheid te vergroten.
        In deze gevallen blijven de regels voor het schrijven van arrays van
        kracht: <programlisting role="php">
threeArguments(array(1, 2, 3), 2, 3);

threeArguments(array(1, 2, 3, 'Zend', 'Studio',
                     $a, $b, $c,
                     56.44, $d, 500), 2, 3);</programlisting></para>
      </sect3>
    </sect2>

    <sect2 id="coding-standard.coding-style.control-statements">
      <title>Control Statements</title>

      <sect3 id="coding-standard.coding-style.control-statements.if-else-elseif">
        <title>If / Else / Elseif</title>

        <para>Control statements gebaseerd op <code>if</code> en
        <code>elseif</code> concepten moeten een enkele spatie voor de openende
        haakjes van de conditie, en een enkele spatie na de sluitende haakjes.</para>

        <para>In de voorwaardeverklaringen tussen de haakjes moeten
        operators gescheiden worden met spaties om de leesbaarheid te
        bevorderen. Binnenhaakjes zijn aangeraden voor het groeperen van
        meer complexe voorwaarden.</para>

        <para>De openingsaccolade wordt op dezelfde regel als de
        voorwaardeverklaring geschreven. De sluitende accolade wordt altijd op
        een alleenstaande regel geschreven. Alle inhoud binnenin de accolades
        moet steeds met vier spaties geïndenteerd worden.
        <programlisting role="php">
if ($a != 2) {
    $a = 2;
}</programlisting></para>

        <para>Voor "if" verklaringen die "else if" of "else" inhouden moet de vorm
        zoals in de volgende voorbeelden zijn: <programlisting role="php">
if ($a != 2) {
    $a = 2;
} else {
    $a = 7;
}


if ($a != 2) {
    $a = 2;
} else if ($a == 3) {
    $a = 4;
} else {
    $a = 7;
}</programlisting> PHP laat het toe om in bepaalde gevallen deze verklaringen zonder
        accolades te schrijven. De codestandaard maakt geen verschil en alle "if",
        "else if" of "else" verklaringen moeten accolades gebruiken.</para>

        <para>Het gebruik van "elseif" is toegestaan maar "else if" wordt sterk
        aanbevolen.</para>
      </sect3>

      <sect3 id="coding-standards.coding-style.control-statements.switch">
        <title>Switch</title>

        <para>Control statements geschreven met "switch" moeten een enkele spatie
        voor de openende haakjes van de voorwaardeverklaring hebben, en een enkele
        spatie na de sluitende haakjes.</para>

        <para>Alle inhoud binnen een "switch" verklaring moet met vier spaties
        geïndenteerd worden. Inhoud onder elke "case" moet geïndenteerd worden
        met vier extra spaties.</para>

        <programlisting role="php">
switch ($numPeople) {
    case 1:
        break;

    case 2:
        break;

    default:
        break;
}</programlisting>

        <para><code>default</code> mag nooit weggelaten worden van een
        <code>switch</code> verklaring.</para>

        <para><emphasis>NOTA:</emphasis> Het is soms handig een <code>case</code>
        verklaring te hebben die doorvalt naar de volgende <code>case</code>
        verklaring door het weglaten van <code>break</code> of <code>return</code>
        in de verklaring. Om deze gevallen van bugs te onderscheiden moet elk
        van de gevallen waarin een <code>break</code> of <code>return</code>
        wordt weggelaten een commentaar "// break intentionally omitted"
        bevatten.</para>
      </sect3>
    </sect2>

    <sect2 id="coding-standards.inline-documentation">
      <title>Inline Documentatie</title>

      <sect3 id="coding-standards.inline-documentation.documentation-format">
        <title>Documentatie Formaat</title>

        <para>Alle documentatieblokken ("docblocks") moeten compatibel zijn
        met het phpDocumentor formaat. Een beschrijving van het
        phpDocumentor formaat is buiten het bereik van dit document.
        Voor meer informatie kunt u terecht op: <ulink
        url="http://phpdoc.org/">http://phpdoc.org"</ulink></para>

        <para>Alle broncodebestanden geschreven voor het Zend Framework of dat
        ermee samenwerkt moet een "file-level" docblock bevatten aan het begin
        van elk bestand en een "class-level" docblock onmiddellijk boven elke
        klasse. Hierna enkele voorbeelden van zulke docblocks.</para>
      </sect3>

      <sect3 id="coding-standards.inline-documentation.files">
        <title>Bestanden</title>

        <para>Elk bestand dat PHP code bevat moet een hoofdblok aan het
        begin van het bestand bevatten dat minstens de volgende
        phpDocumentor gegevens bevat: <programlisting role="php">
/**
 * Korte beschrijving van het bestand
 *
 * Lange beschrijving van het bestand (indien aanwzeig)...
 *
 * LICENSE: Licentie informatie
 *
 * @copyright  Copyright (c) 2005-2015 Zend Technologies USA Inc. (http://www.zend.com)
 * @license    http://www.zend.com/license/3_0.txt   PHP License 3.0
 * @version    $Id:$
 * @link       http://dev.zend.com/package/PackageName
 * @since      File available since Release 1.2.0
*/</programlisting></para>
      </sect3>

      <sect3 id="coding-standards.inline-documentation.classes">
        <title>Klassen</title>

        <para>Elke klasse moet een docblock bevatten dat minstens
        de volgende phpDocumentor gegevens bevat: <programlisting role="php">
/**
 * Korte beschrijving van de klasse
 *
 * Lange beschrijving van de klasse (indien aanwezig)...
 *
 * @copyright  Copyright (c) 2005-2015 Zend Technologies USA Inc. (http://www.zend.com)
 * @license    http://www.zend.com/license/3_0.txt   PHP License 3.0
 * @version    Release: @package_version@
 * @link       http://dev.zend.com/package/PackageName
 * @since      Class available since Release 1.2.0
 * @deprecated Class deprecated in Release 2.0.0
 */</programlisting></para>
      </sect3>

      <sect3 id="coding-standards.inline-documentation.functions">
        <title>Functies</title>

        <para>Elke functie, methodes inbegrepen, moet een docblock hebben
        dat minstens het volgende bevat: <itemizedlist>
            <listitem>
              <para>Een beschrijving van de functie</para>
            </listitem>

            <listitem>
              <para>Alle argumenten</para>
            </listitem>

            <listitem>
              <para>Alle mogelijke terugwaarden</para>
            </listitem>
          </itemizedlist></para>

        <para>Het is niet nodig om de "@access" tags te gebruiken
        want de zichtbaarheid is reeds bekend via het gebruik van
        "public", "private", of "protected" bij het verklaren van de
        functie.</para>

        <para>Indien een functie of methode een exception mag teruggeven,
        gebruik @throws:
        <programlisting role="php">
@throws exceptionClass [beschrijving]
</programlisting></para>
      </sect3>
    </sect2>
  </sect1>
</appendix>
<!--
vim:se ts=4 sw=4 et:
-->