Thema: Hindert euch ein nicht präferierter CS an der Teilnahme/Verwendung eines OS-Projektes

Plant Mohiva etwa die Einführung von PSR-1/PSR-2?

Finde die Umfrage viel zu grob. Problem ist, dass sehr viele Punkte unberücksichtigt bleiben, die aber für die Entscheidung wichtig sind.

1. Wie wichtig ist das Projekt?

Wenn es ein Tool, eine Library, oder ein Framework, was bereits verwendet wird, oder was einfach alternativlos ist, dann springe ich schon eher über den Schatten. Wenn ich es bereits verwende, bin ich auch schneller bereit Bugfixes bereit zu stellen. Das ist unabhängig vom CS

2. Von welchen Code-Styles reden wir eigentlich?

Ich persönlich unterscheide zwischen äusserem und inneren Stil. Wie ein Projekt im inneren formattiert ist, interessiert mich ne Wurst, wenn ich es nur verwenden will und vielleicht ab und an mal reinschaue. Beim äusseren Stil -- gemeint ist der Aufbau und die Nomenklatur der API -- bin ich schon empfindlicher. Das bedeutet bei starken Abweichungen zu bekannten Stilen, dass man alles immer wieder nachschlagen muss, weil man es eben nicht gewohnt ist.

3. Was heißt "präferiert"?

Das man ein Stil bevorzugt, heißt ja nicht, dass alle anderen gehasst werden. In vielen vielen Fällen sehen sich die Stile mittlerweile eh sehr ähnlich, da ist die Abschreckung nicht so groß. Nimmt man dagegen ein PHP4-Projekt unterscheidet sich viel bis alles und nebenbei hinterlässt es bei mir ein Eindruck, dass das Projekt gar nicht richtig gewartet wird.


Hatte eigentlich noch 4 und 5. Sind unterwegs wohl untergegangen Falls ich recht habe und du planst PSR-1 (und eventuell PSR-2) einzusetzen wäre meine Meinung, dass das schon sinnvoll ist. Die meisten sind dann doch Gewohnheitstiere und sich an etwas zu orientieren, was man kennt, spart mindestens ein Denkschritt vorm Pull-Request Und ganz nebenbei reicht eine einzelne Codesniffer-Konfiguration

Zitat von SeKrebs

Und ganz nebenbei reicht eine einzelne Codesniffer-Konfiguration

Und eine einzige Einrichtung der Code-Formatierung in der eigenen Entwicklungsumgebung.

Plant Mohiva etwa die Einführung von PSR-1/PSR-2?

Ich bin gerade am Abwägen. Es gibt ja eigentlich nicht viel was meinen CS von PSR-1/PSR-2 unterscheidet. Die 3 wichtigsten Punkte sind sicherlich:
- die Benennung der Namespaces nach Java Manier
- das verwenden von Tabs statt Spaces
- ich nutze durchgehen 1TBS

Wobei ich für mich wichtige Gründe in den Unterschieden sehe.
Ich finde zum Beispiel die Namespace-Deklaration die durch PSR-1/PSR-2 propagiert wird nicht richtig durchdacht. Ich möchte sogar stark annehmen das einfach nur die alten Namepace-Separatoren blind durch die neuen Namespace-Separatoren ersetzt wurden, ohne sich vorher Gedanken darüber zu machen ob das wirklich sinnvoll ist. In den pre Namespace Zeiten hat die Großschreibung der Klassennamen ja auch hingehauen. Nur mit der Einführung der Namespaces seit PHP 5.3 kann man nicht mehr richtig erkennen was ein Namespace und was eine Klasse ist.

use Mohiva\Common\Controller;

Das kann eine Klasse oder ein Namespace sein. Um mich zu vergewissern muss ich in den Quellcode schauen. Das ist nach der Java Norm einfach eleganter gelöst. Namespaces immer klein und Klassen immer groß. Was mir auch fehlt ist die feinere Einteilung der Namespaces im Vendor Bereich. Bei uns auf Arbeit gibt es zum Beispiel Projekte die unter der gleichen Domäne aber unter einer anderen TLD laufen.

\info\project\www
\com\project\www
\net\project\cdn

Ich finde das einfach flexibler.

Über die anderen Dinge lässt sich ja bekanntlich streiten. Was mich zum Beispiel ärgert ist das auf Github die Tabweite auf 8 Spaces gesetzt ist. Hier würde ich mir schon wünschen das jeder den Quellcode so sehen kann wie er von meiner Seite aus formatiert wurde. Das ist eben ein Nachteil der Tabs.

