@Konafets Nee sind zwei Tools, die man leider identisch abkürzen kann, und mich daher was wahnsinnig machen in ihrer Namenswabl:
PHP CodeSniffer
PHP CodeStyle [Fixer]
@supergarv Für den PHP CodeSniffer habe ich zusammen mit Andy Grunwald vor Jahren mal die komplette TYPO3 CGL in ein eigenes Ruleset gegossen. Das war bevor es den PSR-Standard gab.
Im Grunde brauchst Du nur eins von beiden. Ich nehme immer den Sniffer.
@brotkrueml ... und: Ich sehe in deiner common.php jede Menge PhpCsFixer Rules, aber keine von PhpSniffer - ist die Xml davon dann default bei Dir, oder wie...?
(1/3) @supergarv Also: Psalm und PHPStan machen praktisch dasselbe. Wenn du also das eine Tool benutzt, bringt das andere üblicherweise praktisch keinen zusätzlichen Nutzen (bis auf einige Ausnahmen).
(2/3) @supergarv PHP_CodeSniffer und PHP-CS-Fixer sind beide primär für Codestyle zuständig und haben miteinander viele Überlappungen, sind aber von der Philosophie und Geschichte her grundsätzlich anders: PHP_CodeSniffer checkt (und meckert), und er kann einige (nicht alle!) Dinge fixen, über die er meckert. Dadurch kann das Tool auch Probleme entdecken, die nicht autofixbar sind (z.B. Zeilenlänge oder Naming).
(3/3) @supergarv
PHP-CS-FIxer fixt Probleme, und man kann ihn auch als Checker benutzen. Allerdings kann er nur Sachen anmeckern, die er auch fixen kann, daher also nicht Dinge wie Zeilenlänge oder Naming.
Abgesehen davon wird PHP-CS-Fixer aktiver entwickelt als PHP_CodeSniffer, und PHP-CS-FIxer unterstützt auch neuere Coding-Standards (PER-2 als WIP) verglichen mit PHP-CS-FIxer.
Meiner Erfahrung nach reicht eins der beiden Tools (mit TYPO3 eher PHP-CS-Fixer).
@oliklee Hervorragend, das hat mich gut abgeholt!
Eine Frage: Weisst Du ob ich alles (relevante) was Sniffer anmäkeln kann auch über phpstan abgehandelt bekommen könnte, und alles was sniffer fixt mit php-cs-fixer? Dann hätte ich nur zwei Tools.
PHP-CS-Fixer kümmert sich, wie der Code aussieht: Formattierung, Reihenfolge der Methoden, keine unnötigen FQCNs, etc.
PHP_CodeSniffer kümmert sich vorrangig um Formattierung. Da es nicht darauf limitiert ist, alles, was es anmeckert, auch korrigieren zu können, kann es bspw. auch Softwaremetriken berechnen oder Aussagen über die benötigte PHP-Version treffen.
@supergarv@oliklee Psalm und PHPStan machen statische Codeanalyse, um echte Fehler (keine Fehler in Bezug auf Aussehen des Codes) zu finden, ohne dass der Code, beispielsweise durch automatisierte Tests, tatsächlich ausgeführt wird.
@sebastian@oliklee Danke für die Verfeinerung. Ok, dann bedarfs wohl doch ein Triumvirats - hatte gedacht dass phpstan mit statischer Analyse ja auch das finden müsste, was Sniffer als unfixabke findet. Verstehe aber den leichten Unterschied im Scope Formatierung vs Funktionalität.
@oliklee Bonusfrage: Möchte man typo3/coding-standards als wrapper nutzen, oder lieber seine Regeln selber ab und zu mit dem Core abgleichen? Es scheint, dass das Paket dem Core ja auch hinterherhinkt, und es gibt kein symfony7-kompatibles release.
Bzw eigentlich wundere ich mich, warum der Core nicht seine Regel-Ergänzungen in das Paket gem. semver packt, für ein single-source-of-truth? @lolli
@supergarv@oliklee ich nutze typo3/coding-standards nicht mehr, und habs ausgebaut: dramatisch zuviel bloat fuer ein problem das sich auf einen file reduzieren laesst, den man vom core alle 3 jahre mal rueberkopiert. aber jeder wie er mag.
@lolli Danke für die Bestätigung, ich dachte mir auch einfach ein presetfile einzeln für mich reinzuklöppeln und zu maintainen sollte überschaubar sein, wenn die regeln sich nicht geradr alle 2 wochen ändern (phpcs updates jede Woche sind mir egal).
@Xitnelat@oliklee Wenn man die Projekte wenigstens PHP-Sniffer und PHP-Codestyler oder so genannt hätte, dann wäre ich kein pöbelnder alter weisser Mann 👴🏻
@supergarv
glaub entweder psalm oder phpstan reicht. macht wenig sinn beide statischen analyzer im gleichen projekt gegeneinander auszuspielen: ausser onanie mit hang zu selbstgeisselung gibts glaub wenig gruende das zu machen - das geht zu sehr in richtung schlangenoel uebereinander stapeln statt echte issues zu loesen.
@lolli Genau das möchte ich vermeiden. Geht drum mal bei uns einheitliche Code-Standards zu etablieren mit low-hanging fruits der automatisierbaren Fixes. Also erstmal cyclomatic cognitive load faktorisierung beiseite legen. Klappte auch easy; 30min Tool config, 7.5h Refactoring&Fixing der Codebasis 🥹
@supergarv in dem fall wuerde ich derzeit eher versuchen mich auf phpstan zu konzentrieren: das gefuehlt derzeit die aktivere und insgesamt geilere loesung. noch den php-cs-fixer dazu fuer cgl-shit, und gut. wenn du dann als technischer leiDer deine leute aergern willst, drehst halt den level hoch und machst nen CI watcher das der baseline file nicht wachsen darf ^^
@lolli Technischer Leider? Haha, den kannte ich noch nicht.
Mich wurmt etwas dass PHP-CodeSniffer und PHP-CS-Fixer unterschiedliche rulesets bieten, da frage ich mich ob ich nicht alles mit einem hinbekäme. Wäre einfacher wenn ich die beiden Tools nicht ständig verwechseln würde, und wüsste was was macht -.-
@supergarv Ja, cgl shit halt. waehle eine hoelle und lebe in ihr. typo3 community hat sich glaub weitgehend auf cs-fixer eingeschossen, das laeuft. nimm in der dependency ein ^.x.y, dann schlaegt dein nightly an, wenn sich was neues ergibt - das macht core mit phpstan auch so, und php-cs-fixer hat deshalb gerade "fixes" in fluid standalone und dbdoctor getriggert, damit es nicht langweilig wird (beides done) ;)
@supergarv und gerade cgl shit is jammern auf hohem niveau, heutzutage: lass dir halt die rules von PER bestimmen, keine diskussion, einfach folgen, fertig. adaptieren wenn noetig. frueher hatte man da epische diskussionen, das ist zum glueck vorbei.
Add comment