tom Sat Aug 18 05:41:27 2001 EDT
Modified files:
/phpdoc/de/pear standards.xml
Log:
implemented last en-changes
Index: phpdoc/de/pear/standards.xml
diff -u phpdoc/de/pear/standards.xml:1.2 phpdoc/de/pear/standards.xml:1.3
--- phpdoc/de/pear/standards.xml:1.2 Mon May 21 15:28:36 2001
+++ phpdoc/de/pear/standards.xml Sat Aug 18 05:41:27 2001
@@ -1,3 +1,4 @@
+<!-- EN-Revision: 1.10 Maintainer: tom Status: ready -->
<chapter id="pear.standards">
<title>PEAR Codierstandards</title>
<note>
@@ -21,10 +22,10 @@
(setq tab-width 4
c-basic-offset 4
c-hanging-comment-ender-p nil
- indent-tabs-mode
- (not
- (and (string-match "/\\(PEAR\\|pear\\)/" (buffer-file-name))
- (string-match "\.php$" (buffer-file-name))))))
+ indent-tabs-mode
+ (not
+ (and (string-match "/\\(PEAR\\|pear\\)/" (buffer-file-name))
+ (string-match "\.php$" (buffer-file-name))))))
</programlisting>
</para>
<para>Hier sind die vim rules f�r das gleiche Problem:
@@ -53,8 +54,8 @@
</para>
<simpara>
Kontrollstrukturen sollten ein Leerzeichen zwischen dem Schl�sselwort
- und der �ffnenden Klammer haben, um sie von Funktionsaufrufenbesser zu
- unterscheiden.
+ und der �ffnenden Klammer haben, um sie von Funktionsaufrufen besser
+ zu unterscheiden.
</simpara>
<simpara>
Sie sollten immer geschweifte Klammern benutzen auch wenn sie in
@@ -112,7 +113,7 @@
<sect1 id="pear.standards.funcdef">
<title>Funktionsdefinitionen</title>
<para>
- Funktionsdeklarationen folgen der "eine entsprechnde Klammer" Konvention:
+ Funktionsdeklarationen folgen der "eine entsprechende Klammer" Konvention:
<programlisting role="php">
function fooFunction($arg1, $arg2 = '')
{
@@ -158,7 +159,7 @@
Weitere Kommentare, welche nicht der Klassendokumentation dienen, werden
nachdr�cklich empfohlen. Eine generelle Faustregel ist: Wenn Sie auf ein
St�ck Code blicken und denken "Wow, ich m�chte das nicht versuchen und
- beschreiben", da� Sie es auf jeden Fall kommentieren sollten, bevor Sie
+ beschreiben", dass Sie es auf jeden Fall kommentieren sollten, bevor Sie
vergessen, wie es funktioniert.
</para>
<para>
@@ -173,7 +174,7 @@
Verwenden Sie �berall dort, wo Sie bedingungslos eine Klassendatei
einf�gen <function>require_once</function>. Wenn Sie eine Klassendatei
bedingt einf�gen wollen (z.B. Fabrikmethoden) verwenden Sie
- <function>include_once</function>. Beide Anweisungen stellen sicher, da�
+ <function>include_once</function>. Beide Anweisungen stellen sicher, dass
die einzuf�gende Datei nur einmal eingef�gt wird. Sie benutzen die selbe
Dateiliste, weshalb Sie sich keine Sorgen �ber deren gleichzeitige
Benutzung machen brauchen - alle mittels <function>require_once</function>
@@ -249,11 +250,15 @@
<sect1 id="pear.standards.cvstags">
<title>CVS Tags</title>
+ <simpara>
+ Dieses Kapitel betrifft nur Pakete, welche CVS auf cvs.php.net verwenden.
+ </simpara>
<para>
- F�gen Sie den $Id$ CVS Tag in jede Datei ein. Wenn Sie
- eine Datei editieren und dieser Tag noch nicht vorhanden ist, f�gen Sie
- ihn bitte hinzu (oder ersetzen Sie bereits vorhandene Formen wie "Last
- Modified:", etc.).
+ F�gen Sie das $Id$ CVS Schl�sselwort in jede Datei ein.
+ Wenn Sie eine Datei editieren und dieses Schl�sselwort noch nicht
+ vorhanden ist, f�gen Sie es bitte hinzu (oder ersetzen Sie bereits
+ vorhandene Formen wie "Last Modified:", etc.).
+<!--
<note>
<simpara>
Wir haben einen speziellen $Horde Tag in Horde CVS, um unsere
@@ -263,6 +268,85 @@
verwaltet werden, etc.
</simpara>
</note>
+-->
+ </para>
+ <para>
+ Der Rest dieses Kapitels setzt ein Grundwissen �ber CVS Tags
+ und Branches voraus.
+ </para>
+ <para>
+ CVS Tags werden benutzt, um zu kennzeichnen, welche Revision
+ der Dateien zu einem bestimmten Release geh�ren. Die folgende
+ Liste beschreibt die ben�tigten bzw. vorgeschlagenen CVS Tags:
+
+ <variablelist>
+ <varlistentry>
+ <term>RELEASE_<replaceable>n_n</replaceable></term>
+ <listitem>
+ <simpara>
+ (ben�tigt) Wird verwendet, um ein Release zu kennzeichnen. Wenn Sie
+ es nicht verwenden, k�nnen Sie sp�ter nicht mehr zur�ckgehen, und Ihr
+ Paket, wie es zum Zeitpunkt dieses Releases war, vom CVS Server holen.
+ </simpara>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>QA_<replaceable>n_n</replaceable></term>
+ <listitem>
+ <simpara>
+ (branch, optional) Wenn Sie vor einem Release einen Release Candidate
+ herausbringen m�chten, empfiehlt sich die Erstellung eines Branches. So
+ k�nnen Sie das Release isolieren, und vor dem endg�ltigen Release nur
+ mehr Fixes von kritischen Fehler einspielen, w�hrend im Hauptzweig die
+ normale Entwicklung weitergef�hrt wird.
+ </simpara>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>MAINT_<replaceable>n_n</replaceable></term>
+ <listitem>
+ <simpara>
+ (branch, optional) Wenn Sie "Micro-Releases" (z.B. 1.2.1, usw. nach
+ 1.2), k�nnen Sie auch f�r diese einen Branch erstellen, wenn im
+ Hauptzweig starke Aktivit�ten sind, und Sie nur kleinere �nderungen
+ zwischen den "Micro-Releases" durchf�hren m�chten.
+ </simpara>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ Es wird nur der RELEASE Tag ben�tigt, der Rest wird entsprechend
+ Ihren Bed�rfnissen empfohlen.
+ </para>
+ <para>
+ Folgendes Beispiel zeigt, wie man das Release 1.2 des "Money_Fast"
+ Paketes kennzeichnet:
+ <informalexample>
+ <screen><prompt>$ </prompt><command>cd pear/Money_Fast</command>
+<prompt>$ </prompt><command>cvs tag RELEASE_1_2</command>
+<computeroutput>T Fast.php
+T README
+T package.xml
+</computeroutput>
+</screen>
+ </informalexample>
+ Damit machen Sie es der Pear Webseite m�glich, Sie durch den Rest
+ Ihres Release Prozesses zu f�hren.
+ </para>
+ <para>
+ Hier ein Beispiel, wie man einen QA Branch erstellt:
+ <informalexample>
+ <screen><prompt>$ </prompt><command>cvs tag QA_2_0_BP</command>
+...
+<prompt>$ </prompt><command>cvs rtag -b -r QA_2_0_BP QA_2_0</command>
+<prompt>$ </prompt><command>cvs update -r QA_2_0</command>
+<prompt>$ </prompt><command>cvs tag RELEASE_2_0RC1</command>
+...und dann das aktuelle Release des selben Zweigs:
+<prompt>$ </prompt><command>cvs tag RELEASE_2_0</command>
+</screen>
+ </informalexample>
+ Der "QA_2_0_BP" Tag ist ein "branch point" Tag, sprich der Ausgangspunkt
+ des Tags. Es wird empfohlen, immer einen CVS branch von solchen
+ Branch Points aus zu beginnen.
</para>
</sect1>
@@ -273,16 +357,70 @@
</para>
</sect1>
- <sect1 id="pear.standards.constants">
- <title>Konstanten benennen</title>
- <para>
- Konstanten sollten immer in Gro�buchstaben benannt werden, und die
- Worttrennung sollte mit Unterstrichen erfolgen. Geben Sie als Pr�fix
- zum Konstantennamen den Namen der Klasse bzw. des Paketes an, in
- welcher die Konstante benutzt wird. Zum Beispiel beginnen alle
- Konstanten, welche von dem <literal>DB::</literal> - Paket benutzt
- werden, mit "<literal>DB_</literal>".
- </para>
+ <sect1 id="pear.standards.naming">
+ <title>Namenskonventionen</title>
+ <sect2>
+ <title>Funktionen und Methoden</title>
+ <para>
+ Funktionen und Methoden sollten unter Verwendung des "studly caps"
+ Stils (auch bekannt als "bumpy case" oder "camel caps") benannt werden.
+ Funktionsnamen sollten zus�tzlich den Paketnamen als Pr�fix enthalten,
+ um Kollisionen zwischen den Paketen zu vermeiden. Der Anfangsbuchstabe
+ des Namens (nach dem Pr�fix) ist in Kleinbuchstaben, und jeder
+ Anfangsbuchstabe eines neuen "Wortes" in Gro�buchstaben. Ein paar
+ Beispiele:
+ <informaltable>
+ <tgroup cols="3">
+ <tbody>
+ <row>
+ <entry><simpara>connect()</simpara></entry>
+ <entry><simpara>getData()</simpara></entry>
+ <entry><simpara>buildSomeWidget()</simpara></entry>
+ <entry><simpara>XML_RPC_serializeData()</simpara></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
+ <para>
+ Private Class Members (Klassenmitgieder, welche nur von innerhalb der
+ Klasse aus, in der sie deklariert sind, benutzt werden sollen; PHP
+ unterst�tzt derzeit noch keine "truly-enforceable" privaten
+ Namensbereichen) beginnen mit einem einzelnen Unterstrich. Zum
+ Beispiel:
+ <informaltable>
+ <tgroup cols="3">
+ <tbody>
+ <row>
+ <entry><simpara>_sort()</simpara></entry>
+ <entry><simpara>_initTree()</simpara></entry>
+ <entry><simpara>$this->_status</simpara></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
+ </sect2>
+ <sect2>
+ <title>Konstanten</title>
+ <para>
+ Konstanten sollten immer in Gro�buchstaben benannt werden, und die
+ Worttrennung sollte mit Unterstrichen erfolgen. Geben Sie als Pr�fix
+ zum Konstantennamen den Namen der Klasse bzw. des Paketes an, in
+ welcher die Konstante benutzt wird. Zum Beispiel beginnen alle
+ Konstanten, welche von dem <literal>DB::</literal> - Paket benutzt
+ werden, mit "<literal>DB_</literal>".
+ </para>
+ </sect2>
+ <sect2>
+ <title>Globale Variablen</title>
+ <para>
+ Wenn Sie in Ihrem Paket globale Variablen definieren m�ssen, sollte
+ deren Name mit einem einzelnen Unterstrich, dem Paketnamen, und einem
+ weiteren Unterstrich beginnen. Zum Beispiel benutzt das PEAR Paket
+ eine globale Variable namens $_PEAR_destructor_object_list.
+ </para>
+ </sect2>
</sect1>
</chapter>
