C++ Welche Tabulatorbreite?

[DrGreenthumb]

tolulol schrieb:

DrGreenthumb schrieb:

Tabs darf man nur benutzen wenn (...)

wer bistn du? die tab-polizei?

Nö, an sich ist mir das sogar ziemlich egal und ich stör mich nicht mal groß daran wenn ich eine Datei editiere wo ein wilder Mischmasch von Tabs & Leerzeichen drin ist.

Aber ein Welt in der nur noch Leerzeichen benutzt werden, wäre trotzdem die bessere

[Blue-Tiger]

DrGreenthumb schrieb:

Blue-Tiger schrieb:

Sprich: was nicht Einrueckung ist, sondern zum "Code-Formattieren" gehoert, mach ich mit Spaces damit es auch bei anderen Tab-Widths noch vernuenftig ausschaut

das ist ein guter Kompromiss... nur stelle ich mir das sehr mühselig vor oder passiert das automatisch? I.d.R. werden im Tab-Modus solche Leerstellen ja mit Tabs aufgefüllt und nur am Ende um Leerzeichen ergänzt.

Ich kenne keine Editoren, die solche "Alignment"-Einrueckungen vornehmen. Also mach ich das immer von Hand.

Das mit dem Auskommentieren stimmt schon, aber nur deswegen würde ich nicht Tabs benutzen. Dann lieber den Editor so einstellen das er die Kommentare auch bei Leerzeichen so ersetzend einfügt

Meinst du sowas wie "in den Einfuege-Modus umschalten" (die Einfg-Taste auf der Tastatur) oder gibts Editoren, die sowas automatisch koennen?

[DrGreenthumb]

Blue-Tiger schrieb:

Ich kenne keine Editoren, die solche "Alignment"-Einrueckungen vornehmen. Also mach ich das immer von Hand.

oha... nee danke, ich drück dann doch lieber einfach Enter

Meinst du sowas wie "in den Einfuege-Modus umschalten" (die Einfg-Taste auf der Tastatur) oder gibts Editoren, die sowas automatisch koennen?

Naja, in Emacs oder Vim könnte man das natürlich scripten. Wäre mir jetzt aber nicht den Aufwand wert.

[rüdiger]

Blue-Tiger schrieb:

Also mach ich das immer von Hand.

Blue-Tiger schrieb:

Das das Zeilen-Auskommentieren immer die Blockstruktur optisch kaputt macht, stoert mich immer ein bisschen. Geht das nur mir so?
(man kann logisch argumentieren dass auskommentierte Zeilen sehr selten vorkommen, etc. aber hin & wieder kommt das bei mir einfach vor)

Gibt schlimmeres. Aber der Emacs kann es zB richtig einrücken.

(und es kommt so selten vor, dass ich nicht per Hand einrücken würde, nur damit ich für einen Fall Tabs habe :p)

[thordk]

rüdiger schrieb:

thordk schrieb:

kommentiert genauso toll und egal, was für nen einrückungstyp verwendet wird, das ganz kann schlicht nicht zerfetzt werden.

Ist natürlich die Frage, ob man sich seinen Einrückungsstil von Tabs diktieren lassen will

ich verwende einfach gar keinen einrückungsstil. find code, der völlig auf alignment verzichtet auch wesentlich übersichtlicher.
hab viele kollegen, die z.b. sowas machen

