coding guidelines

[Phpyton]

Ich wühle mich grade durch ein Framework und mir fällt auf, dass Ordnernamen teilweise groß, teilweise klein geschrieben sind. Das ist ziemlich verwirrend. Gibt es da ein paar Guidelines. Rein aus Interesse: Wie macht ihr das?

[mermshaus]

@rkr:

Leerzeichen sind wohl ursprünglich auch mal nicht dazu da gewesen, um irgendwas einzurücken? Kann man da nicht sagen, dass eine Einrückung mit Leerzeichen im traditionellen Sinne einer Zweckentfremdung gleichkommt?

Ich weiß nicht. Beim Leerzeichen ist es eben nicht so, dass der eigentliche Einsatzzweck „unmöglich“ gemacht wird, sondern dass nur eine Funktion hinzukommt. Ein Leerzeichen ist für sich erst mal auch sehr generisch. Es ist eben nur ein „leeres Zeichen“.

Wenn man Tab aber als Indent-Zeichen mit – was ja ganz zentral wichtig zu sein scheint – beliebig definierbarer Schrittweite nutzt, dann ist es nicht mehr möglich, mit den TABULAtoren Daten tabellenartig anzuordnen, weil die Tabellen nur bei einer bestimmten Schrittweite funktionieren.

Der Witz an der Stelle – das passt auch ganz gut zu Tropis letztem Beitrag – ist, dass das Auffüllen von Tabs durch Spaces im Grunde genau diesen Einsatzzweck wiederherstellt, indem die Ambiguität, wie ein Tab zu interpretieren und darzustellen ist, rausgenommen wird.

Am Rande, auch als „Gegenbeispiel“ zu Tropis „ihr drückt alle Tab“:

  * @exception   CloneNotSupportedException     if the object's class does not
  *                                             support the <code>Cloneable</code>
  *                                             interface. Subclasses that override
  *                                             the <code>clone</code> method can also
  *                                             throw this exception to indicate that an
  *                                             instance cannot be cloned.
  *
  * @exception   OutOfMemoryError               if there is not enough memory.
  * @see         java.lang.Cloneable 
  */
 protected native Object clone() throws CloneNotSupportedException;

Das ist eine Tabelle. Die kriegt ihr nicht zusammengetabbt, da drückt ihr endlos Leerzeichen, während Spaces-Leute tatsächlich tabben können. (Auch wenn das nur eine Softwaresache ist.) Das ist irgendwie ironisch, wenn man mal drüber nachdenkt.

Ihr nutzt TAB gewissermaßen rein als IND („Indenter“/„Indentator“).

Anderes Beispiel:

        $imageBackgroundColor = 'rgb(' . implode(', ', array(($backgroundColor & 0xFF0000) >> 16,
                                                             ($backgroundColor & 0x00FF00) >> 8,
                                                             ($backgroundColor & 0x0000FF))) . ')';

Viel Spaß auch hier bei der Formatierung.

Die Diskussion wäre meines Erachtens übrigens anders, wenn ein Konsens darüber bestünde, dass ein Tab immer meinetwegen mod8 ist (so definiert das etwa Linus (?) gleich im ersten Satz des Kernel Coding Styles[1]). Das würde einige Probleme mit Tabs zur Einrückung lösen. Nur würden bei mod8-Tabs vermutlich die meisten (?) Tab-Fans keine Tabs mehr nutzen wollen, weil sie mod4 vorziehen. (Das ist sicher auch noch eine Randpointe: Killerfeature von Tabs: Indentation ist frei wählbar. ~90 % der Leute wählen sowieso 4 und ändern das nie. – Ist jetzt aber natürlich Spekulation.)

1: Wenn man es festlegt, sollte man es wohl tatsächlich auf 8 festlegen.

Wenn ich bei der Einrückung Tabs und Spaces vermische, dann ist es logisch, dass das bei anderen Schrittweiten-Einstellungen zu Problemen führt. Das gilt auch, wenn ich Spaces mit Tabs vermische. Merkst du was?

Das schreibe ich aber glaube ich selbst nicht anders. Mein Argument, das nicht das stärkste ist, zugegeben, ist an der Stelle: Es besteht – im Gegensatz zu Spaces – keinerlei Notwendigkeit, überhaupt Tabs in Quellcode zu setzen. Alle Fehlformatierungen, die sich aus einem Mischmasch ergeben können und die man nicht sehen kann, wenn man die Schrittweite nicht verstellt oder sich nicht nicht-druckbare Zeichen anzeigen lässt, sind vermeidbar.

