WBCE CMS Forum

cwsoft

Mitglied

Coding Stile

In diesem Thread haben wir schonmal grob über die Einführung von minimalen Code Richtlinen für WBCE gesprochen. Ein ähnlicher Thread beschäftigt sich auch mit der Einführung von Dateiheadern in durch uns bearbeitete PHP Dateien.

Basierend auf den beiden Threads habe ich einige Änderungen ins WBCE Repository übertragen.

Dieser Commit setzt die Dateiheader der PHP Dateien die wir bereits überarbeitet haben auf den verlinkten Vorschlag.

In diesem Commit habe ich die PHP Dateien über einen PHP-Beautifier geschickt, um die Klammersetzung und die Einrücktiefen der PHP Dateien zu vereinheitlichen und an vielen Stellen zu korregieren. Diese Aktion hat in Submlimetext 3 fünf Minuten gedauert und im wesentlichen folgende Änderungen eingeführt:

1. Klammern und Einrücktiefen von Kontrollstrukturen (Schleifen, switch, if/else Blöcken) nach PSR-2 Standard vereinheitlicht

2. Klammern und Einrücktiefen von Klassen/Funktionen nach PSR-2 vereinheitlicht

3. Einrückung nach PSR-2 Standards vereinheitlicht (TAB -> 4 SPACE)

Vorteile einer einheitlichen Codeformatierung: Aussendarstellung, leichterer Codereview auf Github (gleicher whitespace) ...
Nun die Fragen an den Rest der Mitstreiter:

1. Ist es ok, den Dateiheader bei von uns angepassten Dateien auf das WBCE Branding zu ändern

2. Ist es ok, für Commits ins WBCE Repo PHP Code nach PSR-2 zu formatieren (Klammersetzung/Einrücktiefen mit Space

Wer sich mit den oben verlinkten Commits gar nicht anfreunden kann, bitte hier melden mit kurzer Begründung warum. Wie bereits an anderer Stelle geschrieben, mache ich die Commits gerne teilweise oder ganz rückgängig. Wenn es andere Vorlieben für Code-Stile gibt, oder ihr gar keine wollt, auch mit kurzer Begründung hier posten. Es soll hier nur um MINIMALE Standards gehen, nicht um HARTE VORSCHRIFTEN die einen irgendwas aufzwingen. Das ganze kann in jedem halbweg tauglichen Editor eingestellt werden und beim speichern automatisch umgesetzt werden. Anleitung für Sublimetext 3 kann ich bei Bedarf gerne geben.

Gruss

Beitrag geändert von cwsoft (20.08.2015 15:34:57)

---

Account inactive since 2018/11/17.

rjgamer

Mitglied

Re: Coding Stile

Ich finde es gut, wenn der PSR-2 nicht zwingend gilt. Klammern bei einer Funktion/Klasse erst nach einem Zeilenumbruch ist einfach kagge und ich kann mich schon seit Jahren nicht anfreunden damit.

---

Neoflow | Fraggy Backend Theme

webbird

Administrator

Re: Coding Stile

Zu a: Dazu habe ich meine Meinung schon gesagt. Den Header sollte man erst ändern, wenn man den Inhalt der Datei geändert hat. Und damit meine ich nicht die Formatierung.
Zu b: Habe ich auch schon gesagt, ich halte das für überflüssig, aber wenn's halt jetzt schon passiert ist, auch egal. Mußt nur damit rechnen, daß sich das wieder jeder so anpaßt, wie er es haben will. Ich halte nix von starren Regeln.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

badknight

Mitglied

Re: Coding Stile

Ich sag so:
Wenn man nach PSR-2 arbeitet, dann aber an allen Stellen!

Für mich persönlich ist einer der wichtigsten Punkte TAB zu Spacer!

Wenn man mit verschiedenen Editoren arbeitet merkt man den Unterschied sehr schnell

cwsoft

Mitglied

Re: Coding Stile

Den Header sollte man erst ändern, wenn man den Inhalt der Datei geändert hat. Und damit meine ich nicht die Formatierung.

Es wurden bisher nur Dateien geändert, in denen wir CODE geändert haben. Code Formatierung macht ein Skript, wieso sollte man da den Header ändern.

Beitrag geändert von cwsoft (20.08.2015 19:30:23)

---

Account inactive since 2018/11/17.

webbird

Administrator

Re: Coding Stile

Es klang so, dann hab ich das mißverstanden, sorry.

---

Ich habe eine Amazon-Wishlist. Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

rjgamer

Mitglied

Re: Coding Stile

Space > Tab regeln, den Rest frei von Standards...?

---

Neoflow | Fraggy Backend Theme

cwsoft

Mitglied

Re: Coding Stile

Zum Thema frei von Standards hat easyuser ne gute Anmerkung gemacht. Macht man die Klammern mal in der ersten Zeile, mal in der zweiten, fügt noch Leerzeilen hinzu oder löscht welche, kann es für evtl. Supportanfragen wie schau mal in Zeile 400. oder 454 nach schnell eng werden. Dann stellt jeder seinen Editor ein wie er will und bei der nächsten kleinen Änderung der Datei geht alles wieder auf Los.

---

Account inactive since 2018/11/17.

marmot

Mitglied

Re: Coding Stile

Hi,

zu a) sollte nichts schaden, soweit ich das beurteilen kann. Wichtig für mich wäre, dass auf jeden Fall auch die Vorgänger mit angegeben werden. Aber das war ja ohnehin klar.

