# Coding Standards für Plugins (Controller, Models, ...)

**URL:** <https://forum.shopware.com/t/coding-standards-fur-plugins-controller-models/28561>\
**Category:** Programmierung\
**Created:** [1. Juli 2015 um 09:18 UTC](https://forum.shopware.com/t/coding-standards-fur-plugins-controller-models/28561 "2015-07-01T09:18:06Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![arsin](https://avatars.discourse-cdn.com/v4/letter/a/d9b06d/32.png) [@arsin](https://forum.shopware.com/u/arsin)\
**Post date:** [1. Juli 2015 um 09:18 UTC](https://forum.shopware.com/t/coding-standards-fur-plugins-controller-models/28561/1 "2015-07-01T09:18:06Z")

</div>

Hi zusammen, Achtung: wir sind total zufrieden mit der Erweiterbarkeit und mit Shopware insgesamt. Uns fällt durch unser CI und durch die generierten Quality Reports nur immer wieder auf, dass Shopware an ein paar Stellen anders tickt, als es der PHP-Standard und die von Shopware selbst ausgegebenen [Coding Standards](http://community.shopware.com/Shopware-Coding-Standards%5C_detail%5C_661.html#Naming) empfehlen. So werden beispielsweise Controller-Namen wie folgt gefordert: ` class Shopware\_Controllers\_Frontend\_MyControllerName extends Enlight\_Controller\_Action { //... } ` Kein Namespace (und logischerweise kein korrespondierendes Directory), Underscores (\_) - so nicht optimal. Warum dass gefordert wird ist nachvollziehbar - im Default-Dispatcher wird die Klasse zum Controller “hart” verdrahtet: ` public function getControllerClass(Enlight\_Controller\_Request\_Request $request) { if (!$request-\>getControllerName()) { $request-\>setControllerName($this-\>defaultController); } if (!$request-\>getModuleName()) { $request-\>setModuleName($this-\>defaultModule); } $module = $request-\>getModuleName(); $this-\>curModule = $module; $this-\>curDirectory = $this-\>getControllerDirectory($module); $moduleName = $this-\>formatModuleName($module); $controllerName = $this-\>formatControllerName($request-\>getControllerName()); $class = array(Enlight\_Application::Instance()-\>App(), 'Controllers', $moduleName, $controllerName); $class = implode('\_', $class); return $class; } ` Interessant wäre, was passiert, wenn es aus zwei Plugins zwei Controller mit selbem Namen gibt. Da kein Namespace im Spiel ist, dürfte das kompliziert werden. Anderes Beispiel: Bei [Backend-Plugins](http://community.shopware.com/Shopware-Backend-Komponenten-Basics%5C_detail%5C_1402%5C_871.html) wird für Models gefordert, dass diese in einem Namespace “CustomModels” liegen, das Verzeichnis soll aber “Models” heißen. Auch dies geht nicht mit den Shopware-Coding-Stanards konform. Mir ist sehr wohl klar, dass das keine dringlichen Probleme sind sondern höchstens Schönheitsfehler. Im Sinne von Stringenz und Einheitlichkeit könnte man ja mittelfristig drüber nachdenken.

---

<div class="post-metadata">

**Author:** ![Benjamin\_Cremer](https://avatars.discourse-cdn.com/v4/letter/b/a8b319/32.png) [@Benjamin\_Cremer](https://forum.shopware.com/u/Benjamin_Cremer)\
**Post date:** [1. Juli 2015 um 15:30 UTC](https://forum.shopware.com/t/coding-standards-fur-plugins-controller-models/28561/2 "2015-07-01T15:30:45Z")

</div>

Hallo, im großen und ganzen kann ich dir da völlig Recht geben. Wir versuchen uns so weit wie möglich an die etablierten Coding Style Standards [PSR-1](http://www.php-fig.org/psr/psr-1/) sowie [PSR-2](http://www.php-fig.org/psr/psr-2/) zu halten. Aus “historischen” / pre PHP 5.3 Gründen haben die alten Klassen noch keine Namespaces und halten sich nicht immer an die modernen Coding Styles. Aus Gründen der Rückwärtskompatibilität ist es nicht immer leicht Klassen umzubenennen. Neuer Code den wir schreiben folgt allerdings fast immer diesen neuen Coding Styles. Siehe dazu z.B die neuen Bundles: [https://github.com/shopware/shopware/tr … are/Bundle](https://github.com/shopware/shopware/tree/5.1/engine/Shopware/Bundle) Zur gegebener Zeit werden wir natürlich auch diese alten Klassen/Controller überarbeiten und durch aktuelle Namensschema sowie Coding Styles ersetzen. Viele Grüße, Benjamin Cremer :shopware: