Benutzer-Werkzeuge

Webseiten-Werkzeuge


dev:all:psr

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Nächste ÜberarbeitungBeide Seiten der Revision
dev:all:psr [28.12.2018 23:40] – [Offizielle Standards] Manuela v.d.Deckendev:all:psr [20.08.2019 01:08] – [Offizielle Standards] Manuela v.d.Decken
Zeile 7: Zeile 7:
 Die wichtigsten Schlüsselworte wurden/werden nach folgendem, in RFC2119 definierten Sinn übersetzt: Die wichtigsten Schlüsselworte wurden/werden nach folgendem, in RFC2119 definierten Sinn übersetzt:
 ^englisch ^deutsch ^Erklärung | ^englisch ^deutsch ^Erklärung |
-|MUST / REQUIRED / SHALL |MUSS / ERFORDERLICH / SOLL |es ist ein absolutes Erfordernis der Spezifikation. | +|MUST /\\ REQUIRED /\\ SHALL |MUSS /\\ ERFORDERLICH /\\ SOLL |es ist ein absolutes Erfordernis der Spezifikation. | 
-|MUST NOT / SHALL NOT |DARF NICHT / SOLL NICHT |es ist ein absolutes Verbot durch die Spezifikation. | +|MUST NOT /\\ SHALL NOT |DARF NICHT /\\ SOLL NICHT |es ist ein absolutes Verbot durch die Spezifikation. | 
-|SHOULD / RECOMMENDED |SOLLTE / EMPFOHLEN |Auch das ist ein absolutes Erfordernis/Verbot. Jedoch kann es in wenigen Ausnahmefällen gute Gründe geben, diesen Punkt zu ignorieren. Dazu sollten aber die vollen Auswirkungen der Missachtung gut verstanden sein und sehr genau überlegt werden ob die Abweichung tatsächlich erforderlich ist.| +|SHOULD /\\ RECOMMENDED |SOLLTE /\\ EMPFOHLEN |Auch das ist ein absolutes Erfordernis/Verbot. Jedoch kann es in wenigen Ausnahmefällen gute Gründe geben, diesen Punkt zu ignorieren. Dazu sollten aber die vollen Auswirkungen der Missachtung gut verstanden sein und sehr genau überlegt werden ob die Abweichung tatsächlich erforderlich ist.| 
-|SHOULD NOT / NOT RECOMMENDED |SOLLTE NICHT / NICHT EMPFOHLEN |:::| +|SHOULD NOT /\\ NOT RECOMMENDED |SOLLTE NICHT /\\ NICHT EMPFOHLEN |:::| 
-|MAY / OPTIONAL |KANN / OPTIONAL |hiermit wird eine wirkliche Option bezeichnet, die sein kann aber nicht sein muss|+|MAY /\\ OPTIONAL |KANN /\\ OPTIONAL |hiermit wird eine wirkliche Option bezeichnet, die sein kann aber nicht sein muss|
  
-  * **[[dev:all:psr:psr-0|Autoloading Standard]]** - Er zielt darauf ab, ein standardisiertes Dateiformat sowie Klassennamen und Namespace Konventionen bereitzustellen, die Plug&Play Code ermöglichen. <span warning>Seit 2014-10-21 ist PSR-0 als unerwünscht markiert. PSR-4 ist jetzt als Alternative empfohlen.</span>+  * **[[dev:all:psr:psr-0|Autoloading Standard]]** - Er zielt darauf ab, ein standardisiertes Dateiformat sowie Klassennamen und Namespace Konventionen bereitzustellen, die Plug&Play Code ermöglichen. <span important>Seit 2014-10-21 ist PSR-0 als unerwünscht markiert. PSR-4 ist jetzt als Alternative empfohlen.</span>
   * **[[dev:all:psr:psr-1|Basic Coding Standard]]** - Hiermit soll ein möglichst hoher Grad an Kompatibilität von PHP-Code aus unterschiedlichen Quellen erreicht werden.    * **[[dev:all:psr:psr-1|Basic Coding Standard]]** - Hiermit soll ein möglichst hoher Grad an Kompatibilität von PHP-Code aus unterschiedlichen Quellen erreicht werden. 
   * **[[dev:all:psr:psr-2|Coding Style Guide]]** Enthält Anweisungen, die dafür sorgen, dass PHP-Code immer eine standardisierte optische Erscheinung hat.   * **[[dev:all:psr:psr-2|Coding Style Guide]]** Enthält Anweisungen, die dafür sorgen, dass PHP-Code immer eine standardisierte optische Erscheinung hat.
Zeile 20: Zeile 20:
  
 ===== Grundsätzliche Regeln zur Programmierung im WB-Umfeld ===== ===== Grundsätzliche Regeln zur Programmierung im WB-Umfeld =====
-Mit jeder weiteren Version von WebsiteBaker entfernt sich der Programmierstil immer weiter vom bisherigen, seit fast 10 Jahren gewohnten, 'anarchischen' Stil, hin zu einer immer modulareren, jedoch zwangsweise auch an strenge Schnittstellen gebundenen Programmierweise. Das wird vor allem von Addon-Programmierern ein konsequentes Umdenken erfordern.\\+Mit jeder weiteren Version von WebsiteBaker entfernt sich der Programmierstil immer weiter vom bisherigen, seit 15 Jahren gewohnten, 'anarchischen' Stil, hin zu einer immer modulareren, jedoch zwangsweise auch an strenge Schnittstellen gebundenen Programmierweise. Das wird vor allem von Addon-Programmierern ein konsequentes Umdenken erfordern.\\
 Derzeit, also __bis zur 2.10__ ist die Einhaltung vieler Regeln noch freiwillig, __in der 2.12__ wird vieles bereits deprecated und __nach der 2.12__ werden nach und nach viele der Vorgaben zwingend werden. Das alles hört sich für viele sehr einschränkend an, was aber gerne in Kauf genommen wird, da genau diese Einschränkungen letztendlich für eine stabile Modularität, für stabile Flexibilität und für Austauschbarkeit, Wiederverwendbarkeit und vor allem Wartungsfreundlichkeit von Code sorgen werden. Derzeit, also __bis zur 2.10__ ist die Einhaltung vieler Regeln noch freiwillig, __in der 2.12__ wird vieles bereits deprecated und __nach der 2.12__ werden nach und nach viele der Vorgaben zwingend werden. Das alles hört sich für viele sehr einschränkend an, was aber gerne in Kauf genommen wird, da genau diese Einschränkungen letztendlich für eine stabile Modularität, für stabile Flexibilität und für Austauschbarkeit, Wiederverwendbarkeit und vor allem Wartungsfreundlichkeit von Code sorgen werden.
  
Zeile 35: Zeile 35:
   - ... dürfen keine globalen Variablen oder globalen Konstanten definieren.   - ... dürfen keine globalen Variablen oder globalen Konstanten definieren.
   - ... dürfen **niemals** eine indirekte Adressierung verwenden oder zulassen!   - ... dürfen **niemals** eine indirekte Adressierung verwenden oder zulassen!
-  - +
 für spätere Versionen (nach 2.10.x) werden noch weitere Einschränkungen kommen. Siehe die jeweiligen Abschnitte dieser Dokumentation. für spätere Versionen (nach 2.10.x) werden noch weitere Einschränkungen kommen. Siehe die jeweiligen Abschnitte dieser Dokumentation.
  
dev/all/psr.txt · Zuletzt geändert: 21.12.2020 06:10 von Manuela v.d.Decken