• Einrückungen sollen mit Tabs und nicht mehr Leerzeichen erfolgen

public function getContextName() 
{
»   return $this->contextName;
}

Die Benennung von Methoden oder Klassen ist ein unterbewerteter Faktor in der Software Entwicklung, obwohl jeder gute und sprechende Name positiv bewerten würde. Man sollte keine Abkürzungen verwenden. Jegliche Benennung sollte in Englisch erfolgen und mit sprechenden Bezeichnungen arbeiten. Wenn Abkürzung benutzt werden, ist darauf zu achten, dass diese nicht alle Großgeschrieben werden, sondern der CamelCase Standard eingehalten wird.

Beispiel: createHtmlContent

Jeder Package Name startet mit einem Großbuchstaben und wird in UpperCamelCase geschrieben. Um Probleme mit unterschiedlichen Dateisystemen zu vermeiden, sind nur folgenden Zeichen erlaubt: [A-z],[0-9]. Sonderzeichen sind nicht erlaubt.

• Folge Zeichen sind erlaubt [A-z],[0-9]
• Namespace werden in UpperCamelCase geschrieben. Ausnahmen sind erlaubt bei üblichen Namen und Bezeichnungen.

Alle Methodennamen werden in lowerCamelCase geschrieben. Es dürfen nur die Buchstaben [A-z],[0-9] verwendet werden. Methodennamen sollte aussagekräftig und gleichzeitig klein und präzise sein. Konstruktoren müssen immer wie folgt benannt werden "__construct(). Verwenden Sie niemals den Klassennamen. Korrekte Methodennamen:

• myMethod()
• someNiceMethodName()
• betterWriteLongMethodNamesThanNamesNobodyUnderstands()
• singYmcaLoudly()
• __construct()

Variablen werden in lowerCamelCase geschrieben und sollten:

• selbsterklärend sein
• lieber länger wenn die Bedeutung dadurch eindeutiger wird

Korrekte Variablennamen:

• $singletonObjectsRegistry
• $argumentsArray
• $aLotOfHTMLCode

Inkorrekte Variablennamen:

• $sObjRgstry
• $argArr
• $cx
• $x,$y

Sonderfälle sind Zählervariablen wie z.B. $i, $j, $k... Man sollte trotzdem versuchen diese wenn Möglich zu vermeiden.

Werden ausschließlich in Großbuchstaben geschrieben. Unterstriche können verwendet werden um Konstanten thematisch zu gruppieren. Korrekte Konstanten:

• STUFF_LEVEL
• COOLNESS_FACTOR
• PATTERN_MATCH_EMAILADDRESS
• PATTERN_MATCH_VALIDHTMLTAGS

Nebenbei ist es sinnvoll reguläre Ausdrücke in Konstanten zu speichern statt irgendwo im Code.

• Jede Datei ist UpperCamelCase
• Dateien für Klassen und Interfaces werden wie die Klassen und Interfaces benannt.
• Jede Datei darf nur eine Klasse oder Interface besitzen.
• Dateien für Unittests werden wie die Referenz Klasse bezeichnet mit dem Suffix "Test.php".
• Dateien werden in die Ordnerstruktur hinterlegt, die dem Namespace entspricht.

Literals:

$vision = 'enter vision here';

Concatenate Strings

$message = 'Hi' . $name . ', you look ' . $look . ' today';

if ($something || $somethingElse) {
   doThis();
} else {
   doSomethingElse();
}

   // one liners - exception for throw statements!
if (allGoesWrong() === TRUE) throw new \Exception('Hey, all went wrong!', 123);

if (weHaveALotOfCriteria() === TRUE
   && notEverythingFitsIntoOneLine() === TRUE
   || youJustTendToLikeIt() === TRUE) {
      doThis();

} else {
   ...
}

switch ($something) {
   case FOO:
      $this->handleFoo();
   break;
   case BAR:
      $this->handleBar();
   break;
   default:
      $this->handleDefault();
}

Zusammenfassend: Bevor ein Feature oder ein Fix entwickelt wird, wird vorher ein Unittest geschrieben. Bevor Features committed werden, sollten alle Unit-Tests erfolgreich durchgelaufen sein.

Damit die Historie übersichtlich bleibt, sind gute Commit Kommentare unabdingbar.

Kein Commit ohne Kommentar

• Die erste Zeile sollte eine kurze Beschreibung der durchgeführten Änderung sein.

• [!!!] Wenn nach dem Update eine händisch Anpassung gemacht werden muss, sollte der Commit zu Anfang mit [!!!] gekennzeichnet werden.