2. Von welchen Code-Styles reden wir eigentlich?

Ich persönlich unterscheide zwischen äusserem und inneren Stil. Wie ein Projekt im inneren formattiert ist, interessiert mich ne Wurst, wenn ich es nur verwenden will und vielleicht ab und an mal reinschaue. Beim äusseren Stil -- gemeint ist der Aufbau und die Nomenklatur der API -- bin ich schon empfindlicher. Das bedeutet bei starken Abweichungen zu bekannten Stilen, dass man alles immer wieder nachschlagen muss, weil man es eben nicht gewohnt ist.

Ich dachte eigentlich das ich dass mit Fall 1 und 2 abgedeckt habe.

3. Was heißt "präferiert"?

Das man ein Stil bevorzugt, heißt ja nicht, dass alle anderen gehasst werden. In vielen vielen Fällen sehen sich die Stile mittlerweile eh sehr ähnlich, da ist die Abschreckung nicht so groß. Nimmt man dagegen ein PHP4-Projekt unterscheidet sich viel bis alles und nebenbei hinterlässt es bei mir ein Eindruck, dass das Projekt gar nicht richtig gewartet wird.

Naja nicht gehasst, aber die Diskussion Tab vs Spaces nimmt teilweise schon religiöse Züge an.

Wenn ich mich irgendwo beteilige, dann nur für einzelne Komponenten und darum muss die Hürde der Beteiligung sehr gering sein. Also nach Möglichkeit etwas was ich kenne: Bugzilla -> Patch anhängen und dann ist es wichtig dass jemand schnell darauf antwortet. Ich will nicht wissen wie viele Lösungen es in den div. Bugzillas gibt auf die nur nie jemand geantwortet hat.

Erst aus dieser Gelegenheitsbeteiligung kann dann eine etwas größere Beteiligung werden. Das halte ich persönlich daher für wichtiger als jeder Codestyle oder Code (sofern beides nicht zu grausam ist).

Ich finde zum Beispiel die Namespace-Deklaration die durch PSR-1/PSR-2 propagiert wird nicht richtig durchdacht. Ich möchte sogar stark annehmen das einfach nur die alten Namepace-Separatoren blind durch die neuen Namespace-Separatoren ersetzt wurden, ohne sich vorher Gedanken darüber zu machen ob das wirklich sinnvoll ist.

Auf eine gewisse Art hast du Recht, allerdings hat man sich doch schon vor EInführung der Pseudo-Namespace-Deklaration darüber Gedanken gemacht (siehe PSR-0). In diesem Sinne finde ich die Java-Nomenklatur auch nicht gelungen, denn einerseits bringt es immer irgendwie einen hässlichen Prefix mit, andererseits könnte sich eine Domain auch mal ändern

In den pre Namespace Zeiten hat die Großschreibung der Klassennamen ja auch hingehauen. Nur mit der Einführung der Namespaces seit PHP 5.3 kann man nicht mehr richtig erkennen was ein Namespace und was eine Klasse ist.

Würde persönlich die Kleinschreibung auch bevorzugen, finde ich aber schon vernachlässigbar. Gute IDEs sagen dir schon, was ne Klasse ist und was nicht. Guter Stil ist sowieso in use-Statements nur Klassen anzugeben, was bedeutet, dass das die einzige Stelle ist, wo dieses Problem auftreten kann.

Was mir auch fehlt ist die feinere Einteilung der Namespaces im Vendor Bereich. Bei uns auf Arbeit gibt es zum Beispiel Projekte die unter der gleichen Domäne aber unter einer anderen TLD laufen.

Das klingt für mich ziemlich eindeutig nach einem einzelnen Projekt Überhaupt klingt die Sortierung so gar nicht nach PSR-0: In dem Kontext wären die Projekte eher

Code:

CompanyName\Project\Common # Falls überhaupt benötigt in der Form
CompanyName\Project\Subset1

Das erste ist immer der Vendor, das zweite das Paket. Ob das Paket auch nach dem Projekt benannt werden sollte, bleibt jedem selbst überlassen, aber ich glaube, dass dürfte in vielen Fällen auch gar nicht notwendig und womöglich auch nicht sinnvoll sein. Zumindest geht man mit PSR-0 nicht davon aus, dass ein Paket immer von der selben URL vertrieben wird, noch das es immer auf der selben Domain zum Einsatz kommt (nicht mal, dass es immer nur auf EINER Domain zum Einsatz kommt). Man könnte sagen: Es ist dezentral

2. Von welchen Code-Styles reden wir eigentlich?

