coding guidelines

[Phpyton]

Tabs halte ich für Humbug.

Ich auch. Beim einen OS sind das 4 Spaces beim anderen 8 Spaces.

[Forumsgast]

und ich entgehe dem problem, da PHPStorm Tabs in Spaces umwandelt...

LG

[Forumsgast]

Was man bei so gut wie jeder IDE einstellen kann...

[Forumsgast]

Hallöchen,

Ich auch. Beim einen OS sind das 4 Spaces beim anderen 8 Spaces.

So ziemlich jede IDE bietet diesbezüglich doch Einstellungsmöglichkeiten. Tabs haben imho den Vorteil, dass jeder Entwickler die Darstellung des Codes dem eigenen Geschmack anpassen kann. Na ja, dieses Thema wurde schon bis zur Unendlichkeit durchdiskutiert und eine klare Einigung ist bisweilen nicht in Sicht

Viele Grüße,
lotti

[Forumsgast]

Es wäre auch echt zu einfach, wenn zum Beispiel Leute, die im Grunde PSR nutzen, nicht in kleinen, aber für alle Beteiligten sehr nervigen Details davon abweichen würden.

Edit: ↓ Ich bin sehr froh, dass es nicht so was wie „Whitespace-vor-geschweifter-Klammer“ als Zeichen gibt, das sich Leute dem eigenen Geschmack nach auf \n oder \r\n oder " " (Space) einstellen können.

[Forumsgast]

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!

[Forumsgast]

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).

[Forumsgast]

„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.

[Forumsgast]

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...

[Forumsgast]

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.

[Forumsgast]

„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.

[Forumsgast]

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?!

[Forumsgast]

Und was, wenn ich deine Vorgabe nicht mag?

[Forumsgast]

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...

[Forumsgast]

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