Ich frage mich dabei halt immer (und das ernsthaft nicht bloß rhetorisch), ob es wirklich so wichtig sein kann, die „Länge“ der Einrückungen optisch individuell definieren zu können, dass man sich dafür all die möglichen Probleme aufhalsen will (auch mit externen Tools, die Code darstellen oder Spalten angeben oder so). Selbst wenn du/ihr das Argument aus dem letzten Absatz nicht anerkennt, opfert man damit zum Beispiel die Fähigkeit, auf eine bestimmte Zeilenlänge schreiben zu können, denn das unterscheidet sich etwa zwischen Tab=2 und Tab=8, also potenziell zwischen zwei Leuten, die am gleichen Code arbeiten, schon recht massiv. Und auch bei einer fließenden Zeilenlänge, wird man irgendwann mal umbrechen müssen – etwa in längeren Kommentarabsätzen.

Ich verstehe nicht, wieso euch gerade die Konfigurierbarkeit an der Stelle so wichtig ist. Ihr könnt auch sonst nichts an der Darstellung verstellen (Plenken der Klammern oder so). Nur bei Tabs geht das halt „zufällig“.

Nein, kann man nicht. Nicht alle IDEs können Textblöcke mit Leerzeichen einrücken. (Ausser, man macht es manuell)

Na ja, du schreibst selbst im Effekt, dass weder Tabs noch Spaces überall funktionieren.

Das ist das einzige Argument, dass ich gelten lassen würde. "Wir müssen uns nun mal auf etwas einigen" macht das eine oder das andere aber nicht besser oder korrekter.

Meinetwegen können wir Kategorien wie „Korrektheit“ gerne weglassen. Ich bilde mir ein, das „pragmatisch“ zu sehen, aber wenn es eine einfache oder korrekte Antwort gäbe, wäre das ja nichts, über das man so schön streiten könnte.

Ich würde auch Tabs nutzen, wenn das in einem verbreiteten Standard stünde. Die Eleganz, ein Zeichen zu haben statt einer Latte von Leerzeichen, erschließt sich mir grundsätzlich durchaus. Das ändert aber nichts daran, dass ich Leerzeichen für praktischer halte.

Mit Leerzeichen kann ich zum Beispiel auch einfach nach \t suchen, um zu gucken, ob die Datei richtig formatiert ist. Wenn keins existiert, passt es. Umgekehrt geht das nicht, weil zu Zeilenbeginn vor dem Content auch ein Tab und dann vier – falsche – Leerzeichen stehen könnten. Die findet man nicht, weil man nicht trivial in einem Regex oder so zwischen falschen und richtigen unterscheiden kann.

Ich könnte deshalb mit Tabs glaube ich nur wirklich bequem arbeiten, wenn ich nicht-druckbare Zeichen auf nicht störende Weise anzeigen lassen könnte. Sonst würde ich spätestens beim Copy-&-Pasten von Fremd-Snippets einen Rappel kriegen.

[erc]

Der einzige Grund der mir gegen Tabs einfällt sind diese 80 Zeichen Begrenzungen, da sich 80 Tabs nunmal nicht gut ausgehen auf einem TTY.

Ist jetzt aber auch nicht so als hätten die IDEs dafür keine Hilfe dabei. Entweder kannst du dir eine Linie einbleden lassen (ist meisten per Default drin) oder hast ein "Lineal" am oberen Rand.

[rkr]

Im Zeitalter von 16:10 Screens wirken 80-Zeichen-Limits ein wenig antiquiert

[Tropi]

Der Haken bei der Diskussion um Space und Tabs ist ja der: Auch die Anhänger der Leerzeichen-Variante benutzen Tabs. Nur lassen sie das dann eben den Editor auf Spaces umwandeln. Mir kann niemand erzählen, das jemand bei einem Code wie dem hier:

class Test {
    public function bla() {
        if (true) {
             echo "foo";
        }
    }
} 

insgesamt 36x auf die Leertaste schlägt (nur fürs Einrücken). Genauso ist es auch beim Löschen/Ausrücken von Code. Wenn die IDE bzw. der Editor das Einrückungsmanagement nicht großteils automatisch machen würde, würden alle nur noch Tabs verwenden. Der einzige Grund der mir gegen Tabs einfällt sind diese 80 Zeichen Begrenzungen, da sich 80 Tabs nunmal nicht gut ausgehen auf einem TTY.

[rkr]

