PSR-2-Refactoring

Hier geht es um die Programmierung von Opencaching.de - User mit Erfahrungen im Bereich PHP, MySQL, HTML, JavaScript, CSS werden hier ständig gesucht
following

Ich verlagere diese Diskussion mal ins öffentliche Forum, weil hier sicher noch der eine oder andere PHP-Entwickler mitliest den es interessieren könnte.

In der OC-Entwicklung soll PSR-2 eingeführt werden. Die Entwickler des polnischen OC-Forks (Opencaching Polen, USA, Niederlande, Rumänien) haben schon damit begonnen und überarbeiten ihren Code Stück für Stück.

Die Frage ist nun, wie wir bei Opencaching.de vorgehen. Ideal wäre eine automatische Umstellung in einem Schritt - erspart viel Handarbeit, und erleichtert die weitere Prüfung von Codebeiträgen (Diffs).

teiling88 hat das Tool psr-cs-fixer getestet und damit die OC-Codestruktur testweise auf PSR-2 umgestellt; hier ist das Ergebnis: Diff, kompletter Code.

Ich hab daraus mal eine beliebige Quelltextdatei rausgepickt und stieß auf Folgendes:

Code: Alles auswählen

    } elseif (isset($_REQUEST['assign']) && $rid > 0 &&
            ($adminid == 0 || ($adminid != $login->userid && $age >= 14))) {
        sql("UPDATE `cache_reports` SET `status`=2, `adminid`=&2 WHERE `id`=&1", $rid, $login->userid);
        $tpl->redirect('adminreports.php?id='.$rid);
    } elseif (isset($_REQUEST['contact']) && $ownerid > 0) {
        $wp_oc = sql_value("SELECT `wp_oc` FROM `caches` WHERE `cache_id`='&1'", '', $cacheid);
        $tpl->redirect('mailto.php?userid=' . urlencode($ownerid) . '&wp=' . $wp_oc);
    } elseif (isset($_REQUEST['contact_reporter']) && $reporterid > 0) {
        $tpl->redirect('mailto.php?userid=' . urlencode($reporterid) . '&reportid=' . $rid);
    } elseif (isset($_REQUEST['done']) && $adminid == $login->userid) {
        sql("UPDATE `cache_reports` SET `status`=3 WHERE `id`=&1", $rid);
        $tpl->redirect('adminreports.php?id='.$rid);
    } elseif (isset($_REQUEST['assign']) && ($adminid == 0 || $adminid != $login->userid)) {
Der Originalcode vor PSR-2-Refactoring sah so aus ...

Code: Alles auswählen

    elseif (isset($_REQUEST['assign']) && $rid > 0 &&
            ($adminid == 0 || ($adminid != $login->userid && $age >= 14))) 
    {
        sql("UPDATE `cache_reports` SET `status`=2, `adminid`=&2 WHERE `id`=&1", $rid, $login->userid);
        $tpl->redirect('adminreports.php?id='.$rid);
    }
    elseif (isset($_REQUEST['contact']) && $ownerid > 0)
    {
        $wp_oc = sql_value("SELECT `wp_oc` FROM `caches` WHERE `cache_id`='&1'", '', $cacheid);
        $tpl->redirect('mailto.php?userid=' . urlencode($ownerid) . '&wp=' . $wp_oc);
    }
    elseif (isset($_REQUEST['contact_reporter']) && $reporterid > 0)
    {
        $tpl->redirect('mailto.php?userid=' . urlencode($reporterid) . '&reportid=' . $rid);
    }
    elseif (isset($_REQUEST['done']) && $adminid == $login->userid)
    {
        sql("UPDATE `cache_reports` SET `status`=3 WHERE `id`=&1", $rid);
        $tpl->redirect('adminreports.php?id='.$rid);
    }
    elseif (isset($_REQUEST['assign']) && ($adminid == 0 || $adminid != $login->userid))
was ich für wesentlich lesbarer halte, auch wenn man Syntax Highlighting verwendet. Generell ist mein Eindruck, dass die Klammerregeln für Kontrollstrukturen im PSR-2-Standard zu pauschal sind und die Codelesbarkeit teilweise verschlechtern. Dies spricht aus meiner Sicht gegen eine 100%ige PSR-2-Einführung; ich würde die Klammerung von Kontrollstrukturen gerne undogmatisch handhaben und Abweichungen ermöglichen.

teiling88 gibt zu bedenken, dass man dann keine Entwicklungstools (z.B. diverse phpStorm-Plugins) zur Prüfung der PSR-2-Konformität mehr verwenden kann, weil sie 100% PSR-2 voraussetzen.

Nun ist die Frage wie wir weiter vorgehen, und es sind Meinungen gefragt.

Was ich mir vorstellen könnte: Wir stellen - soweit möglich - automatisch auf PSR-2 um, aber schreiben uns dazu ein eigenes Tool (PHP-Script) das weniger streng bei den Kontrollstruktur-Klammern ist. Halte ich vom Aufwand her für vertretbar. Dieses Tool steht dann jedem Entwickler zur Verfügung - man lässt es einfach über seinen Code drüberlaufen und hat PSR-2 a la Opencaching.de. Dann müsste man eigentlich ohne Dritttools auskommen, die 100% PSR-2 benötigen - oder?
Zuletzt geändert von following am 28.03.2016, 23:17, insgesamt 1-mal geändert.
Benutzeravatar
4_Vs
Vereinsmitglied
Vereinsmitglied
Beiträge: 3150
Registriert: 18.03.2012, 07:25

Hiho,

ich habe keine Ahnung vom Programmieren, aber ich weiß, was ein Standard ist ... demzufolge erübrigt sich eigentlich die Diskussion.

HPE (HP, Compaq, Digital) setzt seit mehr als 75 Jahren auf einen Standard und ist damit zum größten Anbieter von Serverhardware in RZs geworden. Mit einem Marktanteil von knapp 48% ... ein Grund dafür sind Standards, und nicht "beinahe"-Standards.

Sicher hat ein Standard auch Schattenseiten, aber die gehören halt dazu.

Ich denke das ist reine Gewohnheit ... vllt. noch ein Beispiel aus dem Privaten. Ich habe früher immer die "einfacheren" Gitarrenakkorde gelernt, weil sie auf den ersten Blick schneller gelangen und genauso klingen ... also wo ist der Fehler? :)

