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>