Dem Team ist meine Einstellung egal, denn es arbeitet mit Chr(9).

[Arne Drews]

Wenn man im Team arbeitet sollte man sich halt einigen, ansonsten kann das doch jeder halten, wie er will.

Dann gehörst Du nicht ins Team...

[rkr]

Und was, wenn ich deine Vorgabe nicht mag?

[Arne Drews]

Puh... Das scheint ja doch ne Art Philosophie zu werden.
Also ich nutze zum Einrücken von Code immer konsequent die TAB-Taste, meine IDE macht daraus allerdings intern Spaces (2 oder 4, je nach Sprache bzw. meiner Vorgabe).
Öffne ich die Scripte in einem anderen Editor, habe ich dadurch dieselbe Formatierung, weil ein Space immer ein Space ist, Tab eben nicht.

Und bei welcher IDE bitte kann man das nicht einstellen?!

[rkr]

„Oder dass es eben ein Character ist, der eben dafür da ist, einzurücken.“ Na ja… Da kann man auch sagen, dass Tabulatoren – zumindest ursprünglich – dazu dienen, Text in Tabellenform anzuordnen. Das funktioniert aber nur, wenn die Schrittweite definiert ist, was prinzipbedingt nicht wahnsinnig gut zu „[s]ind [je nach Vorliebe] einstellbar“ passt. Eine Tabelle, die mit Schrittweite 8 erstellt wurde, wird bei Schrittweite 2 nicht mehr hübsch aussehen. Ich möchte deshalb fast behaupten, dass die Verwendung zum Einrücken von Code am Zeilenbeginn eine Zweckentfremdung ist und die Bezeichnung der persönlichen Anpassbarkeit der Schrittweite als Feature erst recht. Das ergibt im – wie gesagt zumindest ursprünglichen – Kontext der Funktion von Tabs eben nicht wirklich viel Sinn. Das erkennt man auch wunderbar daran, dass alle Welt sagt, dass Tabs nur für die initiale Einrückung genutzt werden dürfen. Das ist maximal ein Teil dessen, wozu Tabs gedacht sind/waren.

Leerzeichen sind wohl ursprünglich auch mal nicht dazu da gewesen, um irgendwas einzurücken? Kann man da nicht sagen, dass eine Einrückung mit Leerzeichen im traditionellen Sinne einer Zweckentfremdung gleichkommt?