Wenn man nicht über Lagerfeuerromantik rauskommen will, gibt es keinen Fehler ... wenn man aber auch mal komplexere Stücke spielen möchte, kam man schnell an die Grenzen, denn jetzt fehlte mir auf einmal mein Zeigefinger für die ganzen Barré-Griffe ... das heißt, ich musste alle "non"-Barré-Griffe neu lernen :(

Also, Standard ist IMHO gut, auch wenn man sich vielleicht umstellen muss und es am Anfang ein wenig "hakelt" :)
Whenever I try to plan something, it doesn't seems to work out. So why plan, it only leads to disappointment! (Eddie van Halen)
following

[quote="following"]
teiling88 hat das Tool psr-cs-fixer getestet und damit die OC-Codestruktur testweise auf PSR-2 umgestellt; hier ist das Ergebnis: Diff, kompletter Code.
[/quote]

100% PSR-2 ist das übrigens noch nicht, z.B. viele Klassen- und Funktionsnamen sind z.B. nicht PSR2-konform. Vielleicht wäre das auch zu komplex für eine automatische Umstellung.
Benutzeravatar
Slini11
Vereinsmitglied
Vereinsmitglied
Beiträge: 1164
Registriert: 17.03.2012, 13:25

Mir ist es grundsetzlich egal, was wir für Code-Struktur-Regeln benutzten. Ich pass mich da an.

Bzgl. der Übersichtlichkeit:
Problem ist ganz einfach, dass keine Leerzeilen dazwischen sind, die durch die andere Klammerstruktur vorher vorhanden waren.
So wäre das sicherlich um einiges lesbarer....

