coding_standard.xml 34 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- EN-Revision: 15157 -->
  3. <!-- Reviewed: no -->
  4. <appendix id="coding-standard">
  5. <title>Zend Framework Coding Standard für PHP</title>
  6. <sect1 id="coding-standard.overview">
  7. <title>Übersicht</title>
  8. <sect2 id="coding-standard.overview.scope">
  9. <title>Geltungsbereich</title>
  10. <para>
  11. Dieses Dokument bietet Richtlinien für die Formatierung von Code und Dokumentation
  12. für Individuen und Teams die im Zend Framework mitarbeiten. Viele Entwickler die
  13. den Zend Framework verwenden haben diese Code Standards als nützlich empfunden weil
  14. Ihr Code Stil mit jedem Zend Framework Code konsistent bleibt. Es ist auch
  15. anzumerken das es signifikant viel Arbeit erfordert einen kompletten Coding
  16. Standard zu definieren.
  17. Beachte: Manchmal entscheiden Entwickler das die Verfügbarkeit eines Standards
  18. wichtiger ist als was der Standard aktuell im höchsten Level des Designs empfiehlt.
  19. Diese Richtlinien im Zend Framework Coding Standard beschreiben die Praxis die im
  20. ZF Projekt sehr gut funktionieren. Diese Standard können geändert oder so wie sie
  21. sind verwendet werden solange Sie sich an unsere
  22. <ulink url="http://framework.zend.com/license">Lizenz</ulink> halten.
  23. </para>
  24. <para>
  25. Die Bereiche die im ZF Coding Standard abgedeckt werden enthalten:
  26. <itemizedlist>
  27. <listitem>
  28. <para>PHP Dateiformatierung</para>
  29. </listitem>
  30. <listitem>
  31. <para>Namens Konventionen</para>
  32. </listitem>
  33. <listitem>
  34. <para>Code Stil</para>
  35. </listitem>
  36. <listitem>
  37. <para>Inline Dokumentation</para>
  38. </listitem>
  39. </itemizedlist>
  40. </para>
  41. </sect2>
  42. <sect2 id="coding-standard.overview.goals">
  43. <title>Ziele</title>
  44. <para>
  45. Coding Standards sind in jedem Entwicklungs Projekt wichtig, aber sie sid speziell
  46. dann wichtig wenn viele Entwickler an dem gleichen Projekt arbeiten. Coding
  47. Standards helfen sicherzustellen das der Code von hoher Qualität ist, weniger
  48. Fehler hat, und einfach zu warten ist.
  49. </para>
  50. </sect2>
  51. </sect1>
  52. <sect1 id="coding-standard.php-file-formatting">
  53. <title>PHP Dateiformatierung</title>
  54. <sect2 id="coding-standard.php-file-formatting.general">
  55. <title>Allgemein</title>
  56. <para>
  57. Für Dateien, welche nur PHP Code beinhalten ist der schliessende Tag ("?>") nicht
  58. zugelassen. Er wird von PHP nicht benötigt, und das Weglassen verhindert das
  59. versehentlich Leerzeilen in die Antwort eingefügt werden.
  60. </para>
  61. <para>
  62. <emphasis>WICHTIG:</emphasis> Einbeziehen von beliebigen binärischen Daten durch
  63. <code>__HALT_COMPILER()</code> ist in den PHP Dateien im Zend Framework oder
  64. abgeleiteten Datei verboten. Das Benutzen ist nur für einige Installationsskirpte
  65. erlaubt.
  66. </para>
  67. </sect2>
  68. <sect2 id="coding-standard.php-file-formatting.indentation">
  69. <title>Einrücken</title>
  70. <para>
  71. Ein Einzug sollte aus 4 Leerzeichen bestehen. Tabulatoren sind nicht erlaubt.
  72. </para>
  73. </sect2>
  74. <sect2 id="coding-standard.php-file-formatting.max-line-length">
  75. <title>Maximale Zeilenlänge</title>
  76. <para>
  77. Die Zielzeilenlänge ist 80 Zeichen. Entwickler sollten jede Zeile Ihres Codes unter
  78. 80 Zeichen halten, soweit dies möglich und praktikabel ist. Trotzdem sind längere
  79. Zeilen in einigen Fällen erlaubt. Die maximale Länge einer Zeile beträgt 120
  80. Zeichen.
  81. </para>
  82. </sect2>
  83. <sect2 id="coding-standard.php-file-formatting.line-termination">
  84. <title>Zeilenbegrenzung</title>
  85. <para>
  86. Die Zeilenbegrenzung folgt der Unix Textdatei Konvention. Zeilen müssen mit
  87. einem einzelnen Zeilenvorschubzeichen (LF) enden. Zeilenvorschub Zeicen werden duch
  88. eine ordinale 10, oder durch 0x0A (hexadecimal) dargestellt.
  89. </para>
  90. <para>
  91. Beachte: Benutze nicht den Wagenrücklauf (CR) wie in den Konventionen von Apple's
  92. OS (0x0D) oder die Kombination aus Wagenrücklauf und Zeilenvorschub (CRLF) wie im
  93. Standard für das Windows OS (0x0D, 0x0A).
  94. </para>
  95. </sect2>
  96. </sect1>
  97. <sect1 id="coding-standard.naming-conventions">
  98. <title>Namens Konventionen</title>
  99. <sect2 id="coding-standard.naming-conventions.classes">
  100. <title>Klassen</title>
  101. <para>
  102. Zend Framework standartisiert eine Klassennamen Konvention wobei die Namen der
  103. Klassen direkt mit den Verzeichnissen übereinstimmen muß in welchen Sie gespeichert
  104. sind. Das Basisverzeichnis der ZF Standard Bibliothek ist das "Zend/" Verzeichnis,
  105. wobei das Basisverzeichnis der ZF Extras Bibliothek im "ZendX/" Verzeichnis ist.
  106. Alle Zend Framework Klassen werden hierarchisch unter dem gleichen Basisverzeichnis
  107. gespeichert.
  108. </para>
  109. <para>
  110. Klassennamen dürfen nur alphanumerische Zeichen enthalten. Nummern sind in
  111. Klassennamen gestattet es wird aber von Ihnen in den meisten Fällen abgeraten.
  112. Unterstriche sind nur gestattet im Platz des Pfadseparators -- der Dateiname
  113. "Zend/Db/Table.php" muß übereinstimmen mit dem Klassennamen "Zend_Db_Table".
  114. </para>
  115. <para>
  116. Wenn ein Klassenname aus mehr als einem Wort besteht, muß der erste Buchstabe von
  117. jedem neuen Wort großgeschrieben werden. Durchgehende Großbuchstaben sind nicht
  118. erlaubt, z.B. eine Klasse "Zend_PDF" ist nicht erlaubt, aber "Zend_Pdf" ist
  119. akzeptierbar.
  120. </para>
  121. <para>
  122. Diese Konventionen definieren einen Pseudo-Namespace Mechanismus für Zend
  123. Framework. Zend Framework wird das PHP Namespace Feature einbauen sobald es
  124. verfügbar ist und es für unsere Entwickler in deren Anwendungen ohne Bedenken
  125. verwendbar ist.
  126. </para>
  127. <para>
  128. Siehe die Klassennamen in der Standard und Extra Bibliothek für Beispiel dieser
  129. Klassennamen Konvention.
  130. <emphasis>WICHTIG:</emphasis> Code welcher mit dem Framework ausgeliefert werden
  131. muß, aber nicht Teil der Standard oder Extras Bibliothek ist (z.B. Anwendungscode
  132. oder Bibliotheken die nicht von Zend ausgeliefert werden), dürfen nie mit "Zend_"
  133. oder "ZendX_" beginnen.
  134. </para>
  135. </sect2>
  136. <sect2 id="coding-standard.naming-conventions.filenames">
  137. <title>Dateinamen</title>
  138. <para>
  139. Für alle anderen Dateien sind nur alphanummerische Zeichen, Unterstriche, und der
  140. Bindestrich ("-") gestattet. Leerzeichen sind völlig verboten.
  141. </para>
  142. <para>
  143. Jede Datei die irgendeinen PHP Code enthält sollte mit der Endung ".php" enden, mit
  144. Ausnahme der View Skripte. Die folgenden Beispiele zeigen akzeptierbare Dateinamen
  145. für Zend Framework Klassen:
  146. <programlisting role="php"><![CDATA[
  147. Zend/Db.php
  148. Zend/Controller/Front.php
  149. Zend/View/Helper/FormRadio.php
  150. ]]></programlisting>
  151. Dateinamen müssen den Klassennamen wie oben beschrieben entsprechen.
  152. </para>
  153. </sect2>
  154. <sect2 id="coding-standard.naming-conventions.functions-and-methods">
  155. <title>Funktionen und Methoden</title>
  156. <para>
  157. Funktionsnamen dürfen nur Alphanummerische Zeichen enthalten. Unterstriche sind
  158. nicht gestattet. Nummern sind in Funktionsnamen gestattet aber in den meisten
  159. Fällen nicht empfohlen.
  160. </para>
  161. <para>
  162. Funktionsnamen müssen immer mit einem Kleinbuchstaben anfangen. Wenn Funktionsnamen
  163. aus mehr als einem Wort bestehen, muß der erste Buchstabe jeden Wortes
  164. großgeschrieben werden. Das wird normalerweise "camelCase" Formatierung genannt.
  165. </para>
  166. <para>
  167. Wortreichtum wird generell befürwortet. Funktionsnamen sollten so wortreich wie
  168. möglich sein um deren Zweck und Verhalten zu erklären.
  169. </para>
  170. <para>
  171. Das sind Beispiele akzeptierbarer Namen für Funktionen:
  172. <programlisting role="php"><![CDATA[
  173. filterInput()
  174. getElementById()
  175. widgetFactory()
  176. ]]></programlisting>
  177. </para>
  178. <para>
  179. Für objekt-orientiertes Programmieren, sollten Zugriffspunkte für Instanzen oder
  180. statische Variablen immer mit "get" oder "set" beginnen. Wenn Design-Pattern
  181. implementiert werden, wie Singleton oder das Factory Pattern, sollte der Name der
  182. Methode den Namen des Pattern enthalten wo es praktikabel ist, um das Verhalten
  183. besser zu beschreiben.
  184. </para>
  185. <para>
  186. Für Methoden in Objekten die mit dem "private" oder "protected" Modifikator
  187. deklariert sind, muß das erste Zeichen des Namens der Methode ein einzelner
  188. Unterstrich sein. Das ist die einzige akzeptable Anwendung von einem Unterstrich
  189. im Namen einer Methode. Methoden die als "public" deklariert sind sollten nie
  190. einem Unterstrich enthalten.
  191. </para>
  192. <para>
  193. Funktionen im globalen Bereich (auch "floating functions" genannt) sind gestattet
  194. aber es wird von Ihnen in den meisten Fällen abgeraten. Diese Funktionen sollten
  195. in einer statischen Klasse gewrappt werden.
  196. </para>
  197. </sect2>
  198. <sect2 id="coding-standard.naming-conventions.variables">
  199. <title>Variablen</title>
  200. <para>
  201. Variablennamen dürfen nur Alphanummerische Zeichen enthalten. Unterstriche sind
  202. nicht gestattet. Nummern sind in Variablen gestattet in den meisten Fällen aber
  203. nicht empfohlen.
  204. </para>
  205. <para>
  206. Für Instanzvariablen die mit dem "private" oder "protected" Modifikator deklariert werden,
  207. muß das erste Zeichen des Funktionsnamens ein einzelner Unterstrich sein. Das ist die
  208. einzige akzeptierte Anwendung eines Unterstriches in einem variablen Namen. Klassenvariablen
  209. welche als "public" deklariert werden sollten nie mit einem Unterstrich beginnen.
  210. </para>
  211. <para>
  212. Wie bei Funktionsnamen (siehe Abschnitt 3.3) müssen Variablennamen immer mit einem
  213. Kleinbuchstaben starten und der "camelCaps" Schreibweise folgen.
  214. </para>
  215. <para>
  216. Wortreichtum wird generell befürwortet. Variablen sollen immer so wortreich wie möglich sein
  217. um die Daten zu beschreiben die der Entwickler in Ihnen zu speichern gedenkt.
  218. Von gedrängte Variablennamen wie "$i" und "$n" wird abgeraten für alles außer die kleinsten
  219. Schleifen. Wenn eine Schleife mehr als 20 Codezeilen enthält sollten die Index-Variablen
  220. einen ausführlicheren Namen haben.
  221. </para>
  222. </sect2>
  223. <sect2 id="coding-standard.naming-conventions.constants">
  224. <title>Konstanten</title>
  225. <para>
  226. Konstanten können beides enthalten, sowohl Alphanummerische Zeichen als auch Unterstriche.
  227. Nummern sind in Konstantennamen gestattet.
  228. </para>
  229. <para>
  230. Alle Buchstaben die in Konstantenname verwendet werden müssen großgeschrieben haben, wärend
  231. Wörter in einem Konstantennamen durch Unterstriche getrennt werden müssen.
  232. </para>
  233. <para>
  234. Zum Beispiel ist <code>EMBED_SUPPRESS_EMBED_EXCEPTION</code> gestattet aber
  235. <code>EMBED_SUPPRESSEMBEDEXCEPTION</code> nicht.
  236. </para>
  237. <para>
  238. Konstanten müssen als Klassenkonstanten definiert werden mit dem "const" Modifikator.
  239. Die Definition von Konstanten im globalen Bereich mit der "define" Funktion ist gestattet
  240. aber es wird es wird stärkstens davon abgeraten.
  241. </para>
  242. </sect2>
  243. </sect1>
  244. <sect1 id="coding-standard.coding-style">
  245. <title>Code Stil</title>
  246. <sect2 id="coding-standard.coding-style.php-code-demarcation">
  247. <title>PHP Code Abgrenzung</title>
  248. <para>
  249. PHP Code muß immer mit der kompletten Form des Standard-PHP Tags abgegrenzt sein:
  250. <programlisting role="php"><![CDATA[
  251. <?php
  252. ?>
  253. ]]></programlisting>
  254. </para>
  255. <para>
  256. Kurze Tags sind nie erlaubt. Für Dateien die nur PHP Code enthalten, darf
  257. das schließende Tag nie angegeben werden (Siehe
  258. <xref linkend="coding-standard.php-file-formatting.general"/>).
  259. </para>
  260. </sect2>
  261. <sect2 id="coding-standard.coding-style.strings">
  262. <title>Strings</title>
  263. <sect3 id="coding-standard.coding-style.strings.literals">
  264. <title>String Literale</title>
  265. <para>
  266. Wenn ein String ein Literal ist (er also keine Variablenvertreter enthält), sollte
  267. immer das Apostroph oder "einzelne Anführungszeichen" verwendet werden um den String
  268. abzugrenzen:
  269. <programlisting role="php"><![CDATA[
  270. $a = 'Beispiel String';
  271. ]]></programlisting>
  272. </para>
  273. </sect3>
  274. <sect3 id="coding-standard.coding-style.strings.literals-containing-apostrophes">
  275. <title>String Literale die Apostrophe enthalten</title>
  276. <para>
  277. Wenn ein literaler String selbst Apostrophe enthält, ist es gestattet den String mit
  278. Anführungszeichen oder "doppeltes Anführungszeichen" abzugrenzen. Das ist speziell für
  279. SQL Anweisungen nützlich:
  280. <programlisting role="php"><![CDATA[
  281. $sql = "SELECT `id`, `name` from `people` "
  282. . "WHERE `name`='Fred' OR `name`='Susan'";
  283. ]]></programlisting>
  284. Diese Syntax ist zu bevorzugen, im Gegensatz zum Ausbruch von Apostrophs, da Sie viel
  285. einfacher lesbar ist.
  286. </para>
  287. </sect3>
  288. <sect3 id="coding-standard.coding-style.strings.variable-substitution">
  289. <title>Variabler Austausch</title>
  290. <para>
  291. Variabler Austausch ist gestatten bei Verwendung einer der Formen:
  292. <programlisting role="php"><![CDATA[
  293. $greeting = "Halle $name, willkommen zurück!";
  294. $greeting = "Hallo {$name}, willkommen zurück!";
  295. ]]></programlisting>
  296. </para>
  297. <para>
  298. Aus Gründen der Konstistenz ist folgende Form nicht gestattet:
  299. <programlisting role="php"><![CDATA[
  300. $greeting = "Hallo ${name}, willkommen zurück!";
  301. ]]></programlisting>
  302. </para>
  303. </sect3>
  304. <sect3 id="coding-standard.coding-style.strings.string-concatenation">
  305. <title>Verbinden von Strings</title>
  306. <para>
  307. Strings müssen verbunden werden indem man den "." Operator verwendet. Ein Leerzeichen muß
  308. immer vor und nach dem "." Operator hinzugefügt werden um die Lesbarkeit zu erhöhen:
  309. <programlisting role="php"><![CDATA[
  310. $company = 'Zend' . ' ' . 'Technologies';
  311. ]]></programlisting>
  312. </para>
  313. <para>
  314. Wenn Strings mit dem "." Operator verbunden werden, ist es empfohlen die Anweisung in
  315. mehrere Zeilen umzubrechen um die Lesbarkeit zu erhöhen. In diesen Fällen sollte jede
  316. folgende Zeile mit Leerraum aufgefüllt werden so das der "." Operator genau unterhalb
  317. des "=" Operators ist:
  318. <programlisting role="php"><![CDATA[
  319. $sql = "SELECT `id`, `name` FROM `people` "
  320. . "WHERE `name` = 'Susan' "
  321. . "ORDER BY `name` ASC ";
  322. ]]></programlisting>
  323. </para>
  324. </sect3>
  325. </sect2>
  326. <sect2 id="coding-standard.coding-style.arrays">
  327. <title>Arrays</title>
  328. <sect3 id="coding-standard.coding-style.arrays.numerically-indexed">
  329. <title>Nummerisch indizierte Arrays</title>
  330. <para>Negative Nummern sind in Indezes nicht gestattet.</para>
  331. <para>
  332. Ein indiziertes Array kann mit mit irgendeiner nicht-negativen Nummer beginnen, trotzdem
  333. sind alle BasisIndex neben 0 nicht erlaubt.
  334. </para>
  335. <para>
  336. Wenn indizierte Arrays mit dem <code>array</code> Funktion deklariert werden, muß ein
  337. folgendes Leerzeichen nach jeder Kommabegrenzung hinzugefügt werden um die Lesbarkeit
  338. zu erhöhen:
  339. <programlisting role="php"><![CDATA[
  340. $sampleArray = array(1, 2, 3, 'Zend', 'Studio');
  341. ]]></programlisting>
  342. </para>
  343. <para>
  344. Es ist gestattet mehrzeilige indizierte Arrays zu definieren bei Verwendung des
  345. "array" Konstrukts. In diesem Fall, muß jede folgende Zeile mit Leerzeichen aufgefüllt
  346. werden so das der Beginn jeder Zeile ausgerichtet ist:
  347. <programlisting role="php"><![CDATA[
  348. $sampleArray = array(1, 2, 3, 'Zend', 'Studio',
  349. $a, $b, $c,
  350. 56.44, $d, 500);
  351. ]]></programlisting>
  352. </para>
  353. </sect3>
  354. <sect3 id="coding-standard.coding-style.arrays.associative">
  355. <title>Assoziative Arrays</title>
  356. <para>
  357. Wenn assoziative Arrays mit dem <code>array</code> Konstrukt deklariert werden, ist das
  358. Umbrechen der Anweisung in mehrere Zeilen gestattet. In diesem Fall muß jede folgende
  359. Linie mit Leerraum aufgefüllt werden so das beide, der Schlüssel und der Wert untereinander
  360. stehen:
  361. <programlisting role="php"><![CDATA[
  362. $sampleArray = array('firstKey' => 'firstValue',
  363. 'secondKey' => 'secondValue');
  364. ]]></programlisting>
  365. </para>
  366. </sect3>
  367. </sect2>
  368. <sect2 id="coding-standard.coding-style.classes">
  369. <title>Klassen</title>
  370. <sect3 id="coding-standard.coding-style.classes.declaration">
  371. <title>Klassen Deklarationen</title>
  372. <para>
  373. Klassen müssen entsprechend der Zend Framework Namenskonvention benannt werden.
  374. </para><para>
  375. Die Klammer sollte immer in der Zeile unter dem Klassennamen geschrieben werden.
  376. </para><para>
  377. Jede Klasse muß einen Dokumentationsblock haben der dem PHPDocumentor Standard entspricht.
  378. </para><para>
  379. Jeder Code in der Klasse muß mit vier Leerzeichen eingerückt sein.
  380. </para><para>
  381. Nur eine Klasse ist in jeder PHP Datei gestattet.
  382. </para><para>
  383. Das Platzieren von zusätzlichem Code in Klassendateien ist gestattet aber es wird davon
  384. abgeraten. In solchen Dateien müssen zwei leere Zeilen die Klasse von jedem zusätzlichen PHP
  385. Code in der Datei seperieren.
  386. </para><para>
  387. Das folgende ist ein Beispiel einer akzeptierbaren Klassendeklaration:
  388. <programlisting role="php"><![CDATA[
  389. /**
  390. * Dokumentations Block hier
  391. */
  392. class SampleClass
  393. {
  394. // gesamter Inhalt der Klasse
  395. // muss mit vier Leerzeichen eingerückt sein
  396. }
  397. ]]></programlisting>
  398. </para>
  399. </sect3>
  400. <sect3 id="coding-standard.coding-style.classes.member-variables">
  401. <title>Klassenvariablen</title>
  402. <para>
  403. Klassenvariablen müssen entsprechend den Variablen-Benennungs-Konventionen des
  404. Zend Frameworks benannt werden.
  405. </para>
  406. <para>
  407. Jede Variable die in der Klasse deklariert wird muß am Beginn der Klasse ausgelistet werden,
  408. vor der Deklaration von allen Methoden.
  409. </para>
  410. <para>
  411. Das <code>var</code> Konstrukt ist nicht gestattet. Klassenvariablen definieren Ihre
  412. Sichtbarkeit durch die Verwendung des <code>private</code>, <code>protected</code>,
  413. oder <code>public</code> Modifikatoren. Das gestatten von direktem Zugriff auf
  414. Klassenvariablen durch deren Deklaration als public ist gestattet aber es wird davon
  415. abgeraten da hierfür Zugriffsmethoden verwendet werden sollten (set/get).
  416. </para>
  417. </sect3>
  418. </sect2>
  419. <sect2 id="coding-standard.coding-style.functions-and-methods">
  420. <title>Funktionen und Methoden</title>
  421. <sect3 id="coding-standard.coding-style.functions-and-methods.declaration">
  422. <title>Deklaration von Funktionen und Methoden</title>
  423. <para>
  424. Funktionen müssen nach der Funktions-Namenskonvention des Zend Frameworks benannt werden.
  425. </para>
  426. <para>
  427. Methoden innerhalb von Klassen müssen immer Ihre Sichtbarkeit durch Verwendung einer der
  428. <code>private</code>, <code>protected</code>, oder <code>public</code> Modifikatoren
  429. definieren.
  430. </para>
  431. <para>
  432. Wie bei Klassen, sollte die Klammer immer in der Zeile unterhalb des Funktionsnamens
  433. geschrieben werden.
  434. Leerzeichen zwischen dem Funktionsnamen und der öffnenden Klammer für die Argumente
  435. sind nicht erlaubt.
  436. </para>
  437. <para>
  438. Von Funktionen im globalen Raum wird komplett abgeraten.
  439. </para>
  440. <para>
  441. Das folgende ist ein Beispiel einer akzeptierbaren Funktionsdeklaration in einer Klasse:
  442. <programlisting role="php"><![CDATA[
  443. /**
  444. * Dokumentations Block hier
  445. */
  446. class Foo
  447. {
  448. /**
  449. * Dokumentations Block hier
  450. */
  451. public function bar()
  452. {
  453. // gesamter Inhalt der Funktion
  454. // muss durch view Leerzeichen eingerückt sein
  455. }
  456. }
  457. ]]></programlisting>
  458. </para>
  459. <para>
  460. <emphasis>NOTIZ:</emphasis> Die Übergabe per Referenz ist die einzige erlaubt Mechanismus
  461. für die Übergabe von Parametern in der Deklaration einer Funktion:
  462. <programlisting role="php"><![CDATA[
  463. /**
  464. * Dokumentations Block hier
  465. */
  466. class Foo
  467. {
  468. /**
  469. * Dokumentations Block hier
  470. */
  471. public function bar(&$baz)
  472. {}
  473. }
  474. ]]></programlisting>
  475. </para>
  476. <para>
  477. Der Aufruf durch Referenz ist nicht gestattet.
  478. </para>
  479. <para>
  480. Der Rückgabewert darf nicht in Klammern stehen. Das kann die Lesbarkeit behindern und
  481. zusätzlich den Code unterbrechen wenn eine Methode später später auf Rückgabe durch
  482. Referenz geändert wird.
  483. <programlisting role="php"><![CDATA[
  484. /**
  485. * Dokumentations Block hier
  486. */
  487. class Foo
  488. {
  489. /**
  490. * FALSCH
  491. */
  492. public function bar()
  493. {
  494. return($this->bar);
  495. }
  496. /**
  497. * RICHTIG
  498. */
  499. public function bar()
  500. {
  501. return $this->bar;
  502. }
  503. }
  504. ]]></programlisting>
  505. </para>
  506. </sect3>
  507. <sect3 id="coding-standard.coding-style.functions-and-methods.usage">
  508. <title>Verwendung von Funktionen und Methoden</title>
  509. <para>
  510. Funktionsargumente sollten durch ein einzelnes trennendes Leerzeichen nach dem Komma
  511. Trennzeichen getrennt werden. Das folgende ist ein Beispiel für einen akzeptierbaren
  512. Aufruf einer Funktion die drei Argumente benötigt:
  513. <programlisting role="php"><![CDATA[
  514. threeArguments(1, 2, 3);
  515. ]]></programlisting>
  516. </para>
  517. <para>
  518. Übergabe von Referenzen zur Laufzeit ist strengstens verboten. Siehe die Sektion für
  519. Funktions Deklarationen für den richtigen Weg um Funktionsargumente per Referenz
  520. zu übergeben.
  521. </para>
  522. <para>
  523. Durch die Übergabe von Arrays als Argument für eine Funktion, kann der
  524. Funktionsaufruf den "array" Hinweis enthalten und kann in mehrere Zeilen geteilt werden
  525. um die Lesbarkeit zu erhöhen. In solchen Fällen sind die normalen Richtlinien für
  526. das Schreiben von Arrays trotzdem noch anzuwenden:
  527. <programlisting role="php"><![CDATA[
  528. threeArguments(array(1, 2, 3), 2, 3);
  529. threeArguments(array(1, 2, 3, 'Zend', 'Studio',
  530. $a, $b, $c,
  531. 56.44, $d, 500), 2, 3);
  532. ]]></programlisting>
  533. </para>
  534. </sect3>
  535. </sect2>
  536. <sect2 id="coding-standard.coding-style.control-statements">
  537. <title>Kontrollanweisungen</title>
  538. <sect3 id="coding-standard.coding-style.control-statements.if-else-elseif">
  539. <title>If/Else/Elseif</title>
  540. <para>
  541. Kontrollanweisungen die auf den <code>if</code> und <code>elseif</code> Konstrukten
  542. beruhen müssen ein einzelnes Leerzeichen vor der öffnenden Klammer der bedingten Anweisung
  543. und ein einzelnes Leerzeichen nach der schließenden Klammer.
  544. </para>
  545. <para>
  546. Innerhalb der bedingten Anweisungen zwischen den Klammern, müssen die Operationen, für die
  547. Lesbarkeit, durch Leerzeichen getrennt werden. Innere Klammern sind zu befürworten um
  548. die logische Gruppierung für größeren bedingte Anweisungen zu erhöhen.
  549. </para>
  550. <para>
  551. Die öffnende Klammer wird in der selben Zeile geschrieben wie die Bedingungsanweisung.
  552. Die schließende Klammer wird immer in einer eigenen Zeile geschrieben. Jeder Inhalt innerhalb
  553. der Klammer muß durch Verwendung von vier Leerzeichen eingerückt werden.
  554. <programlisting role="php"><![CDATA[
  555. if ($a != 2) {
  556. $a = 2;
  557. }
  558. ]]></programlisting>
  559. </para>
  560. <para>
  561. Für "if" Anweisungen die "elseif" oder "else" beinhalten, sind die Konventionen
  562. der Formatierung ähnlich dem "if" Konstrukt. Das folgende Beispiel zeigt gültige
  563. Formatierungen für "if" Anweisungen mit "else" und/oder "elseif" Konstrukten:
  564. <programlisting role="php"><![CDATA[
  565. if ($a != 2) {
  566. $a = 2;
  567. } else {
  568. $a = 7;
  569. }
  570. if ($a != 2) {
  571. $a = 2;
  572. } elseif ($a == 3) {
  573. $a = 4;
  574. } else {
  575. $a = 7;
  576. }
  577. ]]></programlisting>
  578. PHP erlaubt das Anweisungen in einigen Fällen auch ohne Klammern zu schreiben.
  579. Dieser Coding Standard macht keine Unterscheidungen und es müssen alle "if", "elseif" oder "else"
  580. Anweisungen in Klammern geschrieben werden.
  581. </para>
  582. <para>
  583. Die Verwendung des "elseif" Konstruktes ist erlaubt es wird aber strengstens davon abgeraten
  584. und es ist die "else if" Kombination zu bevorzugen.
  585. </para>
  586. </sect3>
  587. <sect3 id="coding-standards.coding-style.control-statements.switch">
  588. <title>Switch</title>
  589. <para>
  590. Kontrollanweisungen die mit der "switch" Anweisung geschrieben werden müssen ein einzelnes
  591. Leerzeichen vor der öffnenden Klammer der Bedingten Anweisung besitzen, und auch
  592. nach der schließenden Klammer.
  593. </para>
  594. <para>
  595. Jeglicher Inhalt innerhalb der "switch" Anweisung muß durch Verwendung von vier Leerzeichen
  596. eingerückt sein. Der Inhalt unter jeder "case" Anweisung muß durch Verwendung von vier
  597. zusätzlichen Leerzeichen eingerückt werden.
  598. </para>
  599. <programlisting role="php"><![CDATA[
  600. switch ($numPeople) {
  601. case 1:
  602. break;
  603. case 2:
  604. break;
  605. default:
  606. break;
  607. }
  608. ]]></programlisting>
  609. <para>
  610. Das <code>default</code> Konstrukt darf nie bei der <code>switch</code> Anweisung vergessen
  611. werden.
  612. </para>
  613. <para>
  614. <emphasis>NOTIZ:</emphasis> Es ist machmal nützlich eine <code>case</code> Anweisung zu
  615. schreiben, die durch das nächste case fällt indem innerhalb solcher Fälle kein
  616. <code>break</code> oder <code>return</code> angegeben wird. Um diese Fälle von Fehlern
  617. zu unterscheiden, sollte jede <code>case</code> Anweisung in der <code>break</code>
  618. oder <code>return</code> unterlassen werden einen Kommentar enthalten der anzeigt das
  619. das break gewünschtermaßen unterdrückt wurde.
  620. </para>
  621. </sect3>
  622. </sect2>
  623. <sect2 id="coding-standards.inline-documentation">
  624. <title>Inline Dokumentation</title>
  625. <sect3 id="coding-standards.inline-documentation.documentation-format">
  626. <title>Dokumentations Format</title>
  627. <para>
  628. Alle Dokumentations Blöcke ("DocBlock") müssel mit dem phpDocumentor Format kompatibel sein.
  629. Die Beschreibung des phpDocumentor Formats is jenseits der Reichweite dieses Dokuments.
  630. Für weiterführende Informationen siehe:
  631. <ulink url="http://phpdoc.org/">http://phpdoc.org"></ulink>
  632. </para>
  633. <para>
  634. Alle Klassen Dateien müssen einen "file-level" Docblock am Beginn jeder Datei und einen
  635. "class-level" Docblock direkt überhalb jeder Klasse enthalten. Beispiele solcher
  636. Docblocks können anbei gefunden werden.
  637. </para>
  638. </sect3>
  639. <sect3 id="coding-standards.inline-documentation.files">
  640. <title>Dateien</title>
  641. <para>
  642. Jede Datei die PHP Code enthält muß einen Docblock am Beginn der Datei besitzen welcher
  643. mindestens diese phpDocumentor Tags enthält:
  644. <programlisting role="php"><![CDATA[
  645. /**
  646. * Kurze Beschreibung der Datei
  647. *
  648. * Lange Beschreibung der Datei (wenn vorhanden)...
  649. *
  650. * LICENSE: Einige Lizenz Informationen
  651. *
  652. * @copyright 2008 Zend Technologies
  653. * @license http://framework.zend.com/license BSD License
  654. * @version $Id:$
  655. * @link http://framework.zend.com/package/PackageName
  656. * @since Datei vorhanden seit Release 1.2.0
  657. */
  658. ]]></programlisting>
  659. </para>
  660. </sect3>
  661. <sect3 id="coding-standards.inline-documentation.classes">
  662. <title>Klassen</title>
  663. <para>
  664. Jede Klasse muß einen Docblock haben welche mindestens diese phpDocumentor Tags enthält:
  665. <programlisting role="php"><![CDATA[
  666. /**
  667. * Kurze Beschreibung für die Klasse
  668. *
  669. * Lange Beschreibung für die Klasse (wenn vorhanden)...
  670. *
  671. * @copyright 2008 Zend Technologies
  672. * @license http://framework.zend.com/license BSD License
  673. * @version Release: @package_version@
  674. * @link http://framework.zend.com/package/PackageName
  675. * @since Klasse vorhanden seit Release 1.5.0
  676. * @deprecated Klasse abgeraten ab Release 2.0.0
  677. */
  678. ]]></programlisting>
  679. </para>
  680. </sect3>
  681. <sect3 id="coding-standards.inline-documentation.functions">
  682. <title>Funktionen</title>
  683. <para>
  684. Jede Funktion, auch Objekt Methoden, müssen einen Docblock haben welcher mindestens folgendes
  685. enthält:
  686. <itemizedlist>
  687. <listitem><para>Eine Beschreibung der Funktion</para></listitem>
  688. <listitem><para>Alle Argumente</para></listitem>
  689. <listitem><para>Alle möglichen Rückgabewerte</para></listitem>
  690. </itemizedlist>
  691. </para>
  692. <para>
  693. Es ist nicht notwendig das "@access" Tag zu verwenden, weil das Accesslevel bereits vom
  694. "public", "private" oder "protected" Modifikator bekannt ist wenn die Funktion deklariert wird.
  695. </para>
  696. <para>
  697. Wenn eine Funktion/Methode eine Ausnahme werfen könnte, muß @throws für alle bekannten
  698. Exception Klassen verwendet werden:
  699. <programlisting role="php"><![CDATA[
  700. @throws exceptionclass [Beschreibung]
  701. ]]></programlisting>
  702. </para>
  703. </sect3>
  704. </sect2>
  705. </sect1>
  706. </appendix>
  707. <!--
  708. vim:se ts=4 sw=4 et:
  709. -->