zu b) ja klar, auch wenn ich es echt nicht wichtig finde. Wenn einer Code nicht versteht und es auf die Formatierung schiebt, dann macht er sich selbst was vor. Für mich steht ganz klar Funktionalität vor Formalismus.
Allerdings ist es ja auch kein Problem den Code gelegentlich komplette über einen Beautyfier laufen zu lassen (3 Minuten lt. cwsoft). Das könnte man ja gelegentlich machen.
Aus meiner Sicht wäre es viel wichtiger die Vorbereitungen (Kommentare) für die automatische Erstellung einer API Doku zu haben (bin ich aber auch zu faul dafür).

a) und b) werde ich sicherlich immer wieder mal vergessen. Wenn das ein Problem ist und sich ständig jemand ganz doll darüber ärgert, dann sollte er das kund tun. Denn ich werde mich ärgern, wenn mich jemand ständig deswegen anmacht und dann würde ich im Vorfeld ausklinken, um die Nerven aller Parteien zu schonen.

Gruß

cwsoft

Mitglied

Re: Coding Stile

Ok, dann fasse ich mal kurz die geäusserten Meinungen bezüglich Code-Stilen in diesem und diesem Thread zusammen.

Meinungen von Mitgliedern mit Zugang zum WBCE Github Repo:
- cwsoft: PSR-1 + PSR-2 (SPACE statt TAB)
- marmot: generell ja aber nicht wirklich wichtig
- norhei: TAB zu SPACE grausam ... aber machbar, Rest eher nein
- webbird: überflüssig (arbeitet mit SPACE)
Einführen von Code-Stilen: 1 x ja, 1 x nein, 2 x nicht wichtig

Meinungen von den übrigen Mitgliedern:
- badknight: wenn PSR-2 dann überall (SPACE statt TAB)
- easyuser: PSR-1+PSR-2 (SPACE statt TAB)
- rjgamer: PSR-2 nicht zwingend (SPACE statt TAB sonst nix)
Einführen von Code-Stilen: 2 x ja, 1 x nein nur SPACE

Nach aktuellem Meinungsbild würde ich sagen, jeder macht wie er denkt und wir legen keine Coding-Richtlinien für die gemeinsame Arbeit am WBCE Code fest. Eventuell kann man sich auf das Minimalziel SPACE statt TAB einigen, wär ja mal ein Anfang.

Die mit Commit aa4e12f30a5 eingeführten PSR-1 und PSR-2 Formatierungen werden nicht rückgängig gemacht. Hier entspricht der Tenor, wenn es schon mal drin ist ...

Was die Sache mit den Dateiheadern angeht. Hier ist der gemeinsame Tenor, diesen nur zu ändern, wenn CODE Änderungen an einer Datei gemacht wurden und evtl. zusätzliche Copyright Statements auf jeden Fall mit zu übernehmen - eh logisch. Entspricht also genau dem Vorgehen wie wir (ich) es bisher gemacht haben.

Dann mal happy Coding 

---

Account inactive since 2018/11/17.

norhei

Developer

Re: Coding Stile

+1 Miniziel, OK

Beitrag geändert von norhei (21.08.2015 10:49:49)