oxpus hat geschrieben: ↑17.08.2021 11:32
PSR2 würde mir persönlich allerdings schon deutlich besser gefallen, gerade was auch die Verwendbarkeit des Codes in anderen Systemen anbelangt, wo eben andere Regeln gelten.
Aber bleiben wir bei den bestehenden Regeln, denn ich gebe Dir vollkommen Recht, dass eine Umstellung auf PSR2 die meisten phpBB-Entwickler vergraulen könnte.
Es hat eh fast jedes Web-Projekt seine ganz eigenen Regeln. Wenn man natürlich Dinge aufgrund langer Erfahrung anders gewohnt war, ist es immer erstmal mühselig, sich an die Projekt-spezifischen Vorgaben anzupassen. Ging mir zumindest so, als ich im Sommer 2018 anfing mich mit phpBB Ext zu beschäftigen und auch überhaupt erst mit PHP anfing. Da war zuerst mal kräftig umdenken angesagt. Nicht nur was PHP angeht, auch was die phpBB Richtlinien angeht. Ich komme eigentlich aus der Compiler und IDE Welt, mit Interpreter-Sprachen habe beruflich nur am Rande zu tun. Und da war für mich der Einstieg in PHP und phpBB ein regelrechter Kulturschock.
![Lachend :lol:](./images/smilies/icon_lol.gif)
Allerdings, wenn man schon ein paar Jahrzehnte Software Entwicklung auf dem Buckel hat, ist beim Einlernen in ein neues Projekt und/oder eine neue Programmiersprache die anfängliche "Schmerzphase" relativ kurz. Inzwischen liebe ich es, in PHP zu programmieren. Unter anderem deswegen, das gebe ich offen zu, weil ich mich um eine ganze Menge nerviger Details gar nicht kümmern muss.
Glücklicherweise hatte ich vorhin doch noch eine Möglichkeit gefunden, einen phpBB-Coding-Regelsatz in meiner IDE zu integrieren, wodurch jetzt durchgängig danach geprüft werden kann.
Jetzt wäre nur noch die enthaltene "PHP Intelligence" davon zu überzeugen, die phpBB-eigenen Container ebenfalls als "korrekt" zu markieren, damit ich meine Extensions auch einzeln validieren kann. Da zickt der betreffende Linter noch etwas rum, da bislang leider nur innerhalb eines Projektes validiert wird, unabhängig, worin sich dieses Projekt befindet oder zu welchem "größeren" Projekt es gehören könnte. Da gibt es noch Verbesserungspotential...
Das hört sich doch schon mal gut an. Was IDEs und deren Möglichkeiten angeht: Du musst berücksichtigen, dass die meisten Ext Coder wohl eher keine ausgewachsene IDE benutzen, sondern einen guten Editor. Und einige der EC Nutzer auch gar nicht vorhaben, offiziell validieren zu lassen. Und ebenso nutzt nicht jeder Ext Coder automatisch auch Github. Ein "Gelegenheits-Programmierer" kann/will sich nicht mit Github oder IDEs auseinandersetzen. Aber um z.B. per EPV und PSSE prüfen zu können, müsste man mindestens Github nutzen. Es sei denn, man richtet sich alle benötigten Analysetools lokal ein, das setzt aber auch schon wieder einiges Grundwissen voraus. Für eben diese Zielgruppe wurde EC ursprünglich geschaffen, es schliesst eine Lücke bei den Werkzeugen für diese Gruppe.
Wenn man eine IDE nutzt, hat man eh ganz andere Möglichkeiten der Prüfung und je nach IDE kann man sogar CS gleich direkt integrieren. Ich habe zwar eine IDE installiert, aber noch komme ich prima mit NP++ zurande. Wenn ich mal solche Mammut-Projekte ähnlich wie deine DL Ext anfange, werde ich auf jeden Fall die IDE benutzen.
Dann lebe ich lieber mit den false positive Meldungen, bevor ein echter Fehler übersehen wird.
Ein schwieriges Thema, gebe ich zu, aber wirklich keines, welches mit Gewalt gelöst werden muss.
So sehe ich das auch. Schlussendlich ist EC ja für niemand eine Pflicht, das ist völlig wahlfrei. Es soll Ext Coder bei ihrer Arbeit unterstützen und gleichzeitig auch den phpBB Coding Standard etablieren und die Code Qualität verbessern. Und davon profitieren schlussendlich alle Ext Coder.
An dieser Stelle aber noch einmal ein großes Lob für den umfangreichen Ext Check. Das ist wirklich eine große Hilfe für alle Entwickler und kann nicht oft genug bestätigt werden.
Mir wird es jedenfalls zukünftig sehr viel helfen, was ich lange Zeit idiotischerweise ignoriert hatte.
Danke für dein Lob! Es steckt auch sehr viel Arbeit und Herzblut darin. Schlussendlich sind auch immer wieder Vorschläge von den EC Benutzern eingeflossen, siehe Changelog.
Und hier mal eine Vorschau wie das dann aussieht, wenn phpc-auto aktiviert ist:
[ externes Bild ]
Wenn phpc-auto deaktiviert ist, sieht es klassich so aus:
[ externes Bild ]
Ich nutze dazu bereits vorhandene Funktionalität mit der ich eine ganze Prüf-Kategorie deaktivieren kann. Diese musste ich jetzt nur geringfügig anpassen. Gestern Abend bin ich noch von einem grösseren Aufwand ausgegangen, als ich das quick-and-dirty umgesetzt habe. Aber tatsächlich war eigentlich das meiste für phpc-auto schon vorhanden.
Oben links ist ein Debug. Dort lasse ich mir im Prototyp die bereinigte PHP-Mindestversion anzeigen. Bereinigt heisst: wenn ich die Version extrahiert habe, prüfe ich sie auf einen gültigen Bereich. Ist sie geringer als 5.3 oder schlicht ungültig, wird 5.3 gesetzt. Ist sie höher als 8.0 wird eben 8.0 gesetzt. PHPCompatibility erwartet bei den Parametern die Version im Format <major>.<minor>. Wenn also in der
composer.json
z.B.
>=7,<8
stünde, würde das von EC als ungültig behandelt und auf 5.3 gesetzt werden.