Code: Alles auswählen

 
    } elseif (isset($_REQUEST['assign']) && $rid > 0 &&
            ($adminid == 0 || ($adminid != $login->userid && $age >= 14))) {

        sql("UPDATE `cache_reports` SET `status`=2, `adminid`=&2 WHERE `id`=&1", $rid, $login->userid);
        $tpl->redirect('adminreports.php?id='.$rid);

    } elseif (isset($_REQUEST['contact']) && $ownerid > 0) {

        $wp_oc = sql_value("SELECT `wp_oc` FROM `caches` WHERE `cache_id`='&1'", '', $cacheid);
        $tpl->redirect('mailto.php?userid=' . urlencode($ownerid) . '&wp=' . $wp_oc);

    } elseif (isset($_REQUEST['contact_reporter']) && $reporterid > 0) {

        $tpl->redirect('mailto.php?userid=' . urlencode($reporterid) . '&reportid=' . $rid);

    } elseif (isset($_REQUEST['done']) && $adminid == $login->userid) {

        sql("UPDATE `cache_reports` SET `status`=3 WHERE `id`=&1", $rid);
        $tpl->redirect('adminreports.php?id='.$rid);

    } elseif (isset($_REQUEST['assign']) && ($adminid == 0 || $adminid != $login->userid)) {
Das ist aber wohl ein Extrembeispiel, oder?

Verglichen finde ich den alten Code auch ein wenig übersichtlicher. Aber wenn es einen Standart gibt, sollte man ihn auch komplett umsetzten.
Irgendwann gewöhnt man sich dran; ist mit allem so.
[url=http://www.opencaching.de/viewprofile.php?userid=159941][img]http://www.opencaching.de/statpics/DE/159941.jpg[/img][/url]
Samsung1

[quote="following"]
Was ich mir vorstellen könnte: Wir stellen - soweit möglich - automatisch auf PSR-2 um, aber schreiben uns dazu ein eigenes Tool (PHP-Script) das weniger streng bei den Kontrollstruktur-Klammern ist.
[/quote]

Würde es da nicht auch ein existierender Code Beautifier tun? Da gibt's doch sicher auch schon was fertiges für PHP :).
following

4_Vs hat geschrieben: HPE (HP, Compaq, Digital) setzt seit mehr als 75 Jahren auf einen Standard und ist damit zum größten Anbieter von Serverhardware in RZs geworden. Mit einem Marktanteil von knapp 48% ... ein Grund dafür sind Standards, und nicht "beinahe"-Standards.
.. darunter viele selbst (mit)entwickelte Standards, nehme ich an. Viele Marktführer sind heute deshalb Marktführer, weil sie sich nicht um Konventionen geschert haben sondern selbst gedacht. Man sehe sich nur die sehr eigenen Google-Coding-Styles an.
Slini11 hat geschrieben: Das ist aber wohl ein Extrembeispiel, oder?
War die erste Codedatei die ich mir angeschaut habe. Es gibt weitere solche Fälle, aber nicht soo viele, ja. Auf der anderen Seite werden Listen mit Einzeiler-ifs und -cases schwer aufgebläht.

Code: Alles auswählen

 
    } elseif (isset($_REQUEST['assign']) && $rid > 0 &&
            ($adminid == 0 || ($adminid != $login->userid && $age >= 14))) {

        sql("UPDATE `cache_reports` SET `status`=2, `adminid`=&2 WHERE `id`=&1", $rid, $login->userid);
        $tpl->redirect('adminreports.php?id='.$rid);

    } elseif (isset($_REQUEST['contact']) && $ownerid > 0) {

        $wp_oc = sql_value("SELECT `wp_oc` FROM `caches` WHERE `cache_id`='&1'", '', $cacheid);
        $tpl->redirect('mailto.php?userid=' . urlencode($ownerid) . '&wp=' . $wp_oc);

    } elseif (isset($_REQUEST['contact_reporter']) && $reporterid > 0) {

        $tpl->redirect('mailto.php?userid=' . urlencode($reporterid) . '&reportid=' . $rid);

    } elseif (isset($_REQUEST['done']) && $adminid == $login->userid) {

        sql("UPDATE `cache_reports` SET `status`=3 WHERE `id`=&1", $rid);
        $tpl->redirect('adminreports.php?id='.$rid);

    } elseif (isset($_REQUEST['assign']) && ($adminid == 0 || $adminid != $login->userid)) {
Das ist mal ne originelle Idee. :) Erinnert etwas an antike Sprachen wie Fortran und Cobol, wo Blöcke lose in der Gegend stehen und durch Einrückung gebildet werden. Aber man könnte sich sicher dran gewöhnen, ja.
following

Opencaching hat sich bei der Definition von "Geocache" nicht nach dem Marktführer gerichtet, Opencaching ist bei der Codelizenz einen eigenen Weg gegangen und bei der Datenlizenz. In keinem der Fälle wurde einfach nur ein vorgegebener Standard übernommen, sondern man hat sich jedesmal eigene Gedanken gemacht und etwas für den eigenen Bedarf verbessert.

Schaut euch mal das hier an. Alles bedeutende PHP-Projekte, die sich eigene Style Guides definiert haben - in den meisten Punkten übereinstimmend mit PSR-2, aber nicht in allen.

Interessant finde ich, wie das OKAPI-Projekt die Sache mit den Blockklammern regelt. Die OKAPI Style Guides sind recht minimalistisch, aber genau bei den Blockklammern differenzierter als PSR-2:

"Tiny codeblocks within methods: { in the same line (with a space before it). Larger blocks: { in a new line."

PSR-2 geht nur alles oder nichts? Dann nehmen wir halt nicht PSR-2 sondern OSG - die Opencaching-Style-Guides, und machen es so wie bei der Code- und der Datenlizenz: "Es gilt PSR-2 mit folgender Ergänzung:

* Bei einzeiligen Blöcken können die Blockklammern entfallen.
* Bei großen Blöcken, oder wenn lange Zeilen direkt aufeinanderfolgen würden, steht die Blockklammer in einer eigenen Zeile.!

Beides führt zu übersichtlicherem Code, und für die die bislang nur PSR-2 kennen gilt auch das was Slini schrieb: Man kann sich an alles gewöhnen.
Benutzeravatar
mic@
Vereinsmitglied
Vereinsmitglied
Beiträge: 6623
Registriert: 04.12.2009, 00:31

[quote="following"]Dann nehmen wir halt nicht PSR-2 sondern OSG - die Opencaching-Style-Guides, und machen es so wie bei der Code- und der Datenlizenz: "Es gilt PSR-2 mit folgender Ergänzung:

* Bei einzeiligen Blöcken können die Blockklammern entfallen.
* Bei großen Blöcken, oder wenn lange Zeilen direkt aufeinanderfolgen würden, steht die Blockklammer in einer eigenen Zeile.![/quote]

Aber wäre denn damit das Problem von Thomas gelöst?
Denn ein "OSG" ist ja eben kein 100%-iges "PSR-2" ! Zur Erinnerung:

# teiling88 gibt zu bedenken, dass man dann keine Entwicklungstools (z.B. diverse
# phpStorm-Plugins) zur Prüfung der PSR-2-Konformität mehr verwenden kann,
# weil sie 100% PSR-2 voraussetzen.
following

Mein Lösungsvorschlag dafür ist, dass wir statt dieser Tools ein eigenes Script verwenden (bescheidener Anfang), das den Code prüft und soweit möglich auch gleich nach unseren Richtlinien korrigiert. Das funktioniert dann nicht nur mit bestimmten Entwicklungsumgebungen, sondern jeder Entwickler kann damit seinen Code aufräumen.
Benutzeravatar
4_Vs
Vereinsmitglied
Vereinsmitglied
Beiträge: 3150
Registriert: 18.03.2012, 07:25

[quote="following"]
Mein Lösungsvorschlag dafür ist, dass wir statt dieser Tools ein eigenes Script verwenden (bescheidener Anfang), das den Code prüft und soweit möglich auch gleich nach unseren Richtlinien korrigiert. Das funktioniert dann nicht nur mit bestimmten Entwicklungsumgebungen, sondern jeder Entwickler kann damit seinen Code aufräumen.
[/quote]
Wie ich verstanden haben, gibt es dann aber bei den Entwickler-IDEs Heruaforderungen, oder nicht?

Wir haben als offenes Projekt Lizenzen von phpStorm, welches so wie ich inziwschen in vielen Foren gelesen habe ein führendes Tool ist (auch wenn Du das nicht einsetzt), dann sollten wir aber auch das Maximale herausholen ...

Und um die Hürde für andere Entwickler zu senken ist ein bekannter Standard mit Sicherheit zuträglicher, als ein unbekannter bzw. keiner ...
Whenever I try to plan something, it doesn't seems to work out. So why plan, it only leads to disappointment! (Eddie van Halen)
following

4_Vs hat geschrieben: Wie ich verstanden haben, gibt es dann aber bei den Entwickler-IDEs Heruaforderungen, oder nicht?
Soweit ich es verstanden habe, entstehen die Herausforderungen nur bei IDE-Plugins, die den Code auf PSR-2 prüfen. Solche Tools muss man nicht verwenden - manche PHP-Projekte arbeiten damit, andere nicht -, sondern man kann auch

* auf eine penibelste Prüfung formaler Richtlinien verzichten (habe in 30 Jahren noch kein Softwareprojekt erlebt, dass deswegen Probleme bekommen hätte), oder

* wie oben vorgeschlagen ein eigenes Prüf- und Cleanup-Tool schreiben, dass solche Fertigtools ersetzt.
Und um die Hürde für andere Entwickler zu senken ist ein bekannter Standard mit Sicherheit zuträglicher, als ein unbekannter bzw. keiner ...
Das was ich vorschlage wäre für jemanden, der nur PSR-2 kann, zu ~ 95% bekannt (gewohnt). Und wen die restlichen 5% nicht interessieren, kann seinen Code auch in 100% PSR-2 schreiben. Ich möchte nur denen, die damit was anfangen können, etwas Spielraum bei der Klammersetzung geben.

Dass jemand PSR kannte und verwenden wollte, war bisher aber die Ausnahme. Der bisherige OC-Code - bevor kürzlich das Thema PSR-2 aufkam - stammt zu 100% von Entwicklern, die sich nach dem "Oliver-Stil" gerichtet haben oder einen ganz anderen Style draufhatten.

Es sind schon einige Entwickler an der Einarbeitung gescheitert, aber das lag an der Bedienung der VM und/oder von Git und/oder der Komplexität der Software.
Benutzeravatar
4_Vs
Vereinsmitglied
Vereinsmitglied
Beiträge: 3150
Registriert: 18.03.2012, 07:25

Ich hab echt vergessen, wie müßig es ist mit Dir zu diskutieren ...

Warum fragst Du eigentlich Themen, bei denen Du Dir eh schon Dein vorgefertigtes Bild gemalt hast, erinnert mich stark an eine Alibi-Diskussion ...
Whenever I try to plan something, it doesn't seems to work out. So why plan, it only leads to disappointment! (Eddie van Halen)
Siggiiiiii
Micro
Micro
Beiträge: 201
Registriert: 04.06.2015, 16:46

[quote="following"]
In der OC-Entwicklung soll PSR-2 eingeführt werden.
[/quote]

Blöde Frage, aber wenn das so sein soll und OC.de Bestandteil davon ist, dann müsste das doch in der weltweiten OC-Community zwischen den verschiedenen Forks und Schnittstellen/Beteiligten durchdiskutiert worden sein und man hätte sich übergreifend auf etwas für alle passendes geeinigt. Macht ja keinen Sinn, wenn Entwickler mit schwerer lesbarem Code Bauchschmerzen bekommen. Die anderen finden das alles so super? *NeinIchWillKeinenShitstorm-KlingtNurUnlogisch*
Benutzeravatar
4_Vs
Vereinsmitglied
Vereinsmitglied
Beiträge: 3150
Registriert: 18.03.2012, 07:25

Hi Peter,

es handelt sich hierbei um keine Diskussion, sorry. Du stellst Thesen auf, nimmst die Argumente der Antwortenden und widerlegst sie mit Deiner "Meinung" ... so kann man nicht argumentieren.

Es gäbe keine Standards, wenn sie keinen Nutzen hätten -> https://de.wikipedia.org/wiki/Standard

Ganz ehrlich, ich finde man macht es sich ziemlich einfach mit Aussagen: Ich finde das unleserlich, oder ich arbeite so nicht. Es geht darum den kleinsten gemeinsamen Nenner zu finden - und ein Standard ist genau dafür geschaffen.

Ob es nun dieser Standard ist oder ein anderer, steht auf einem anderen Blatt.

Nur weil wir das "schon immer so gemacht haben", muss es ja nicht besser werden. Mir fehlt Deine Bereitschaft zu Kompromissen - mir scheint, als ob es für Dich nur schwarz und weiß gibt, Du machst es durch diese Einstellungen "Neuen" extrem schwer Fuß zu fassen, wenn man Dich nicht besser kennen würde, hat das den Eindruck von "es kann nur einen geben" ...

Sorry für "off topic", aber die Diskussionen haben nicht den Anschein, dass wirklich ein Konsens gefunden werden soll, sondern sie haben wie bereits geschildert, ein "Geschmäckle"
Whenever I try to plan something, it doesn't seems to work out. So why plan, it only leads to disappointment! (Eddie van Halen)
Benutzeravatar
teiling88
Vereinsmitglied
Vereinsmitglied
Beiträge: 694
Registriert: 06.12.2015, 14:15

[quote="following"]

Soweit ich es verstanden habe, entstehen die Herausforderungen nur bei IDE-Plugins, die den Code auf PSR-2 prüfen. Solche Tools muss man nicht verwenden - manche PHP-Projekte arbeiten damit, andere nicht -, sondern man kann auch

* auf eine penibelste Prüfung formaler Richtlinien verzichten (habe in 30 Jahren noch kein Softwareprojekt erlebt, dass deswegen Probleme bekommen hätte), oder

* wie oben vorgeschlagen ein eigenes Prüf- und Cleanup-Tool schreiben, dass solche Fertigtools ersetzt.
[/quote]

Es sind nicht nur die IDE-Plugins, die Probleme tauchen auch dann z.B. beim CI, Pre Commit Hooks, scrutinizer/travis etc auch auf.

Bezüglich deinem Beispiel following, finde ich beide Varianten unleserlich. Für mich als neuer Entwickler stellen sich viele Fragen.

Code: Alles auswählen

elseif (isset($_REQUEST['assign']) && $rid > 0 &&
			($adminid == 0 || ($adminid != $login->userid && $age >= 14)))
	{
		sql("UPDATE `cache_reports` SET `status`=2, `adminid`=&2 WHERE `id`=&1", $rid, $login->userid);
		$tpl->redirect('adminreports.php?id='.$rid);
	}
- was wird genau geprüft mit der Bedingung?
- was ist das für ein Status mit der Nummer 2?
- was für ein Alter wird geprüft und warum muss dies größer 14 sein?
- warum wird später noch zwei mal auf $_REQUEST['assign'] geprüft?

Leserlicher und einfacher wäre es eine Controller Struktur zu verwenden anstatt dieses lange if/elseif Konstrukt. Da dies nicht mal ebend so machbar ist wäre ggf. eine Umstrukturierung wie folgt möglich (Funktionsname kann bestimmt noch verbessert werden da ich die Funktion hinter der IF Bedingung aktuell nicht kenne):

Code: Alles auswählen

elseif (assignReportAction($rid, $adminid, $login->userid, $age) === true) {
    sql("UPDATE `cache_reports` SET `status`=2, `adminid`=&2 WHERE `id`=&1", $rid, $login->userid);
    $tpl->redirect('adminreports.php?id=' . $rid);
}

function assignReportAction($rid, $adminId, $userId, $age)
{
    if (!isset($_REQUEST['assign'])) {
        return false;
    }

    if ($rid <= 0) {
        return false;
    }

    if ($adminId != 0 || ($adminId == $userId && $age < 14) {
        return false;
    }

    return true;
}
Damit könnte man ggf. die einzelnen Bedingungen noch kommentieren und wenn man es weiter ausbaut auch die anderen beiden isset($_REQUEST['assign']) Prüfungen mit ersetzen

[quote="following"]
Das was ich vorschlage wäre für jemanden, der nur PSR-2 kann, zu ~ 95% bekannt (gewohnt). Und wen die restlichen 5% nicht interessieren, kann seinen Code auch in 100% PSR-2 schreiben. Ich möchte nur denen, die damit was anfangen können, etwas Spielraum bei der Klammersetzung geben.
[/quote]

Meiner persönlichen Meinung und Erfahrung ist schlecht lesbarer Code im PSR-2 Stil eigentlich immer ein Hinweis darauf gewesen das man diesen optimieren sollte.


[quote="following"]
Schaut euch mal das hier an. Alles bedeutende PHP-Projekte, die sich eigene Style Guides definiert haben - in den meisten Punkten übereinstimmend mit PSR-2, aber nicht in allen.
[/quote]

Du hast aber das schon raus gelesen das die Befragung gemacht wurde während der PSR-2 Standard erarbeitet wurde oder?

Ich habe mir mal ein paar rausgesucht und geschaut welche dort aktuell verwendet weren:

Composer: PSR-2 https://github.com/composer/composer/bl ... er/.php_cs
Phing: PSR-2 https://github.com/phingofficial/phing
Symfony: PSR-2 https://symfony.com/doc/current/contrib ... dards.html

[quote="following"]
Beides führt zu übersichtlicherem Code, und für die die bislang nur PSR-2 kennen gilt auch das was Slini schrieb: Man kann sich an alles gewöhnen.
[/quote].

Oder andersherum wir entwirren den Spaghetti Code und machen es Modularer und Schlanker - dann wird es, egal mit welcher Formatierung, leserlicher :-)
Antworten