Ich dachte eigentlich das ich dass mit Fall 1 und 2 abgedeckt habe.

Hast du, wollte aber darauf hinaus, das je nach Projekt mal das eine, mal das andere mal beides und mal keins von Beiden von Bedeutung ist.

Naja nicht gehasst, aber die Diskussion Tab vs Spaces nimmt teilweise schon religiöse Züge an.

Jop, verständlich. Ich hab schon viel Zeit damit verbracht reguläre Ausdrücke für Mischdateien zu basteln. Ich habe auch noch nie erlebt, dass die Dateien konsequent ausschließlich nur Tabs verwendet haben; spätestens bei Inline-Einrückungen scheiterten alle. Hinzu kommt das Problem, was viele als "Vorteil" beschreiben: Jeder kann sich die Tabweite selbst einstellen. Gut, damit wäre die maximale Zeilenlänge ja hinfällig, denn die ist nun bei jeden anders OK, man könnte nun projektweit wieder per Style-Guide festlegen, dass ein Tab X Zeichen lang ist, aber dann wäre dieser "Vorteil" auch dahin.
Parallel dazu: Bei Leerzeichen für Einrückungen hat mich nicht mal Gnomes gedit im Stich gelassen


@crash:
So ziemlich genau so sehe ich das auch, aber leider spielen da die CS durchaus eine nicht unerhebliche Rolle. Eine Antwort auf ein Patch, oder Pull-Request "Sieht gut aus, aber bitte formatiere die Änderungen gemäß unseren Richtlinien" ist schon sehr frustrierend. Wenn ich mich dann auf ein Standard verlassen kann, der sowieso in der IDE eingestellt ist, fällt das aber schon mal viel leichter.

Der PSR-2 spricht doch von Einrückungen durch Tabs statt Leerzeichen ist doch wunderbar

@SeKrebs: Das nicht gleichmäßige Nutzen von Tabs oder Spaces ist wirklich schlimm. Habe die letzte Zeit mit Eclipse CDE gearbeitet und obwohl es ein Eclipse ist, wird die Angabe der Einrückung teilweise einfach ignortiert. Man definiert Spaces, öffnet eine geschweifte Klammer drückt Enter und hat dann den Cursor schön eingerückt mit Tabs, waaaaah.


Was ich an PSR-2, dem ZF-CodingStandard und dem Pear-Standard gar nicht mag sind die geschweiften Klammern in einer eigenen Zeile, keine andere Sprache macht diesen Quatsch, aber in PHP hält man es für nötig...


Gibt es eigentlich im CodeSniffer mittlerweile PSR-1 und PSR-2 Rules?

Was ich an PSR-2, dem ZF-CodingStandard und dem Pear-Standard gar nicht mag sind die geschweiften Klammern in einer eigenen Zeile, keine andere Sprache macht diesen Quatsch, aber in PHP hält man es für nötig...

Definitiv. Hatte dazu eine längere, umfangreiche Diskussion auf der Mailinglist, die darauf hinaus lief, dass die meisten Projekte das schon so machen und das denen damit eine Adaption des Standards leichter fällt (bzw diese dann überhaupt mitmachen ). Inkonsequenz, nur um andere nicht zur sehr auf die Füße zu treten, scheint typisch fürs PHP-Ökosystem Und tatsächlich tauchten immer wieder Kommentare auf, wie "Wenn ich alle meine Tabs durch Leerzeichen ersetzen soll, mach ich (respektive mein Projekt) aber nicht mit" (gleiches Spiel wirklich auch wegen der geschweiften Klammern, etc).

Gibt es eigentlich im CodeSniffer mittlerweile PSR-1 und PSR-2 Rules?

Für PSR-1 hat sich jemand mal die Mühe gemacht, PSR-2 afaik bisher nicht, lese aber auch nicht mehr alles auf der Mailinglist (too much noise )

Zitat von SeKrebs

Und tatsächlich tauchten immer wieder Kommentare auf, wie "Wenn ich alle meine Tabs durch Leerzeichen ersetzen soll, mach ich (respektive mein Projekt) aber nicht mit" (gleiches Spiel wirklich auch wegen der geschweiften Klammern, etc).

Es gibt eben Menschen, die können mit einem Neuanfang nicht umgehen bzw. wollen damit nicht umgehen.

Zitat von SeKrebs

…lese aber auch nicht mehr alles auf der Mailinglist (too much noise )

Geht mir ebenso.

