coding_standard.xml 36 KB

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