„Es ist nicht möglich, versehentlich "falsch" einzurücken.“ Leute schaffen es so oder so, falsch einzurücken. Ich habe das schon mehrfach erzählt, aber sogar in den offiziellen PSR-Standards hatten sie es geschafft, mit drei Spaces einzurücken, obwohl sie explizit vier definiert haben. (Böh, das ist derzeit tatsächlich noch immer so: https://github.com/php-fig/fig-stand....md#6-closures. Man beachte die Anzahl der Leerzeichen vor „// body“ im zweiten Codeblock des Abschnitts…) Ist das ein Argument für Tabs? Es klingt so, aber: Nein, ist es meines Erachtens nicht. Dazu habe ich schon zu viel seltsam eingerückten Code im Browser (standardmäßig Tab=8) gesehen. Der wurde von wem mit Tab=4 erstellt, aber die Person hat da Code reinkopiert, der Spaces nutzte oder was auch immer. Das sah dann im Editor richtig aus, ist aber eben falsch. Das ist natürlich auch kein Argument gegen Tabs, weil es sich mehr oder weniger umdrehen lässt, aber rein pragmatisch gesprochen: Tabs geben den Leuten eine Chance mehr, es falsch zu machen, und diese Chance werden sie nutzen. Auf das Space als Character lässt sich halt schwerlich verzichten, aber das Tab ist komplett fakultativ. Bei reiner Nutzung von Spaces hat man zudem eben die Chance, zu sehen, wenn etwas falsch eingerückt ist.

Habe ich bei Tabs auch. Wenn ich bei der Einrückung Tabs und Spaces vermische, dann ist es logisch, dass das bei anderen Schrittweiten-Einstellungen zu Problemen führt. Das gilt auch, wenn ich Spaces mit Tabs vermische. Merkst du was?
Tabs sind direkter. Wenn ich einen Tab zu viel oder zu wenig setze, dann sehe ich das sofort. Bei Leerzeichen ist das eben nicht so.

„[Tabs] [s]ind mit fast allen IDEs perfekt kompatibel (Spaces nicht).“ Die Aussage kann man umdrehen.

Nein, kann man nicht. Nicht alle IDEs können Textblöcke mit Leerzeichen einrücken. (Ausser, man macht es manuell)

Mal ganz blöd gesagt, wie ich es im letzten Post auch schon angedeutet habe: Wenn man einen anerkannten (was auch immer das heißen soll) Coding-Standard nutzen will, dann ist das PSR-Zeug vermutlich nicht die schlechteste Wahl, weil es da etliche große Projekte der PHP-Welt halt einfach mal versucht haben, sich auf was zu einigen (bla bla ). Die haben 4 Spaces definiert. Wenn man da jetzt mit der Einstellung rangeht „okay, ich finde das weitestgehend gut, was die machen, aber ich nutze trotzdem Tabs“, führt das die Anstrengung eben etwas ad absurdum, weil dann eben niemand den eigenen Code PSR-kompatibel editieren kann, weil jeder trotzdem immer erst mal gucken muss, ob die Datei nun Tabs oder Spaces will. Das ist in gewisser Weise unnötiges Mikromanagement, das da dann verlangt wird. (Das ist auch nicht in jedem Editor einfach mal so zu machen. Das wird teilweise echt nervig und man muss Formatier-Tools über den Code rüberrödeln, bevor man einen Push-Request erstellt oder whatever. Okay, ist umgekehrt natürlich auch so.) Da sollte man dann vielleicht einfach mal in den sauren Apfel beißen, weil das kollektiv möglicherweise Sinn ergibt, auch wenn das den eigenen Ansichten nicht entspricht. (Ich finde zum Beispiel auch die Regel schwachsinnig, in Methodensignaturen jeden Parameter auf eine eigene Zeile schreiben zu müssen, sobald die Liste der Parameter die Zeile länger als 80 Zeichen werden lässt, weil das einfach beim Refaktorieren/Umbenennen von Parametern nur dämlich wird, weil man neu „ausmessen“ muss.)

Das ist das einzige Argument, dass ich gelten lassen würde. "Wir müssen uns nun mal auf etwas einigen" macht das eine oder das andere aber nicht besser oder korrekter.

[erc]

Spaces zum Einrücken sind mir schon immer ein Rätsel. Code ist doch kein ASCII-Art, ist doch völlig wurscht ob der nun mit 2, 4 oder 8 Zeichen eingerückt dargestellt wird. Mit Tabs kann sich das jeder einstellen wie er will, mit Spaces ist es fest und erfordert immer ein explizites Einstellen der Editoren.
Ich benutzt für kleine Änderungen z.T. ein "einfachen" Editor (Ultraedit), da macht sich das bei mehreren Projekten besonders toll.

[Arne Drews]

Rot geht gar nicht, damit bist Du schon mal raus...

Aber im Ernst, ich verstehe die Diskussion um die Tabs/Spaces nicht.
Wenn man im Team arbeitet sollte man sich halt einigen, ansonsten kann das doch jeder halten, wie er will.
Ich persönlich nutze in eigenen Projekten 1 Tab = 4Spaces für PHP und 1 Tab = 2 Spaces für JS, CSS und HTML/XML.
Lässt sich alles über die IDE einstellen, und ich behaupte mal das geht mit jede ( sinnvollen ) IDE.


EDIT

Dazu habe ich schon zu viel seltsam eingerückten Code im Browser ( standardmäßig Tab=8 ) gesehen.

Das fällt natürlich flach, wenn der Quelltext minimiert ausgegeben wird...

[mermshaus]

„Naja, und dass bei (4-width vorausgesetzt) 75% whitespaces wegfallen.“ Okay, das ist so. Bei Schrittweite 8 ist es sogar noch mehr.

„Oder dass es eben ein Character ist, der eben dafür da ist, einzurücken.“ Na ja… Da kann man auch sagen, dass Tabulatoren – zumindest ursprünglich – dazu dienen, Text in Tabellenform anzuordnen. Das funktioniert aber nur, wenn die Schrittweite definiert ist, was prinzipbedingt nicht wahnsinnig gut zu „[s]ind [je nach Vorliebe] einstellbar“ passt. Eine Tabelle, die mit Schrittweite 8 erstellt wurde, wird bei Schrittweite 2 nicht mehr hübsch aussehen. Ich möchte deshalb fast behaupten, dass die Verwendung zum Einrücken von Code am Zeilenbeginn eine Zweckentfremdung ist und die Bezeichnung der persönlichen Anpassbarkeit der Schrittweite als Feature erst recht. Das ergibt im – wie gesagt zumindest ursprünglichen – Kontext der Funktion von Tabs eben nicht wirklich viel Sinn. Das erkennt man auch wunderbar daran, dass alle Welt sagt, dass Tabs nur für die initiale Einrückung genutzt werden dürfen. Das ist maximal ein Teil dessen, wozu Tabs gedacht sind/waren.

„Es ist nicht möglich, versehentlich "falsch" einzurücken.“ Leute schaffen es so oder so, falsch einzurücken. Ich habe das schon mehrfach erzählt, aber sogar in den offiziellen PSR-Standards hatten sie es geschafft, mit drei Spaces einzurücken, obwohl sie explizit vier definiert haben. (Böh, das ist derzeit tatsächlich noch immer so: https://github.com/php-fig/fig-stand....md#6-closures. Man beachte die Anzahl der Leerzeichen vor „// body“ im zweiten Codeblock des Abschnitts…) Ist das ein Argument für Tabs? Es klingt so, aber: Nein, ist es meines Erachtens nicht. Dazu habe ich schon zu viel seltsam eingerückten Code im Browser (standardmäßig Tab=8) gesehen. Der wurde von wem mit Tab=4 erstellt, aber die Person hat da Code reinkopiert, der Spaces nutzte oder was auch immer. Das sah dann im Editor richtig aus, ist aber eben falsch. Das ist natürlich auch kein Argument gegen Tabs, weil es sich mehr oder weniger umdrehen lässt, aber rein pragmatisch gesprochen: Tabs geben den Leuten eine Chance mehr, es falsch zu machen, und diese Chance werden sie nutzen. Auf das Space als Character lässt sich halt schwerlich verzichten, aber das Tab ist komplett fakultativ. Bei reiner Nutzung von Spaces hat man zudem eben die Chance, zu sehen, wenn etwas falsch eingerückt ist.

„[Tabs] [s]ind mit fast allen IDEs perfekt kompatibel (Spaces nicht).“ Die Aussage kann man umdrehen.

Mal ganz blöd gesagt, wie ich es im letzten Post auch schon angedeutet habe: Wenn man einen anerkannten (was auch immer das heißen soll) Coding-Standard nutzen will, dann ist das PSR-Zeug vermutlich nicht die schlechteste Wahl, weil es da etliche große Projekte der PHP-Welt halt einfach mal versucht haben, sich auf was zu einigen (bla bla ). Die haben 4 Spaces definiert. Wenn man da jetzt mit der Einstellung rangeht „okay, ich finde das weitestgehend gut, was die machen, aber ich nutze trotzdem Tabs“, führt das die Anstrengung eben etwas ad absurdum, weil dann eben niemand den eigenen Code PSR-kompatibel editieren kann, weil jeder trotzdem immer erst mal gucken muss, ob die Datei nun Tabs oder Spaces will. Das ist in gewisser Weise unnötiges Mikromanagement, das da dann verlangt wird. (Das ist auch nicht in jedem Editor einfach mal so zu machen. Das wird teilweise echt nervig und man muss Formatier-Tools über den Code rüberrödeln, bevor man einen Push-Request erstellt oder whatever. Okay, ist umgekehrt natürlich auch so.) Da sollte man dann vielleicht einfach mal in den sauren Apfel beißen, weil das kollektiv möglicherweise Sinn ergibt, auch wenn das den eigenen Ansichten nicht entspricht. (Ich finde zum Beispiel auch die Regel schwachsinnig, in Methodensignaturen jeden Parameter auf eine eigene Zeile schreiben zu müssen, sobald die Liste der Parameter die Zeile länger als 80 Zeichen werden lässt, weil das einfach beim Refaktorieren/Umbenennen von Parametern nur dämlich wird, weil man neu „ausmessen“ muss.)

Ich mag den Fahrradschuppen übrigens in rot.

[rkr]

Das und nix anderes. Tabs an die Macht!

Naja, und dass bei (4-width vorausgesetzt) 75% whitespaces wegfallen.
Oder dass es eben ein Character ist, der eben dafür da ist, einzurücken.
Es ist nicht möglich, versehentlich "falsch" einzurücken.
Sind einstellbar.
Sind mit fast allen IDEs perfekt kompatibel (Spaces nicht).

[ApoY2k]

Tabs haben imho den Vorteil, dass jeder Entwickler die Darstellung des Codes dem eigenen Geschmack anpassen kann.

Das und nix anderes. Tabs an die Macht!