Differences

This shows you the differences between two versions of the page.

--- de:entwickler:programmierrichtlinien [2013/07/04 11:13] – [Kommentare] fasse
+++ de:entwickler:programmierrichtlinien [2024/12/02 18:21] (current) – [Kommentare] greno
@@ Line 50: / Line 50: @@
   * Wer möchte kann 1 Leerzeichen zwischen ControlKeyword (if) und der Bedingung machen, um sie von Methodenaufrufen abzugrenzen. Dies ist aber jedem selbst überlassen.
-  * auch wenn nur eine Action definiert ist immer geschweifte Klammern nutzen
+  * auch wenn nur eine Aktion definiert ist immer geschweifte Klammern nutzen
 Hier noch ein Beispiel für eine switch/case-Anweisung:
@@ Line 68: / Line 68: @@
 }</code>
+Verkürzte Schreibweisen, wie zum Beispiel die folgende If-Anweisung sollten aus Gründen der Übersichtlichkeit vermieden werden!
+<code php>(bedingung) ? action1 : action2</code>
 ===== Funktionsaufrufe =====
-Ein Funktionsaufruf geschieht immer ohne Leerzeichen zwischen dem Funktionsnamen, der öffnenden Klammer und dem ersten Übergabeparameter. Die einzelnen Parameter werden mit Komma und Leerzeichen von einander getrennt. Hinter dem letztem Parameter wird ebenfalls kein Leerzeichen mehr eingesetzt. Anbei wieder ein Beispiel:
+Ein Funktionsaufruf geschieht immer ohne Leerzeichen zwischen dem Funktionsnamen, der öffnenden Klammer und dem ersten Übergabeparameter. Die einzelnen Parameter werden mit Komma und Leerzeichen voneinander getrennt. Hinter dem letztem Parameter wird ebenfalls kein Leerzeichen mehr eingesetzt. Anbei wieder ein Beispiel:
 <code php>$var = funktion($para1, $para2, $para3);</code>
 Wie oben gezeigt steht auf der linken und rechten Seite des Gleichheitszeichen jeweils ein Leerzeichen. Wenn mehrere Funktionsaufrufe und damit Variablenzuweisungen im Block untereinander stehen, kann, um die Lesbarkeit des Codes zu gewährleisten, davon abgewichen werden:
@@ Line 85: / Line 87: @@
 ===== Kommentare =====
-Damit auch andere die eventuell vorhanden Bugs in eurem Code fixen können, muss dieser nicht nur übersichtlich, sondern auch verständlich sein. Daher ist der ein oder andere Kommentar unumgänglich. Hier ist der richtige Mittelweg zu wählen. Zu viel Kommentar verschränkt den Blick auf das wesentliche (den Code), zu wenig Kommentar lässt ihn undurchdringbar erscheinen...
+Damit auch andere die eventuell vorhanden Bugs in deinem Code fixen können, muss dieser nicht nur übersichtlich, sondern auch verständlich sein. Daher ist der eine oder andere Kommentar unumgänglich. Hier ist der richtige Mittelweg zu wählen. Zu viel Kommentar verschränkt den Blick auf das Wesentliche (den Code), zu wenig Kommentar lässt ihn undurchdringbar erscheinen...
 Kommentare sollten in der Regel in englisch erfasst werden, so dass der Sourcecode auch von nicht deutschsprachigen Entwicklern gelesen werden kann. Bei der Dokumentation von Klassen, Methoden und Funktionen verwenden wir zur Unterstützung Doxygen. Damit kann eine übersichtliche HTML-Hilfe erstellt werden. Allerdings müssen dazu ein paar Tags innerhalb des Kommentars gesetzt werden. Eine [[de:entwickler:sourcecode-dokumentation|Beschreibung zur Dokumentation mit Doxygen]] ist aber vorhanden.
@@ Line 93: / Line 95: @@
 // This is the second line of a short comment</code>
 Wie oben zu sehen ist, sollte auch in Kommentaren von Umlauten abgesehen werden. Erstreckt sich ein Kommentar über mehr als 2 Zeilen sollten Block-Kommentare eingesetzt werden:
-<code php>/*
+<code php>/* This comment could be very long ...
-*
 * This comment could be very long ...
 * This comment could be very long ...
-* This comment could be very long ...
+* This comment could be very very very long ...  */</code>
-* This comment could be very very very long ...
-*
-*/</code>
 Wichtig bei Blockkommentaren sind die * am Anfang der Zeilen. Diese sind nicht notwendig, erleichtern aber den Überblick erheblich und sollten deshalb gesetzt werden.
@@ Line 142: / Line 140: @@
 **Variablen**\\
-Variablen sollten ähnlich den Funktionsnamen im camelStyle (vielen auch als [[http://de.wikipedia.org/wiki/CamelCaps|camelCaps]] oder laOlaStyle bekannt) geschrieben werden. Globale Variablen, die systemweit gelten erhalten ein **g** als Präfix, Übergabevariablen an ein Script erhalten ein **get** bzw. **post** als Präfix, damit immer direkt klar ist, dass der Inhalt der Varialben manipuliert sein kann.\\
+Variablen sollten ähnlich den Funktionsnamen im camelStyle (vielen auch als [[http://de.wikipedia.org/wiki/CamelCaps|camelCaps]] oder laOlaStyle bekannt) geschrieben werden. Globale Variablen, die systemweit gelten erhalten ein **g** als Präfix, Übergabevariablen an ein Script erhalten ein **get** bzw. **post** als Präfix, damit immer direkt klar ist, dass der Inhalt der Variablen manipuliert sein kann.\\
 Beispiel:
 <code php>numberRows  // Varialbenbezeichnung
-gCurrentUser  // globale Varialbe
+gCurrentUser  // globale Variable
 getUserId  // Übergabevariable an ein Script</code>
 **Konstanten**\\
-Bei Konstanten werden alle Buchstaben groß geschrieben und die einlenen Worte innerhalb de Namens durch Unterstriche getrennt.\\
+Bei Konstanten werden alle Buchstaben groß geschrieben und die einzelnen Worte innerhalb de Namens durch Unterstriche getrennt.\\
 Beispiel:
@@ Line 187: / Line 185: @@
 <code php>echo '<a href="javascript: beispiel(\'uebergabe\');" target="_self">Html-Code</a>';</code>
+===== Vergleichsoperatoren =====
+Beim Vergleich des Inhalts von Variablen sollten diese so gewählt werden, dass auch der Typ (integer/string) mit geprüft wird. Dies erreicht man, indem man gleich mit **===** oder ungleich mit **!==** angibt.
+<code php>if($a == $b)  // prüft nur ob der Inhalt gleich ist. "Test" == Test   > true
+if($a === $b) // prüft ob auch der Typ gleich ist. "Test" === Test   > false
+              //                                   "Test" === "Test" > true
+if($a != $b)  // prüft nur ob der Inhalt ungleich ist. "Test" != Test2   > true
+if($a !== $b) // prüft ob auch der Typ gleich ist. "Test" !== Test   > false
+              //                                   "Test2" !== "Test" > true
+</code>