Hier sollten dann noch die Schritte beschreiben werden, die nötig sind, damit nach dem Update ein funktionierender Stand zur Verfügung steht. Weitere Prefixes sind selbst erklärend:

• [FEATURE]
• [BUGFIX]
• [API]
• [Configuration] Wenn Standardwerte in den Einstellungen z.B. verändert wurden.
• [TASK] Was nicht den oberen Kategorien entspricht z.B. coding style cleanup etc.

Zum Schluss wird je nach Typ auf die Ticketnummer referenziert z.B.

• Resolves: #123
• Resolves: #456
• Relates to: #789

Beispiel:

[~TASK] Shopware (MVC): Short (50 chars or less) summary of changes

More detailed explanatory text.  Wrap it to about 72

You can treat the firstlin as the subject of an email 
and the rest of the text as the body.

Write your commit message in the present tense: "Fix bug" and not "Fixed
bug." 

Further paragraphs come after blank lines.

* Bullet points are okay, too
* An asterisk is used for the bullet, it can be preceded by a single
  space. This format is rendered correctly by Forge (redmine)
* Use a hanging indent

Resolves: #123
Resolves: #456
Relates to: #789

Dokumentations-Beispiele:

Klasse:

 /**
 * First sentence is a short description. Then you can write more, just as you like
 * Here may follow some detailed description about what the class is doing.
 *
 * Extends the Basic Enlight_Class
 *
 * @author John Doe
 * @author $Author$
 * @package Shopware
 * @subpackage Controllers_Frontend
 * @copyright Copyright (c) 2011, shopware AG
 * @since 3.5.0 - 2010/12/06
 * @version 4.0.0-SVN$Id$
 */
class Shopware_Controllers_Frontend_Account extends Enlight_Controller_Action implements Enlight_Controller_Hook
{
 ...
}

Interface:

/**
 * First sentence is short description. Then you can write more, just as you like
 *
 * Here may follow some detailed description about what the interface is for.
 *
 * Paragraphs are seperated by a empty line.
 *
 * [annotations see above]
 */
/**
 * First sentence is a short description. Then you can write more, just as you like
 * Here may follow some detailed description about what the class is doing.
 * [annotations see above]
 */
interface SomeInterface 
{
 ...
}

Exception:

/**
 * First sentence is short description. Then you can write more, just as you like
 *
 * Here may follow some detailed description about what the exception is for.
 *
 * Paragraphs are seperated by a empty line.
 * [annotations see above]
 */
class SomeException extends Exception 
{
 ...
}

Methode:

/**
 * A description for this method
 *
 * Paragraphs are seperated by a empty line.
 *
 * @author John Doe
 * @author $Author$
 * @copyright Copyright (c) 2011, shopware AG
 * @param \Shopware\Controller\Post $post A post
 * @param string $someString This parameter should contain some string
 * @return void
public function addStringToPost(\Shopware\Controller\Post $post, $someString) 
{
 ...
}

Testcase:

/**
 * @test
 */
public function fooReturnsBarForQuux() 
{
 ...
}

Public API:

/**
 * This method is part of the public API.
 *
 * @return void
 * @api
 */
public function fooBar() 
{
 ...
}

Liste der Dokumentations- Annotationen:

Interface Documentation

• @author
• @api
• @package
• @subpackage
• @copyright
• @since
• @deprecated
• @version

Class Documentation

• @author
• @api
• @package
• @subpackage
• @copyright
• @since
• @deprecated
• @version

Property Documentation

• @var
• @api
• @since
• @deprecated

Constructor Documentation

• @param
• @throws
• @author
• @api
• @since
• @deprecated

Method Documentation

• @param
• @return
• @throws
• @author
• @api
• @since
• @deprecated

Testscase Documentation

• @test
• @author

=Best Practices= Beispiel von guten und bösen Vergleichsoperationen

if ($template)             // BAD
if (isset($template))      // GOOD
if ($template !== NULL))   // GOOD
if ($template !== ''))     // GOOD

if (strlen($template) > 0) // BAD! strlen("-1") is greater than 0
if (is_string($template) && strlen($template) >0) // BETTER

if ($foo == $bar)          // BAD, avoid truthy comparisons
if ($foo != $bar)          // BAD, avoid falsy comparisons
if ($foo === $bar))        // GOOD
if ($foo !== $bar))        // GOOD

Bad coding smell

   // We only allow valid persons
if (is_object($p) && strlen($p->lastN) > 0 && $p->hidden === FALSE && ↩
  $this->environment->moonPhase === MOON_LIB::CRESCENT) 
  {
   $xmM = $thd;
}

Smells better

if ($this->isValidPerson($person) {
   $xmM = $thd;
}