Nachtrag:
https://github.com/klaussilveira/phpcs-psr1 PSR-1 Sniff von Klaus Silveira
https://github.com/squizlabs/PHP_Cod...db868abdc5244d Erster Commit zur Integration direkt in CodeSniffer.

Der PSR-2 spricht doch von Einrückungen durch Tabs statt Leerzeichen ist doch wunderbar

Hab ich was verpasst. Auf der Seite steht doch

Code MUST use 4 spaces for indenting, not tabs.

@SeKrebs: Das nicht gleichmäßige Nutzen von Tabs oder Spaces ist wirklich schlimm. Habe die letzte Zeit mit Eclipse CDE gearbeitet und obwohl es ein Eclipse ist, wird die Angabe der Einrückung teilweise einfach ignortiert. Man definiert Spaces, öffnet eine geschweifte Klammer drückt Enter und hat dann den Cursor schön eingerückt mit Tabs, waaaaah.

Dazu fällt mir doch gleich das Bild ein:
https://lh5.googleusercontent.com/-V..._vs_spaces.png

Was ich an PSR-2, dem ZF-CodingStandard und dem Pear-Standard gar nicht mag sind die geschweiften Klammern in einer eigenen Zeile, keine andere Sprache macht diesen Quatsch, aber in PHP hält man es für nötig...

Geht mir auch so.

Zitat von ice-breaker

Was ich an PSR-2, dem ZF-CodingStandard und dem Pear-Standard gar nicht mag sind die geschweiften Klammern in einer eigenen Zeile, keine andere Sprache macht diesen Quatsch, aber in PHP hält man es für nötig...

Dann wirst du meinen erst recht hassen Bei mir hat sich irgendwie sowas ergeben, wenn ich privat programmiere:

PHP-Code:

<?php

class Foo
{
    public function __construct($bar)
    {
        if (true === $bar) {
        }
    }
}

Also nur bei Kontrollstrukturen schreib ich die geschweifte Klammer in dieselbe Zeile. Leider unterstützt sowas wie PHP_Beautifier das nicht. Auch andere Tools können sowas nicht, soweit ich getestet habe. Aber dafür ist man ja Programmierer - dann baut man halt eben eines, welches flexibler (und vielleicht auch schneller?) ist.

Zitat von akkie

Hab ich was verpasst. Auf der Seite steht doch

ich meinte natürlich Spaces statt Tabs, sonst hätte es ja nichts gebracht zu widersprechen.

Zitat von DennisBecker

Dann wirst du meinen erst recht hassen Bei mir hat sich irgendwie sowas ergeben, wenn ich privat programmiere:

PHP-Code:

<?php

class Foo
{
    public function __construct($bar)
    {
        if (true === $bar) {
        }
    }
}

Also nur bei Kontrollstrukturen schreib ich die geschweifte Klammer in dieselbe Zeile. Leider unterstützt sowas wie PHP_Beautifier das nicht. Auch andere Tools können sowas nicht, soweit ich getestet habe. Aber dafür ist man ja Programmierer - dann baut man halt eben eines, welches flexibler (und vielleicht auch schneller?) ist.

Vielleicht kannst du mir dann den Vorteil davon erklären und bitte nicht "Damit es offensichtlich ist, das beide korrespondierende Klammern auf einer Ebene liegen". Wenn man nämlich die öffnende Klammer hinter das Statement setzt, dann ist die schließende Klammer auf einer Ebene mit dem korrespondierenden Schlüsselwörter, was ich persönlich sprechender finde (eventuell weil ein Schlüsselwort mehr "spricht", als ne öffnende Klammer ). Leider war das aber bis dato das einzige Argument, was ich bisher dazu gehört habe (OK, vielleicht noch "Haben das immer so gemacht", oder "Macht Sprache XY, mit der ich auch programmiere, auch so"). Ich erhoffe mir grad son kleinen Aha-Effekt
Vielleicht noch "Code-Ästhetik": Ich finde, das sieht fleckig aus (Ja, ohne Anführungszeichen, ich meine wirklich "fleckig".)

@akkie: Das Bild ist gut und trifft es auch irgendwie. Mit Wohlwollen könnte ich Tabs tolerieren (also in eigenen Arbeiten, wenns verlangt wird), aber gegen Hybride sträube ich mich.

Warum ich das so mache ist schwierig zu sagen. Bei uns auf der Arbeit sind bestimmt >85% der PHP Klassen so strukturiert und irgendwann fängt man dann selbst auch an, so zu schreiben und passt sich der Allgemeinheit ein.

Das mache ich übrigens bei Coding Standards immer so Ich passe mich dem jeweiligen Projekt an.