void somefunc()
{
   RandomClass  rc;
   int          foo;
   double       bar;
   // code

find ich unglaublich unübersichtlich

[groovemaster]

Bouncer schrieb:

hab ich schon angedeutet, ansonsten --> http://www.adamspiers.org/computing/why_no_tabs.html

Deine "Andeutungen" entbehren aber jeglicher Grundlage. Und den Artikel hinter deinem Link brauche ich mir auch nicht durchlesen.

Why I prefer ...

Das sagt schon alles.

Spasseshalber habe ich mir den Artikel trotzdem mal angeschaut.

Punkt 1

It's less portable, since different editors/pagers render a hard tab as varying numbers of spaces ...

Vollkommen belanglos, da, wie ich bereits sagte, hierdurch lediglich Unterschiede in der Anzeige entstehen. Einrückung wird aber nicht zerstört. Eigentlich ist dies eher ein Argument gegen Spaces. Denn du musst im Editor immer die jeweilige Tab Breite, abhängig vom jeweiligen Quellcode, einstellen, damit die Einrückung bei Änderungen oder Erweiterungen konsistent bleibt. Smarte Editoren können das womöglich automatisch erkennen, bei echten Tabs sind solche Spielereien gar nicht notwendig.

Punkt 2

It makes context/unified diffs far harder to read ... UPDATE: I just found out that diff provides two possible workarounds ...

Geschenkt. Ist aber schon lustig, dass der Autor dies als "workaround" bezeichnet.

Punkt 3

It makes re-indenting sections more difficult; if for example you try to shift a block two columns right, it might have no effect on lines starting with tabs ...

Keine Ahnung, mit welchen Werkzeugen der arbeitet. Aber klingt nach "mir fehlen die Argumente, also erschaffe ich mir welche künstlich". Totaler Käse. Wenn überhaupt, ist das ein Problem des Editors und nicht von Spaces oder Tabs.

Punkt 4

Tabs aren't just used at the beginning of lines ...

Wer auf ein und dieselbe Tab Breite setzt, hat es auch nicht besser verdient, wenn die Einrückung zerstört wird. Da kann ich genauso gut darauf verzichten und sage Tab Width = 0. Ein weiteres unsinniges Argument. thordk hat ja schon gezeigt, wie vernünftig kommentiert wird. Ich habe mir übrigens abgewöhnt, an das Ende von Codezeilen Kommentare zu setzen. Darüber ist es genauso übersichtlich, wenn nicht sogar übersichtlicher. Und verursacht eben keine Tab Probleme. Und wie ebenfalls erwähnt würde, Tabs sind für Einrückung sinnvoll, nicht fürs Ausrichten.

Punkt 5

There can be problems even if tabs only occur at the beginning of lines ... If someone else tries to view this code setting their editor/pager tab width to 4, first level lines will be indented 5 columns, second level lines 6 columns, third level lines 11 columns ... oops!

Sry, aber ist dieser Kerl wirklich so dumm oder tut der nur so?

Punkt 6

The same argument can be applied to spaces. Want to view source with 2 column indents using 4 column indents? No problem ...

Willst du Quellcode mit "echten" Tabs mit einer Einrückung von 4 Spalten sehen? Kein Problem. Sag deinem Editor einfach Tab width = 4. Fertig.

Punkt 7

Want to change source with 8 column indents to use 3 column indents?

Wozu sollte ich sowas wollen? Mit "echten" Tabs gibt es keine Notwendigkeit, meinen Quellcode zu ändern. Das ist alles eine Einstellungssache des Editors.

Bouncer schrieb:

vielleicht hast du schon mal ein code snippet in dieses board gepostet, dann weisst du, was ich meine. es ist sicher kein problem, wenn man daheim ganz allein in seinem hobbykeller programmiert. aber wehe man tauscht quelltexte mit anderen aus. spätestens dann werden echte tabs zu einem ärgernis

Das kannst du von mir aus auch noch tausendmal wiederholen, ohne Begründung ist diese Aussage wertlos.

Sry Bouncer, du solltest dir schon selbst mal ein paar Gedanken dazu machen, anstatt dem (Irr)glauben anderer zu glauben. Letztendlich ist es egal, ob du zu Spaces oder Tabs greifst. Wichtig ist lediglich, nicht beides zu vermischen und nicht einer fixen Tab Breite zu vertrauen. _Dadurch_ entstehen Probleme, nicht durch die fadenscheinigen Argumente, die du uns verkaufen willst.

DrGreenthumb schrieb:

Wie rücken denn die Tab-Verfechter sowas ein:

void func(int a,
          int b)
{
}

void func(
    int a,
    int b)
{
}

DrGreenthumb schrieb:

Tabs darf man nur benutzen wenn man genau weiß was man tut.

Das würde ich sogar unterschreiben. Wer nicht versteht, wie Einrückung bzw. Tabs funktionieren, soll Quelltexte weiterhin dot matrix layouten.

[Lost in Space]

groovemaster schrieb:

Letztendlich ist es egal, ob du zu Spaces oder Tabs greifst. Wichtig ist lediglich, nicht beides zu vermischen und nicht einer fixen Tab Breite zu vertrauen.

warum sollte man sich so einschränken und keine tabs mit spaces mischen? meinst du ich will mich beim programmieren darauf konzentrieren, wann ich tabs und wo ich spaces verwenden darf? das ist ja wohl total albern.
ich stelle meinen editor einfach auf 'no hard tabs' und dann kann ich mischen, wie ich lustig bin. mein editor haut dann einfach bei 'tab' ein paar spaces rein und bei anderen sieht der code immer noch so aus, wie ich ihn geschrieben habe.
ich will dir nichts einreden, du sollst mit deinen tabs glücklich werden, wenn du die so toll findest. bestimmt arbeitest du mit einem editor, der dir tabs bzw. spaces anzeigt und bestimmt tauscht du nie quelltexte mit anderen aus, oder? bei mir springt der cursor einfach nach rechts, wenn ich tab drücke und es entsteht ein breiter leerraum, den man nicht von einigen spaces unterscheiden kann. und falls du eines tages mal in einem team arbeitest, wirst auch du von tabs abstand nehmen.

[Lost in space again]

@groovemaster: vielleicht wäre das *die* programmiersparche für dich: --> http://compsoc.dur.ac.uk/whitespace/

[Blue-Tiger]

DrGreenthumb schrieb:

Blue-Tiger schrieb:

Ich kenne keine Editoren, die solche "Alignment"-Einrueckungen vornehmen. Also mach ich das immer von Hand.

oha... nee danke, ich drück dann doch lieber einfach Enter

Ich hab grad gestest, Code::Blocks macht das automatisch.
Aus folgender Zeile:

Color c = traceRay(precalculatedRays[pos], 
	                   &tmp, 0, INITIAL_REFRACTION_INDEX);

hab ich vor INITIAL_REFRACTION_INDEX umgebrochen, und C::B hat daraus automatisch folgende Einrueckung gemacht:

[i]<tab>[/i]Color c = traceRay(precalculatedRays[pos], 
[i]<tab>[/i]...................&tmp, 0,
[i]<tab>[/i]...................INITIAL_REFRACTION_INDEX);

[groovemaster]

Lost in Space schrieb:

warum sollte man sich so einschränken und keine tabs mit spaces mischen? meinst du ich will mich beim programmieren darauf konzentrieren, wann ich tabs und wo ich spaces verwenden darf? das ist ja wohl total albern.

Nee, lediglich dieser Kommentar ist albern. Warum?

Lost in Space schrieb:

ich stelle meinen editor einfach auf 'no hard tabs' und dann kann ich mischen, wie ich lustig bin.

Deshalb. Wenn du keine echten Tabs verwendest, mischst du auch nicht. Hier geht es um die Zeichen Tab (HT) bzw. Space, nicht die Tasten.

Lost in Space schrieb:

bestimmt arbeitest du mit einem editor, der dir tabs bzw. spaces anzeigt und bestimmt tauscht du nie quelltexte mit anderen aus, oder?

Falsch gedacht.

Lost in Space schrieb:

bei mir springt der cursor einfach nach rechts, wenn ich tab drücke und es entsteht ein breiter leerraum, den man nicht von einigen spaces unterscheiden kann.

Toll. Wer hätte das gedacht.

Lost in Space schrieb:

und falls du eines tages mal in einem team arbeitest, wirst auch du von tabs abstand nehmen.

Erzähl mir nichts, von dem du scheinbar keine Ahnung hast. Beruflich habe ich nach Konvention bisher nur mit Tabs gearbeitet. Und ich habe auch nichts gegen Spaces. Nur was gegen Leute die glauben, sie seien vorteilhafter. Das ist einfach totaler Käse.

[Bouncer]

groovemaster schrieb:

Lost in Space schrieb:

ich stelle meinen editor einfach auf 'no hard tabs' und dann kann ich mischen, wie ich lustig bin.

Deshalb. Wenn du keine echten Tabs verwendest, mischst du auch nicht. Hier geht es um die Zeichen Tab (HT) bzw. Space, nicht die Tasten.

ich denke du weisst wie das gemeint war.

Lost in Space schrieb:

Und ich habe auch nichts gegen Spaces. Nur was gegen Leute die glauben, sie seien vorteilhafter. Das ist einfach totaler Käse.

dann erklär mir doch mal, wie du das mit den tabs und spaces handlest beim programmieren. da du, wie du schriebst, keinen speziellen editor verwendest, der dir tab/spaces anzeigt: wie achtest du darauf, dass du nicht doch aus versehenen mal mischst? benutzt du ein spezielles tool, das dich dabei unterstützt? und: welchen vorteil bringt dir dieser mehraufwand?

[__Stefan__]

Ich benutze 2 Spaces

[Blue-Tiger]

Bouncer schrieb:

Lost in Space schrieb:

Und ich habe auch nichts gegen Spaces. Nur was gegen Leute die glauben, sie seien vorteilhafter. Das ist einfach totaler Käse.

dann erklär mir doch mal, wie du das mit den tabs und spaces handlest beim programmieren. da du, wie du schriebst, keinen speziellen editor verwendest, der dir tab/spaces anzeigt: wie achtest du darauf, dass du nicht doch aus versehenen mal mischst? benutzt du ein spezielles tool, das dich dabei unterstützt? und: welchen vorteil bringt dir dieser mehraufwand?

Ich persoenlich geh davon aus, dass meine normalen Entwicklertools (mein Editor) das richtig machen. Dazu muss ich mir gar keine Tabs/Spaces anzeigen lassen. Im Normalfall merkt man Diskrepanzen auch ziemlich schnell (wenn man z. B. mit dem Cursor durch den Text scrollt), aber ich find eigentlich nie falsch gesetzte Tabs/Spaces. Die paar Male, wo ich - gewollt oder nur als Nebenprodukt - die komplette Einrueckungen meiner Files ueberprueft hab, waren die Tabs/Spaces auch immer korrekt gesetzt. also hab ich keinen Grund davon auszugehen, dass meine Tools hier versagen.

Das Ganze ist uebrigens kein Mehraufwand, da es wie gesagt meine IDE fuer mich korrekt macht. Ich ruecke mit Tabs ein, und die IDE rueckt nachfolgende Zeilen automatisch weiter mit Tabs ein. Ich aligne irgendwas mit Spaces und meine IDE sorgt dafuer, dass nachfolgende Zeilen gleich aligned sind.

Der Nutzen fuer mich ist wie weiter oben gesagt, dass ichs nicht mag, dass das auskommentieren von Zeilen mir mein Layout kaputt macht. Und ich denke fuer andere, die mit meinem Code arbeiten ists ganz nett, wenn sie ihre eigenen Tab-Widths festlegen koennen, ohne dass das Layout einbricht.

[No TABs - NEVER!!!]

Blue-Tiger schrieb:

Das Ganze ist uebrigens kein Mehraufwand.

der mehraufwand besteht allein darin, dass man darauf achten muss, wo tabs und wo spaces platziert werden dürfen. bei einem 'tab-losen design' ist diese frage schlicht und ergreifend nicht vorhanden. du sagtes selber, dass du manchmal den cursor vertikal durch den text bewegst, um unstimmigkeiten zu entdecken. auch das kann sich ein 'nicht-tabber' komplett sparen.

[Blue-Tiger]

No TABs - NEVER!!! schrieb:

Blue-Tiger schrieb:

Das Ganze ist uebrigens kein Mehraufwand.

der mehraufwand besteht allein darin, dass man darauf achten muss, wo tabs und wo spaces platziert werden dürfen. bei einem 'tab-losen design' ist diese frage schlicht und ergreifend nicht vorhanden. du sagtes selber, dass du manchmal den cursor vertikal durch den text bewegst, um unstimmigkeiten zu entdecken. auch das kann sich ein 'nicht-tabber' komplett sparen.

Darauf zu achten, wo tabs und wo spaces hinkommen ist kein Mehraufwand, da beides logisch getrennte Einsatzzwecke hat. Genauso wie ich Bremse und Kupplung nicht verwechsle, ich "weiss" einfach instinktiv, wann was benutzt wird.

Bzgl. Scrolling hast du mich falsch verstanden:
Ich scrolle den Cursor nicht vertikal durch den Text, um Unstimmigkeiten zu entdecken, sondern schlicht um in die naechste Zeile zu gelangen. Wenn ich nun Einrueckungsfehler haette oder z. B. per Copy & Paste Code von anderswo uebernehme, wuerde mir das dabei natuerlich auffallen Aber wie gesagt, mir faellt da nie was auf, also geh ich davon aus, dass meine Tools die Einrueckung korrekt hinkriegen.

[Globox]

Blue-Tiger schrieb:

Darauf zu achten, wo tabs und wo spaces hinkommen ist kein Mehraufwand, da beides logisch getrennte Einsatzzwecke hat. Genauso wie ich Bremse und Kupplung nicht verwechsle, ich "weiss" einfach instinktiv, wann was benutzt wird.

und wer sich das nicht antun will, fährt eben ein auto mit automatikgetriebe.

[groovemaster]

Bouncer schrieb:

ich denke du weisst wie das gemeint war.

Wenn das Ironie gewesen sein soll, war's einfach nur schlecht. Aber das mag auch daran liegen, dass ich Unregs nicht wirklich ernst nehme. Sry, mein Fehler.

Lost in Space schrieb:

dann erklär mir doch mal, wie du das mit den tabs und spaces handlest beim programmieren. da du, wie du schriebst, keinen speziellen editor verwendest, der dir tab/spaces anzeigt: wie achtest du darauf, dass du nicht doch aus versehenen mal mischst?

Was soll ich denn "aus versehenen" machen? Ich sage meiner IDE, sie soll echte Tabs verwenden. Fertig.

Lost in Space schrieb:

welchen vorteil bringt dir dieser mehraufwand?

Welcher Mehraufwand? Du implizierst etwas, was nicht der Realität entspricht.

No TABs - NEVER!!! schrieb:

der mehraufwand besteht allein darin, dass man darauf achten muss, wo tabs und wo spaces platziert werden dürfen.

Nein, das muss man nicht. Denn wie schon erwähnt, Einrückung und Ausrichtung funktionieren unabhängig.
Aber mal davon abgesehen, Ausrichtung verwende ich sowieso kaum. Folgender Code

Color c = traceRay(precalculatedRays[pos],
                       &tmp, 0, INITIAL_REFRACTION_INDEX);

sofern man ihn nicht in einer Zeile unterbringen kann, sieht bei mir zB so aus

Color c = traceRay(
        precalculatedRays[pos],
        &tmp,
        0,
        INITIAL_REFRACTION_INDEX);

Auch wenn es meine persönliche Meinung ist, sein Layout strikt auf Einrückung zu trimmen, verbessert die Optik und Übersichtlichkeit.

[Bouncer]

groovemaster schrieb:

Bouncer schrieb:

ich denke du weisst wie das gemeint war.

Wenn das Ironie gewesen sein soll, war's einfach nur schlecht. Aber das mag auch daran liegen, dass ich Unregs nicht wirklich ernst nehme. Sry, mein Fehler.

kein problem, als registrierter wurde ich auch nie ernst genommen. ausserdem diskutieren wir hier nicht darüber, warum groovemaster die boarduser in zwei klassen unterteilt.

groovemaster schrieb:

Lost in Space schrieb:

dann erklär mir doch mal, wie du das mit den tabs und spaces handlest beim programmieren. da du, wie du schriebst, keinen speziellen editor verwendest, der dir tab/spaces anzeigt: wie achtest du darauf, dass du nicht doch aus versehenen mal mischst?

Was soll ich denn "aus versehenen" machen? Ich sage meiner IDE, sie soll echte Tabs verwenden. Fertig.

deine IDE kann aber keine tabs verwenden, wo sie nicht passen würden. es sei denn, sie schert sich einen dreck um deine formatierung. das wär' aber 'ne schlechte IDE.

groovemaster schrieb:

Lost in Space schrieb:

welchen vorteil bringt dir dieser mehraufwand?

Welcher Mehraufwand? Du implizierst etwas, was nicht der Realität entspricht.

der mehraufwand besteht darin, dass du bewusst tabs oder spaces verwenden musst. auch wenn es dir in fleisch und blut übergegangen ist, wie das fahren eines autos mit schaltgetriebe, so ist es dennoch ein mehraufwand, auf den 'non-tab user' getrost verzichten können.

groovemaster schrieb:

Color c = traceRay(
        precalculatedRays[pos],
        &tmp,
        0,
        INITIAL_REFRACTION_INDEX);

Auch wenn es meine persönliche Meinung ist, sein Layout strikt auf Einrückung zu trimmen, verbessert die Optik und Übersichtlichkeit.

ich formatiere oft so ähnlich, allerdings sieht es bei mir eher so aus:

Color c = traceRay (precalculatedRays[pos],
                    &tmp,
                    0,
                    INITIAL_REFRACTION_INDEX);

wie du unschwer erkennen kannst, sind die 3 letzten zeilen abhängig von der länge der erste bis zur öffnenden klammer. das sind zufälligerweise 20 zeichen, wenn jemand seine tab-width auf '3' eingestellt hat, hat er schon mal die popokarte gezogen.

btw: hey, hab gerade beim kopieren gemerkt: dein code-beispiel war mit spaces formatiert. woher dieser sinneswandel

[groovemaster]

Bouncer schrieb:

kein problem, als registrierter wurde ich auch nie ernst genommen. ausserdem diskutieren wir hier nicht darüber, warum groovemaster die boarduser in zwei klassen unterteilt.

Mache ich nicht. Nur haben sich solche in der Vergangenheit leider immer wieder als Problem herausgestellt. Und am Tonfall kann man dann recht gut einschätzen, wer da entsprechenden Beitrag verfasst hat. Generell habe ich nichts gegen Unregs, nur betrachte ich sie erstmal recht kritisch. Wahrscheinlich hast du hier noch zu wenig gesehen, um eine Beurteilung abgeben zu können. Deinen persönlichen Angriff übersehe ich jetzt mal grosszügig, das solltest du dir aber für die Zukunft abgewöhnen.

Bouncer schrieb:

deine IDE kann aber keine tabs verwenden, wo sie nicht passen würden.

Das ist schon klar. Aber nochmal, Einrückung und Ausrichtung sind logisch zu trennen.

Bouncer schrieb:

der mehraufwand besteht darin, dass du bewusst tabs oder spaces verwenden musst.

Das ist aber kein Mehraufwand, der sich zeitlich oder aktionstechnisch widerspiegelt. OK, wer seeeehr weit ausrichtet, spart u.U. ein paar Tastendrücke. Hier ist dann wieder die IDE gefragt, ob sie das clever lösen kann. Theoretisch entstehen durch echte Tabs keine Nachteile. Zur Verdeutlichung mal folgendes Beispiel mit Tab Breite von 5:

<tab>Color c = traceRay(precalculatedRays[pos],
<tab><tab><tab><tab>....&tmp,
<tab><tab><tab><tab>....0,
<tab><tab><tab><tab>....INITIAL_REFRACTION_INDEX);

So sieht die Eingabe aus.

Eine clevere IDE macht daraus folgendes:

<tab>Color c = traceRay(precalculatedRays[pos],
<tab>...................&tmp,
<tab>...................0,
<tab>...................INITIAL_REFRACTION_INDEX);

Du hast weder Mehraufwand noch Nachteile. Aber halt die Vorteile durch echte Tabs, wie der nicht fixen Einrückung. Aber wie schon gesagt, solche Spielereien mache ich sowieso nicht, da solch eine Ausrichtung imo weniger übersichtlich ist.

Bouncer schrieb:

auf den 'non-tab user' getrost verzichten können.

Das ist aber, wie oben beschrieben, kein Argument gegen Tabs. Dafür hast du ohne echte Tabs "Mehraufwand" an anderen Stellen. Allerdings können auch hier clevere IDEs helfen, wenn auch nur bzgl. der Anzeige. Willst du ein Fremdmodul in ein Projekt eingliedern, welches auf einer anderen Tab Breite basiert, musst du trotzdem konvertieren.

Bouncer schrieb:

wie du unschwer erkennen kannst, sind die 3 letzten zeilen abhängig von der länge der erste bis zur öffnenden klammer. das sind zufälligerweise 20 zeichen, wenn jemand seine tab-width auf '3' eingestellt hat, hat er schon mal die popokarte gezogen.

Du scheinst es immer noch nicht zu verstehen, Einrückung und Ausrichtung sind zwei verschiedene Dinge.

Bouncer schrieb:

btw: hey, hab gerade beim kopieren gemerkt: dein code-beispiel war mit spaces formatiert. woher dieser sinneswandel

Das Forum bietet nun mal nur "4 Leerzeichen" zur Einrückung. Das ist dir womöglich entgangen.

[rüdiger]

*patsch* Natürlich sind TABs in Ordnung. Wie konnten wir nur so blind sein. Man braucht halt nur spezielle IDEs und muss sich darüber ein bisschen den Kopf zerbrechen. Warum haben wir Deppen nur den einfachen Weg benutzt?

btw. Macht TAB in eurer IDE einen Tabulator? Bei meiner IDE (Emacs) bedeutet TAB indent und das ist auch gut so imho.