dedlfix: Tabs oder Spaces?

180

Tabs oder Spaces?

  1. 0
  2. 1
    1. 0
      1. 0
        1. 0
          1. 0
            1. 0
              1. 0
                1. 0
          2. 1
            1. 2
              1. 0
                1. 0
                  1. 0
                    1. 1
                    2. 0
          3. 0
            1. 1
              1. 0
              2. 0
                1. 0
        2. 0
          1. 0
            1. 0
              1. 0
                1. 0
                2. 0
  3. 0
    1. 0
      1. 0
        1. 0
          1. 0
            1. 0
              1. 0
                1. 2
      2. 0
        1. 0
          1. 1
            1. 2
              1. 1
            2. 1
              1. 0
                1. 0
                  1. 0
                    1. 1
                      1. 1
            3. 0
              1. 0
                1. 0
                  1. -1
      3. 0
        1. 0
          1. 0
    2. 0
      1. 0
        1. 0
      2. 0
      3. 0
    3. 2
      1. 0
    4. 0
  4. 0
    1. 1
      1. 2
        1. 0
        2. 0
      2. 0
        1. 0
        2. 0
          1. 0
  5. 0
    1. 0
      1. 0
        1. 0
          1. 0
            1. 0
              1. 0
                1. 0
              2. 0
  1. Hello,

    gibt's auch eine Untersuchung für Raucher und Nichtraucher?
    Wenn die Nichtraucher da auch vorne liegen würden, wäre mein Weltbild wieder in Ordnung! ;-P

    Liebe Grüße
    Tom S.

    -- Es gibt nichts Gutes, außer man tut es
    Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
    1. Tach!

      Erinnert mich ein wenig an "Käsekonsum pro Kopf korreliert mit Todesfällen durch Verheddern in Bettlaken".

      Siehe auch die Conclusion im verlinkten Artikel (dem zu Spaces vs. Tabs).

      dedlfix.

      1. Hello,

        Siehe auch die Conclusion im verlinkten Artikel (dem zu Spaces vs. Tabs).

        Genau! Rohdaten runterladen und selber gucken.

        Mich würde nämlich nur tangential interessieren, wer mehr Geld verdient. Das ist nicht unbedingt eine starre Koppelung. Wer in kürzerer Zeit mehr Müll produziert, könnte damit auch mehr Geld verdienen. Da liegen zuviele Freiheitsgerade dazwischen.

        Viel wichtiger wäre für mich, wer von den beiden Gruppen den stabileren Code schreibt.

        Liebe Grüße
        Tom S.

        -- Es gibt nichts Gutes, außer man tut es
        Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
        1. Tach!

          Viel wichtiger wäre für mich, wer von den beiden Gruppen den stabileren Code schreibt.

          Na das ist doch ganz klar, die mit den Spaces. Deren Code wackelt nicht, wenn man die Tabgröße ändert, ist also stabil. Oder nicht?

          dedlfix.

          1. Hello,

            Viel wichtiger wäre für mich, wer von den beiden Gruppen den stabileren Code schreibt.

            Na das ist doch ganz klar, die mit den Spaces. Deren Code wackelt nicht, wenn man die Tabgröße ändert, ist also stabil. Oder nicht?

            Ich meinte das überhaupt nicht witzig :-|
            (auch wenn dein kleiner Scherz zur Auflockerung beiträgt)

            Aber auch dabei müsste man genauer nachfragen: Wenn nämlich die Spacer zur Codeerfassung Tabs benutzen und ihren Editor anweisen, daraus vor dem Speichern Spaces zu machen, haben wir schon wieder eine nicht bewertete Ungenauigkeit im System. Was passiert mit den Tabs, die gezielt zum Code gehören? Ist der verwendete Editor schlau genug, die zu erkennen und deren Umwandlung zu verhindern?

            Je mehr nicht hinterfragte Hilfsmittel wir auf den Maschinencode aufpflanzen, desto mehr Fehlerquellen generieren wir uns.

            Liebe Grüße
            Tom S.

            -- Es gibt nichts Gutes, außer man tut es
            Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
            1. Aber auch dabei müsste man genauer nachfragen: Wenn nämlich die Spacer zur Codeerfassung Tabs benutzen und ihren Editor anweisen, daraus vor dem Speichern Spaces zu machen, haben wir schon wieder eine nicht bewertete Ungenauigkeit im System. Was passiert mit den Tabs, die gezielt zum Code gehören? Ist der verwendete Editor schlau genug, die zu erkennen und deren Umwandlung zu verhindern?

              Das funktioniert in der Regel anders. Ein Druck der Tab-Taste erzeugt sofort eine bestimmte Anzahl von Spaces (nicht erst beim Speichern). Wenn tatsächlich mal ein Tab in der Quellcode-Datei stehen soll (etwa als Teil eines Strings oder dergleichen), werden dafür in aller Regel Escape-Sequenzen (\t) genutzt. Das ist aber unabhängig davon, ob Spaces oder Tabs zur initialen Einrückung eingesetzt werden. Es wäre sehr unangenehm und umständlich, echte Tabs innerhalb von Zeilen verwalten zu müssen. Zum Beispiel, weil die oft unsichtbar sind und dazu noch prinzipbedingt eine variable Länge haben. Zudem ginge der Vorteil verloren, die Tabweite als Entwickler selbst bestimmen zu können.

              1. Aloha ;)

                Das funktioniert in der Regel anders. Ein Druck der Tab-Taste erzeugt sofort eine bestimmte Anzahl von Spaces (nicht erst beim Speichern).

                Das ist in keinem Einzigen der Editoren, die ich bislang verwendet habe, standardmäßig der Fall.

                Grüße,

                RIDER

                -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller

                # Twitter # Steam # YouTube # Self-Wiki #

                Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                1. Das ist aber definitiv der Standard für Leute, die mit Spaces einrücken.

                  Wir müssen bei dem Thema jetzt bitte wirklich nicht so tun, als sei daran irgendwas seltsam oder ungewöhnlich. 😉

          2. Auch zur Statik:

            Ein grundsätzliches Problem bei der Verwendung von Tabs sind gleichmäßige Zeilenlängen. Es ist nicht wirklich praktikabel, entwicklerübergreifend eine Zeilenlänge von vielleicht 80 bis maximal 120 Zeichen zu gewährleisten, wenn Entwickler A mit einer Tab-Weite von 2 arbeitet und Entwickler B mit einer Tab-Weite von 8.

            Wenn wir in einer Einrücktiefe von Ebene 4 sind (Klasse, Methode, zwei Kontrollstrukturen), ist „Tab=2“-Entwickler bei Offset 8 und „Tab=8“-Entwickler schon bei Offset 32. Das ist ein Unterschied von 24 Zeichen. Wenn beide Entwickler halbwegs darauf achten, keine zu langen Zeilen zu produzieren, sondern irgendwann mal umzubrechen, entsteht am Ende kein einheitlicher Code, weil der „Tab=8“-Entwickler viel eher umbricht als der „Tab=2“-Entwickler.

            Um so was zu vereinheitlichen, müsste man schon eine Vorgabe machen im Sinne von: „Die Tab-Weite in unserem Projekt ist genau 4 Spaces.“ Mit anderen Worten: Man will eigentlich Spaces und kann auch gleich Spaces nehmen.

            Denn auch mit einer solchen Festlegung ist das Problem mit unterschiedlichen Tab-Weiten noch nicht gelöst, denn diverse Tools (VCS, E-Mail, Projektmanagement, Print, cat, grep, diff, …), die mit dem Code arbeiten, wissen nicht, dass die Tab-Weite 4 Spaces ist. Die gehen tendenziell wahrscheinlich eher von 8 aus.

            Anderer Aspekt:

            Wieso ist es gerade so wichtig, die Darstellung der Einrücktiefe dem einzelnen Entwickler zu überlassen, wenn es bei jedem anderen zeichenbasierten Aspekt des Quellcodes keinerlei Variabilität gibt? Es gibt kein Zeichen, das sagt „wahlweise geschweifte Klammer mit in die Zeile der Kontrollstruktur oder in die Zeile darunter“. Es gibt kein Zeichen, das sagt „optionaler Leerraum um Gleichheitszeichen“. Es gibt nicht mal ein Zeichen, das sagt „OS-spezifischer Zeilenumbruch (schöne Grüße an Windows)“.

            1. @@mermshaus

              eine Zeilenlänge von vielleicht 80 bis maximal 120 Zeichen zu gewährleisten

              Noch so ein Dogma von Coding-Styles. Zeilenumbrüche im Code sollten sinnvoll erfolgen, nicht nach irgendwelchen Zahlen.

              LLAP 🖖

              -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
              1. Hello,

                das muss sich keinesfalls widersprechen.

                Definiere doch einfach erstmal "sinnvoll".

                Liebe Grüße
                Tom S.

                -- Es gibt nichts Gutes, außer man tut es
                Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
                1. das muss sich keinesfalls widersprechen.

                  Ich glaube auch nicht, dass wir jetzt wirklich diskutieren müssen, wieso Zeilenlängen um 80 und bis maximal etwa 120 Zeichen „sinnvoll“ sind.

                  1. @@mermshaus

                    Ich glaube auch nicht, dass wir jetzt wirklich diskutieren müssen, wieso Zeilenlängen um 80 und bis maximal etwa 120 Zeichen „sinnvoll“ sind.

                    Müssen wir nicht, weil nicht sonnvoll.

                    Ich habe es erlebt, dass ich HTML-Code so formatieren sollte, das eine bestimmte Zeilenlänge nicht überschritten werden sollte. Also Zeilenumbrüche in Fließtext einbauen:

                    Aus

                    <p>Alle Menschen sind frei und gleich an Würde und Rechten geboren. Sie sind mit Vernunft und Gewissen begabt und sollen einander im Geist der Brüderlichkeit begegnen.</p>

                    sollte

                    <p>Alle Menschen sind frei und gleich an Würde und Rechten geboren. Sie sind mit Vernunft und Gewissen begabt und sollen einander im Geist der Brüderlichkeit begegnen.</p>

                    gemacht werden.

                    Solch einen Schwachsinn können sich auch nur Backend-Entwickler ausdenken, die von HTML wenig Ahnung haben.

                    LLAP 🖖

                    -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                    1. Hello,

                      Ich glaube auch nicht, dass wir jetzt wirklich diskutieren müssen, wieso Zeilenlängen um 80 und bis maximal etwa 120 Zeichen „sinnvoll“ sind.

                      Müssen wir nicht, weil nicht sonnvoll.

                      Stimmt, nachdem ich das hier gelesen hatte, hat es dien ganze Zeit geregnet. :-P

                      Liebe Grüße
                      Tom S.

                      -- Es gibt nichts Gutes, außer man tut es
                      Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
                    2. Ja, da stimme ich prinzipiell zu. Ich kriege das gerade nicht mehr pointiert formuliert, aber ich bin durchaus auch der Ansicht, dass die Lesbarkeit von „Code“ nicht unter einem artifiziellen „Coding-Standard“ leiden sollte. Mein klassisches Beispiel dazu ist die Kodierung der Ausgangskonfiguration der Figuren eines Schachbretts, also einer 8x8-Struktur. Coding Standards enthalten gern „ein Array-Element pro Zeile“-Klauseln, die für so was nicht wirklich praktikabel sind, weil „8 Elemente pro Zeile“ in diesem Fall sehr viel verständlicher wäre.

                      Ich finde auch das Schreiben von HTML-Code (oder insbesondere von HTML-Templates, die serverseitige Instruktionen enthalten) oft sehr unbefriedigend, weil sich die „80-/120-Zeichen-Regel“ meines Erachtens nicht für Fließtext eignet. Es ist etwa super umständlich, den Text beim nachträglichen Hinzufügen von Wörtern entsprechend neu umzubrechen. Für derlei Fälle will man eher einen Editor, der von der Darstellung her geschickt automatisch umbricht. Editoren, die das wirklich gut machen, gibt es leider wenige, weil die meisten Editoren nicht „Programmcode“ und „Fließtextinhalt“ gleichzeitig sinnvoll unterstützen. Ich schreibe deshalb de facto oft Programmcode mit einer IDE (z. B. NetBeans) und HTML-Code/Fließtexte mit einem anderen Editor, der auf autowrap eingestellt ist (jEdit, Geany, …).

                      Für mich sind das allerdings auch getrennte Anforderungen. Bei Programmcode halte ich eine Begrenzung auf 80 Zeichen/in Ausnahmefällen 120 Zeichen durchaus für sinnvoll.

                      Andererseits muss man schon sagen, dass es nicht das Ziel sein sollte, möglichst hübsche Ascii-Bildchen zu malen, sondern einfach lesbaren Code zu produzieren. Deshalb finde ich es etwa auch nicht sinnvoll, Strings im Programmcode unnötig umzubrechen, da das beispielsweise den Einsatz von Übersetzungstools wie gettext oder auch von einer Suche nach Phrasen erschweren kann.

                      Wiederum andererseits sind das aber durchaus Ausnahmefälle. Wenn ich davon spreche, dass eine Begrenzung auf ~80 Zeichen durchaus ihren Sinn hat, beziehe ich das primär auf Logikcode, der mehr oder weniger ausschließlich aus Instruktionen besteht. Dort hilft eine Begrenzung auch dabei, die Komplexität verwaltbarer zu gestalten, weil die Begrenzung zum Beispiel eine Richtlinie ist, übertrieben tiefe Schachtelung von Kontrollstrukturen zu vermeiden.

          3. Hej dedlfix,

            Viel wichtiger wäre für mich, wer von den beiden Gruppen den stabileren Code schreibt.

            Na das ist doch ganz klar, die mit den Spaces. Deren Code wackelt nicht, wenn man die Tabgröße ändert, ist also stabil. Oder nicht?

            Das ist ja der Nachteil von Tabs. - Jedenfalls in Sprachen wie CSS - wenn man Gleichheits-Zeichen unterienander ausrichten will/muss, sollte man Spaces benutzen für Einrückungen Tabs.

            Das ist klug und stellt die Nutzbarkeit von Personen mit anderen Vorlieben als den eigenen in den Mittelpunkt (ich hasse Einrückungen mit 4 oder gar 8 Spaces!!! - Meine Tabs sind 2 Spaces breit und ich kann es nicht ab, wenn man mir breitere Abstände aufzwingt!)

            Da Nutzer von Tabs (bzw. Tabs und Spaces) offenbar die netteren menschen sind, arbeiten sie vermutlich auch nciht nur des Geldes wegen und sind vielleicht weniger hart bei den Gehalötsverhandlungen. Da in Europa mehr nach Tarif bezahlt wird als in Amerika, wo es mehr auf das eigene Verhandlungsgeschik ankommt (in Indien vielleicht auch?!?) würde das auch solche Unterschiede erklären.

            es gibt also Leute, denen Geld nicht das wichtigste ist - und die denken auch beim Schreiben von Code an diejenigen, die anders ticken als man selbst — schön, wenn man zu den guten gehört!*

            Marc

            • Ich habe keine Ahnung, ob da was dran ist, habe ich mir nur so ausgedacht.
            1. Tach!

              Das ist ja der Nachteil von Tabs. - Jedenfalls in Sprachen wie CSS - wenn man Gleichheits-Zeichen unterienander ausrichten will/muss, sollte man Spaces benutzen für Einrückungen Tabs.

              Wer Gleichheitszeichen aus eigenem Antrieb untereinandersetzt, wollte wohl eigentlich Schöngeist statt Programmierer werden. Die Beziehung besteht doch horizontal zwischen Variablenname und Wert. Mit Ausrichtung ergeben sich zwei optische Blöcke, die als solche aber keine sinnvoll zusammengefasste Einheit bilden. Und es ergeben sich mit zunehmenden Abstand aufgrund sprechender und damit längerer Variablennamen nur Schwierigkeiten beim Lesen. Nicht umsonst formatiert man Tabellenzeilen unterschiedlich farbig, damit das Auge die Zeile bessern erfassen kann. Das hat man bei Code nicht, außer mit der Editor-Einstellung "markiere die aktuelle Zeile", dann aber auch nur für die, in die man den Cursor platziert hat.

              dedlfix.

              1. Hej dedlfix,

                Das ist ja der Nachteil von Tabs. - Jedenfalls in Sprachen wie CSS - wenn man Gleichheits-Zeichen unterienander ausrichten will/muss, sollte man Spaces benutzen für Einrückungen Tabs.

                Wer Gleichheitszeichen aus eigenem Antrieb untereinandersetzt, wollte wohl eigentlich Schöngeist statt Programmierer werden.

                Mag sein - bin weder das eine, noch das andere 😉

                Aber deine Erklärung ist einleuchtend! - wozu dann spaces?

                In CSS, HTML, SASS und Konsorten machen die keinen Sinn…

                Marc

              2. Wer Gleichheitszeichen aus eigenem Antrieb untereinandersetzt, wollte wohl eigentlich Schöngeist statt Programmierer werden. Die Beziehung besteht doch horizontal zwischen Variablenname und Wert. Mit Ausrichtung ergeben sich zwei optische Blöcke, die als solche aber keine sinnvoll zusammengefasste Einheit bilden. Und es ergeben sich mit zunehmenden Abstand aufgrund sprechender und damit längerer Variablennamen nur Schwierigkeiten beim Lesen. Nicht umsonst formatiert man Tabellenzeilen unterschiedlich farbig, damit das Auge die Zeile bessern erfassen kann. Das hat man bei Code nicht, außer mit der Editor-Einstellung "markiere die aktuelle Zeile", dann aber auch nur für die, in die man den Cursor platziert hat.

                Das ist in dem Sinne kein Nachteil von Tabs, weil Tabs de facto ausschließlich zur initialen Einrückung taugen (wer es braucht…), aber:

                Keys (Variablen) und Values sind in meinem Buch schon sinnvoll zusammengefasste Einheiten, die durchaus eine tabellarische (ausgerichtete Gleichheitszeichen) Darstellung rechtfertigen.

                Du argumentierst hier im Grunde so: „Tabellen sind Quatsch, wenn die Zeilen keinen wechselnden farblichen Hintergrund haben.“

                Das finde ich etwas übertrieben. :)

                1. Tach!

                  Keys (Variablen) und Values sind in meinem Buch schon sinnvoll zusammengefasste Einheiten, die durchaus eine tabellarische (ausgerichtete Gleichheitszeichen) Darstellung rechtfertigen.

                  Der Key/Name zu seinem Value, ja, aber nicht alle Keys auf einem Haufen und alle Werte auf einem anderen. Oftmals haben sie nicht viel mehr gemeinsam, als dass es alles Variablenzuweisungen sind und nur aus diesem Grund und keinem fachlichen zu einen Block am Anfang des Codes zusammengeführt werden.

                  Du argumentierst hier im Grunde so: „Tabellen sind Quatsch, wenn die Zeilen keinen wechselnden farblichen Hintergrund haben.“

                  Nein, dass die Zeilen keine farbliche Markierung haben, macht es nur zusätzlich schwerer, ihrem Verlauf zu folgen. Mit Tabellen und ihrer Sinnhaftigkeit hat das nichts zu tun. Es war nur ein Beispiel, wie man es dort zum Zwecke der besseren Lesbarkeit aufbessern kann.

                  dedlfix.

        2. Aloha ;)

          Vorweg: Ich bin meist Tabber - aus Gewohnheit.

          Viel wichtiger wäre für mich, wer von den beiden Gruppen den stabileren Code schreibt.

          Im Zweifel: Beide. Solange sie sich nicht untereinander fortpflanzen 😉

          Die Spacer haben ein ganz klein wenig die Nase vorn, Dedlfix Scherz geht dabei schon in die richtige Richtung, und das wird relevant bei Programmiersprachen, die der Einrückung eine Bedeutung zugestehen, die über die reine Ästhetik hinausgeht.

          Haskell beispielsweise.

          In Haskell entscheidet die Tiefe der Einrückung darüber, zu was ein bestimmter, in einer eigenen Zeile stehender Code gehört. Siehe auch Haskell/Indentation.

          Man kann jetzt das Problem erahnen: Wenn hier bei der Einrückung Tabs und Spaces gemischt würden, kann der Code nicht mehr richtig interpretiert werden, obwohl er im Editor des Entwicklers richtig aussieht (weil die zwei Tabs eben auf den ersten Blick gleich aussehen wie die 8 Spaces).

          Wenn man das weiß kann man das Problem natürlich leicht beheben - spätestens wenn man vom Editor Tabs in Spaces umwandeln lässt erübrigt sich dieses Problem. Aber es ist ein Argument dafür, gleich überall Spaces zu verwenden, vor allem wenn man viel mit unterschiedlichen Programmiersprachen arbeitet.

          Aber auch hier gilt wie bei fast allen anderen Dingen: Wenn man im Team arbeitet, dann sollte sowas durch eine Konvention innerhalb des Teams verbindlich festgelegt sein und damit stellt sich nicht mehr die Frage. Beides, nur Tabs oder nur Spaces zur Einrückung zu verwenden, funktioniert - es muss nur sichergestellt sein, dass keine Mischung vorkommt (und in dem Aspekt sehe ich einen klitzekleinen Vorteil bei den Spaces).

          Grüße,

          RIDER

          -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller

          # Twitter # Steam # YouTube # Self-Wiki #

          Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
          1. Ja, deinem Schluss (klitzekleiner Vorteil für Spaces) stimme ich absolut zu.

            Der Vorteil vergrößert sich allerdings ein wenig, wenn man bedenkt, dass verschiedene Entwickler verschiedene Tab-Weiten bevorzugen könnten, was nun mal der einzige relevante Vorteil der Nutzung von Tabs ist. (!!!) Sobald das der Fall ist, sieht es dann eben nicht mehr auch bei Mischung von Tabs und Spaces richtig aus.

            Jeder, der sagt, dass ein Tab eh 4 Spaces ist, hat das Prinzip nicht verstanden. Sorry!

            Ich habe in dem Sinne auch nicht wirklich „stark“ was gegen Tabs für Einrückung (obwohl ich es aus diversen Gründen für falsch halte), aber die Praxis hat mich wirklich gelehrt, dass das zu diversen Problemen führt, weil es viele Leute nicht richtig machen und Tabs und Spaces vermischen oder Tabs an falschen Stellen nutzen.

            Es gibt Leute, die das richtig hinbekommen, aber das sind dann oft Projekte auf einem Niveau des Linux-Kernels. Nicht jedes Projekt hat einen Linus Torvalds, der einen dumm anmacht, wenn man falsch formatiert. Das ist einfach so.

            1. @@mermshaus

              wenn man bedenkt, dass verschiedene Entwickler verschiedene Tab-Weiten bevorzugen könnten, was nun mal der einzige relevante Vorteil der Nutzung von Tabs ist. (!!!)

              Na schön, du hast da was übersehen.

              LLAP 🖖

              -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
              1. Ich habe es übersehen und gleichzeitig kommentiert. Das muss man erst mal hinbekommen. 😉

                E: Ich weiß, es klingt schier unglaublich, aber Spaces-Nutzern gelingt es tatsächlich, nicht ständig ein Space zu viel oder zu wenig einzurücken. Es ist fast ein Wunder.

                1. @@mermshaus

                  E: Ich weiß, es klingt schier unglaublich, aber Spaces-Nutzern gelingt es tatsächlich, nicht ständig ein Space zu viel oder zu wenig einzurücken.

                  Tab-Nutzern gelingt das aber mit Spaces nicht.

                  Wohingegen es Spaces-Nutzern auch gelingen sollte, nicht ständig ein Tab zu viel oder zu wenig einzurücken.

                  Deutlicher kann ein Argument pro Tabs wohl kaum sein.

                  LLAP 🖖

                  -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                2. Hej mermshaus,

                  Ich habe es übersehen und gleichzeitig kommentiert. Das muss man erst mal hinbekommen. 😉

                  E: Ich weiß, es klingt schier unglaublich, aber Spaces-Nutzern gelingt es tatsächlich, nicht ständig ein Space zu viel oder zu wenig einzurücken. Es ist fast ein Wunder.

                  Dass der Einrücker die Probleme der Methode ausbügelt, macht es nicht zu einem Vorteil die der Methode angerechnet werden sollte.

                  Wie gesagt gibt es weitere Vorteile: ein Tab ist schneller gelöscht und geschrieben, als 2, 4 oder 8 Spaces…

                  Aber wie auch immer - es ist alles gesagt…

                  Marc

  2. Hallo,

    interessante Korrelation.

    Ich wage mal eine Erklärung:

    Entwickler, die das Programmieren im Rahmen einer Berufsausbildung (z.B. Fachinformatiker) gelernt haben, haben auch die formellen Aspekte vermittelt bekommen.

    Entwickler mit mathematisch-naturwissenschaftlicher Ausbildung (Diplom oder Master in Mathe, Physik oder Ingenieure) haben das Programmieren meistens im Rahmen ihres Studiums gelernt oder sich selbst beigebracht. Da wurde auf formelle Aspekte weniger Wert gelegt.

    Gruß
    Jürgen

    1. Hello,

      interessante Korrelation.

      Ich wage mal eine Erklärung:

      [...]

      Wenn die Spaces bewußt den Tabs vorgezogen werden, hängt das mMn mit dem Wunsch zur Kontrolle des Direktionsrechtes zusammen, den jeder Programmierer haben sollte. Wer sich nicht dafür interessiert, wie sein Code interpretiert werden könnte (und sei es nur die Darstellung im Editor), der ist eben ein wenig fahrlässiger als Andere.

      Der nächste Aspekt sind dann die Flame-Wars bezüglich der weiteren Coding-Standards. Ich für meinen Teil bevorzuge immer noch bewusst die explizite Schreibweise im Allman-Style. Manchmal lasse ich mich auch schon dazu hinreißen, die öffnende Klammer auf die Signaturzeile hochzuziehen, aber das auch nur, weil viele Programme (einschließlich Browsern in der Quellcode-Ansicht) das ohnehin sonst selber tun, ohne dass ich Einfluss darauf hätte. Ich lasse mich da quasi "vergewaltigen".

      Liebe Grüße
      Tom S.

      -- Es gibt nichts Gutes, außer man tut es
      Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
      1. Hallo Tom,

        ich habe mich für solche Formalien nie interessiert. In Fortran mussten an den Anfang 6 Spaces, in C habe ich mit Leerzeichen eingerückt und in Javascript/CSS/HTML hatte ich ein wüstes Gemisch aus Leerzeichen und Tabs1. Erst in letzter Zeit bringe ich da Ordnung rein.

        Gruß
        Jürgen

        1. Ein Blick in die Quelltextansicht der Browser zeigte Flattersatz links 😀

        1. Hello,

          Und ein hiesiger Upload von Code, den ich nicht bewusst vorher mit Spaces (anstelle von Tabs) ausgestattet habe, bringt mich auch jedes Mal wieder zum gesteigerten Puls...

          8 Zeichenpositionen in der Textarea sind einfach zu viel für einen Tab angesichts der heutigen Schachtelungstiefen. Vier sind vollkommen gut, zwei gingen zur Not auch noch...

          Liebe Grüße
          Tom S.

          -- Es gibt nichts Gutes, außer man tut es
          Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
          1. Letztlich ist das aber genau das, worum es Tab-Nutzern geht: Die Einrücktiefe1 selbst festlegen zu können. Eine Tab-Weite von 8 Zeichen ist dabei total normal. (Das ist zum Beispiel auch in Terminals der Standard. Die Entwicklung hin zu 4 Zeichen oder noch weniger ist meines Erachtens fast eine Art Verständnisfehler der Bedeutung der „Taste“.)

            Wem 8 Zeichen zu weit sind oder wer eigentlich eine Einrücktiefe von 4 Zeichen will, der darf keine Tabs verwenden. Es ist wirklich so einfach.

            1. „Einrücktiefe“ ist eigentlich auch der falsche Begriff. Die Tab-Taste dient zur tabellarischen Anordnung. (Und dafür ergeben veränderliche Weiten im Grunde überhaupt keinen Sinn.) Dass damit eingerückt werden kann, ist von der Semantik her irgendwie auch ein Hack.

            1. @@mermshaus

              Eine Tab-Weite von 8 Zeichen ist dabei total normal. (Das ist zum Beispiel auch in Terminals der Standard. Die Entwicklung hin zu 4 Zeichen oder noch weniger ist meines Erachtens fast eine Art Verständnisfehler der Bedeutung der „Taste“.)

              Nein. Eine Festlegung auf irgendeine Anzahl von Zeichen ist der Verständnisfehler.

              Und was heißt übrigens 8 (oder wieviel auch immer) Zeichen bei Verwendung von Proportionalschrift?

              LLAP 🖖

              -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
              1. Eine Tab-Weite von 8 Zeichen ist dabei total normal. (Das ist zum Beispiel auch in Terminals der Standard. Die Entwicklung hin zu 4 Zeichen oder noch weniger ist meines Erachtens fast eine Art Verständnisfehler der Bedeutung der „Taste“.)

                Nein. Eine Festlegung auf irgendeine Anzahl von Zeichen ist der Verständnisfehler.

                Nein.

                The word tab derives from the word tabulate, which means "to arrange data in a tabular, or table, form."

                In diesem Kontext ergibt eine frei wählbare Tab-Weite überhaupt keinen Sinn, weil jedwede Spaltendarstellung sehr schnell fehlerhaft wird, wenn sich die „Spaltenbreite“ ändert.

                Eine frei definierbare Tab-Weite ist im Sinne der ursprünglichen Bedeutung ein Hack. Die Taste heißt „tab“, nicht „ind“ (wie indent) oder so. Sie ist für tabellarische Darstellung gedacht. Einrückungen sind im Grunde eine Zweckentfremdung. Wenn auch eine Zweckentfremdung, die praktisch durchaus nutzbar ist.

                Und was heißt übrigens 8 (oder wieviel auch immer) Zeichen bei Verwendung von Proportionalschrift?

                Welche Rolle soll das spielen?

                1. @@mermshaus

                  The word tab derives from the word tabulate, which means "to arrange data in a tabular, or table, form."

                  In diesem Kontext ergibt eine frei wählbare Tab-Weite überhaupt keinen Sinn, weil jedwede Spaltendarstellung sehr schnell fehlerhaft wird, wenn sich die „Spaltenbreite“ ändert.

                  Bei Spaltendarstellung kommt es darauf an, dass die Anfänge der jeweiligen Spalten untereinander stehen. Dabei ist es unerheblich, wie weit von links das jeweils ist.

                  Die Tab-Weite ist frei wählbar, ohne das die Spaltendarstellung fehlerhaft werden würde.

                  Oder meinst du, dass aus

                  James T. Kirk › › ›William Shatner Spock › › › › ›Leonard Nimoy Leonard “Bones” McCoy ›DeForest Kelley

                  bei Änderung der Tab-Weite von 4 auf 8 dann

                  James T. Kirk › › ›William Shatner Spock › › › › ›Leonard Nimoy Leonard “Bones” McCoy ›DeForest Kelley

                  werden würde? ([ ]*› soll für ein Tab-Zeichen stehen.)

                  Der Fehler liegt darin, dass multiple Tabs verwendet werden, um eine Tabellendarstellung zu erzielen.

                  Eine frei definierbare Tab-Weite ist im Sinne der ursprünglichen Bedeutung ein Hack.

                  Multiple Tabs sind ein Hack.

                  Bei einem Tab-Zeichen

                  James T. Kirk ›William Shatner Spock ›Leonard Nimoy Leonard “Bones” McCoy›DeForest Kelley

                  besteht das Problem nicht. Die jeweilige Position des Tabulators wird vom Inhalt bestimmt.

                  Und was heißt übrigens 8 (oder wieviel auch immer) Zeichen bei Verwendung von Proportionalschrift?

                  Welche Rolle soll das spielen?

                  Es besteht keine Notwendigkeit, Code in dicktengleicher Schrift zu schreiben.

                  LLAP 🖖

                  -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
      2. Ich für meinen Teil bevorzuge immer noch bewusst die explizite Schreibweise im Allman-Style.

        So unterschiedlich können Geschmäcker sein 🌓 Ich schreibe am liebsten in Sprachen, die gar keine geschweiften Klammern für Codeblöcke vorsehen und dafür Whitespace-sensitiv sind. Python, Elm oder Haskell zum Beispiel. Und dann selbstverständlich 2❗️ Spaces.

        1. 2❗️ Spaces

          😉

          Das ist vielleicht so ein wenig die Pointe der Tabs-vs.-Spaces-Diskussion. Würden wir nicht darüber diskutieren, wäre es bestimmt die Einrücktiefe. Und hey, wäre es nicht praktisch, ein Zeichen zu haben, das die Einrücktiefe für jeden Entwickler frei wählbar macht?

          Edit: Dieser Beitrag ist nicht so ganz ernst gemeint. Die Einrücktiefe bei reiner Spaces-Nutzung ist mir persönlich noch nie wirklich als Thema untergekommen. Was aber auch irgendwie interessant ist.

          1. 2❗️ Spaces

            Das Gepoche war auch meinerseits schon Ironie 😉

            Die Argumente für die Alternativen sind schnell aufgezählt:

            1. Tabs lassen den Nutzer die dargestellte Breite selber einstellen.
            2. Bei Spaces wählt man eine Einrücktiefe, die dann für alle gilt.
            3. Tabs sind ungeignet, um in der Zeilenmitte Spalten auszurichten.
            4. Spaces dagegen schon.

            Keines der Argumente wiegt besonders schwer. Ich habe persönlich schon gefühlt jeden Coding-Style mal durchprobiert und kann mich mit allem anfreunden. Wichtig ist lediglich, dass eine Code-Basis konsistent ist. Und ein guter Editor macht natürlich eh vieles einfacher.

            1. Hallo 1unitedpower,

              Keines der Argumente wiegt besonders schwer.

              Abgesehen davon stammt diese Diskussion aus den 60ern? 70ern? und jedes einzelne Argument ist schon diverse male durchgekaut worden. Ich habe schon seit Jahrzehnten keinen mehr etwas neues dazu beitragen sehen… gähn

              LG,
              CK

              -- https://wwwtech.de/about
              1. Hallo Christian,

                Abgesehen davon stammt diese Diskussion aus den 60ern? 70ern? und jedes einzelne Argument ist schon diverse male durchgekaut worden. Ich habe schon seit Jahrzehnten keinen mehr etwas neues dazu beitragen sehen… gähn

                und eigentlich ging es ja auch nur um die Korrelation zwischen Einrückstil und Gehalt.

                Gruß
                Jürgen

            2. @@1unitedpower

              Die Argumente für die Alternativen sind schnell aufgezählt:

              Und bei schnell, schnell sind dann schnell mal ein paar Dinge vergessen:

              5. Bei Leerzeichen hat man schnell mal 3 Leerzeichen eingerückt. Oder 5.
              6. Bei Tabs hat man das Problem nicht.
              7. Wenn man bei Leerzeichen am Anfang in die Einrückung clickt, landet man irgendwo, aber nicht notwendigerweise bei 4, 8, 12, …
              8. Bei Tabs hat man das Problem nicht.

              Ich kann nicht verstehen, warum einige Entwickler immer noch Leerzeichen bevorzugen.

              3. Tabs sind ungeignet, um in der Zeilenmitte Spalten auszurichten.
              4. Spaces dagegen schon.

              Das ist wahr, aber:

              • Das braucht man selten.
              • Es spricht überhaupt nichts dagegen, am Zeilenanfang Tabs zum Einrücken zu verwenden und in der Zeilenmitte Leerzeichen zum Ausrichten.
              • Bei Proportionalschrift ist das hinfällig.

              LLAP 🖖

              -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory

              Folgende Nachrichten verweisen auf diesen Beitrag:

              1. 5. Bei Leerzeichen hat man schnell mal 3 Leerzeichen eingerückt. Oder 5. 6. Bei Tabs hat man das Problem nicht.

                Das ist mir quasi noch nie begegnet. Nahezu alle Einrückfehler, die ich sehe, haben mit einem Mischmasch von Tabs und Spaces oder mit einer falschen Nutzung von Tabs zu tun. Spaces-Nutzer drücken halt auch Tab, um die Einrückung vorzunehmen. Die Taste erzeugt dann eben die passende Anzahl an Spaces. Das kann man an der Stelle meinetwegen sogar ein wenig schizophren nennen, es funktioniert meiner Erfahrung nach aber sehr gut, weil man eben auch sofort sieht, wenn was falsch eingerückt ist. (Was aber selten passiert, weil Tab eben trotzdem zu Modulo-4- oder Modulo-8-Offsets springt – durch Auffüllen mit Spaces.) Wenn man Tabs und Spaces mischt, sieht man die Fehler oft nicht, weil man bei Space+Tab genauso bei Offset 4 landet wie mit nur Tab. Dass da ein unnötiges Space vor dem Tab steht, merkt man nicht, wenn man sich die nicht-druckbaren Zeichen nicht darstellen lässt.

                Natürlich sollte das nicht passieren, aber es passiert meiner Erfahrung nach ständig, dass sich da überzählige Leerzeichen einschleichen.

                7. Wenn man bei Leerzeichen am Anfang in die Einrückung clickt, landet man irgendwo, aber nicht notwendigerweise bei 4, 8, 12, …
                8. Bei Tabs hat man das Problem nicht.

                Das ist theoretisch richtig, aber mir ist das nicht als praktisches Problem bekannt, weil man eben sofort sieht, dass eine Zeile, die 3 oder 5 Zeichen eingerückt ist, nicht plan mit einer Einrücktiefe von 4 ist.

                Ich kann nicht verstehen, warum einige Entwickler immer noch Leerzeichen bevorzugen.

                Sie sind eindeutig und nicht abhängig vom Kontext. Ich habe es hier anderswo etwas ausgebreitet, dass viele Anwendungen von einer Tab-Weite von 8 ausgehen, obwohl die Mehrzahl der Entwickler eher 4 will.

                Ich würde die Frage deshalb umdrehen und fragen, worin der Vorteil von Tabs besteht.

                1. @@mermshaus

                  5. Bei Leerzeichen hat man schnell mal 3 Leerzeichen eingerückt. Oder 5. 6. Bei Tabs hat man das Problem nicht.

                  Das ist mir quasi noch nie begegnet.

                  Mir desöfteren.

                  7. Wenn man bei Leerzeichen am Anfang in die Einrückung clickt, landet man irgendwo, aber nicht notwendigerweise bei 4, 8, 12, …
                  8. Bei Tabs hat man das Problem nicht.

                  Das ist theoretisch richtig, aber mir ist das nicht als praktisches Problem bekannt, weil man eben sofort sieht, dass eine Zeile, die 3 oder 5 Zeichen eingerückt ist, nicht plan mit einer Einrücktiefe von 4 ist.

                  Oder später. Oder gar nicht.

                  Ich würde die Frage deshalb umdrehen und fragen, worin der Vorteil von Tabs besteht.

                  Lea Verou hat mal einen Artikel geschrieben: Why tabs are clearly superior

                  LLAP 🖖

                  -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
                  1. Hej Gunnar,

                    Lea Verou hat mal einen Artikel geschrieben: Why tabs are clearly superior

                    Schön, dann brauche ich den nicht zu posten - sollte man kennen 😉

                    Lea verdient übrigens nicht allzu schlecht…

                    Marc

                    1. Hej marctrix,

                      Lea Verou hat mal einen Artikel geschrieben: Why tabs are clearly superior

                      Lea verdient übrigens nicht allzu schlecht…

                      Zu recht. Was mich zu der Frage führt: verdienen Spaces-Nutzer zu recht mehr als Tab-Nutzer, d. h. sind sie die besseren Entwickler? Wie sieht die Verbreitung von Sapces/Tabs unter den Koryphäen aus? Und was für Gründe haben die dafür. Wäre es an der Zeit, sich auf Tabs oder Spaces zu einigen?

                      Ob Tab- oder Leerzeichen-Liebhaber mehr Geld verdienen ist doch eine vollkommen unwichtige Information. Wenn ich morgen zu meinem Chef gehe und ihm sage: „Ich glaube, dass die Verwendung von Tabs ungefähr einen dutzend erheblicher Vorteile gegenüber der Verwendung von Leerzeichen hat. Aber ich bin bereit mir meine tägliche Arbeit zu erscheren und Leerzeichen zu verwenden. Sind sie jetzt stolz auf mcih? - So stolz, dass sie mir ab morgen mehr Geld geben?“

                      Was wird der dann wohl antworten grübel?

                      Marc

                      PS: Ich persönlich verwende Tabs aus guten Gründen, mir ist es aber völlig wurscht, wen jemand anders das nicht so macht - wenn ich in ein team komme, passe ich mich den gepflogenheiten an - (heißt ich lasse HTMLtidy dafür sorgen, dass mir der Code passt und übergebe ihn am Ende so wie gewünscht — ist nur eine Einstellungssache im Editor, Postprocessor oder wo auch immer).

                      Damit so etwas funktioniert ist viel wichtiger, dass sauber gearbeitet wird!

                      PPS: Ich glaube nciht, dass man anhand der Verwendung bestimmter Methoden zur Einrückung sagen kann, ob jemand ein besserer Programmierer ist. - nur um das klar zu stellen!

                      1. Hallo marctrix,

                        Wäre es an der Zeit, sich auf Tabs oder Spaces zu einigen?

                        Ich glaube nicht, dass das klappt: Siehe verschiedene Stecker und sonstige Standards. Jeder sieht immer irgendwelche Vorteile in seiner Vorgehensweise oder hat zumindest keine Lust sich umzugewöhnen.

                        Es wird wohl auch immer ein paar Inseln geben, auf denen man links fährt 😉

                        Gruß
                        Julius

                        P.S.: Habe gerade nachgedacht, was ich eigentlich verwende: Wenn ich von Hand einrücke, Spaces, sonst (90%) macht das die IDE oder der passende Editor das Einrücken automatisch. Ich habe gerade noch mal nachgesehen und festgestellt, dass dort scheinbar Spaces eingestellt sind, hat mich eigentlich nie sonderlich interessiert...

            3. Hej 1unitedpower,

              1. Tabs lassen den Nutzer die dargestellte Breite selber einstellen.
              2. Bei Spaces wählt man eine Einrücktiefe, die dann für alle gilt.
              3. Tabs sind ungeignet, um in der Zeilenmitte Spalten auszurichten.
              4. Spaces dagegen schon.

              5. Tabs benötigen deutlich weniger Tastendrücke beim Verwenden und Entfernen!

              Marc

              1. 5. Tabs benötigen deutlich weniger Tastendrücke beim Verwenden und Entfernen!

                Das stimmt nur so halb. Beim Setzen stimmt es gar nicht (Editoren füllen bei entsprechender Einstellung mit Spaces auf), beim Entfernen ist es richtig, dass nicht alle Editoren, die ich so kenne, beim Druck von Backspace „eine Einrücktiefe“ an Spaces entfernen, aber einerseits machen das etliche Editoren durchaus und andererseits ist das meiner Einschätzung nach kein wahnsinnig relevanter Use-Case, weil Shift-Tab die korrekte Tastenkombination für den Einsatzzweck ist.

                Anders gesagt: Editoren abstrahieren den „Unterschied“ zwischen Tabs und Spaces weg. Ich erkenne es an, dass man das dennoch als Argument für Tabs auffassen kann, weil die Tab-Taste für Spaces gewissermaßen „zweckentfremdet“ wird, aber im Gebrauch funktioniert das schlicht und ergreifend problemlos und wunderbar. Der Vorteil (aus Sicht von Spaces-Nutzern) ist eben, dass die Ambiguität der Tab-Weite aus der Gleichung rausgenommen wird.

                Mein Argument hier ist, dass es in der Anzahl der Tastendrücke (-drucke?) nicht den geringsten Unterschied gibt, ob Tabs oder Spaces genutzt werden.

                Letztlich ist der Punkt bei dem Thema meines Erachtens immer, ob man es aushalten kann, eine fest definierte Einrücktiefe (gemessen in Spaces) zu nutzen. Und ich bin der Ansicht, dass man das kann, weil man eben x andere Aspekte an der Formatierung des Quellcodes auch nicht durch Nutzung bestimmter Kontrollzeichen beeinflussen kann, weil diese Kontrollzeichen schlicht und ergreifend nicht existieren. Dass das mit Tabs „geht“, ist meines Erachtens eher ein Zufall oder ein Nebeneffekt der ursprünglichen Bedeutung der Tabulator-Taste.

                1. Hej mermshaus,

                  5. Tabs benötigen deutlich weniger Tastendrücke beim Verwenden und Entfernen!

                  Das stimmt nur so halb. Beim Setzen stimmt es gar nicht (Editoren füllen bei entsprechender Einstellung mit Spaces auf)

                  Nein "Editoren" machen das nicht, aber "dein Editor" macht das vermutlich so - wobei das vermutlich auch Einstellungssache ist.

                  Letztlich ist der Punkt bei dem Thema meines Erachtens immer, ob man es aushalten kann,

                  Für mich ist es die Frage, ob ich es aushalten muss. Warum soll ich alles aushalten, nur weil ich es kann. Bin ich ein Esel?

                  Und macht es mich schneller? Oder besser, wenn ich etwas aushalte? Wohl im Gegenteil.

                  Ich denke aber, wir reden etwas aneinander vorbei. Haskell und diverse andere Aspekte, die du hier ins Rennen führst, spielen für Frontender keine Solle. Ich hatte das vorher schon mal (offenbar zu subtil) angedeutet und zusammengefasst als

                  Es gibt für Frontender keinen Grund etwas anderes als Tabs für Einrückungen zu nutzen. Für Sass, CSS, HTML haben Tabs nur Vorteile.

                  Marc

                  1. @@marctrix

                    Es gibt für Frontender keinen Grund etwas anderes als Tabs für Einrückungen zu nutzen. Für Sass, CSS, HTML haben Tabs nur Vorteile.

                    Füge JavaScript, PHP, Java, … zur Liste hinzu.

                    Mit kommen diese ganzen Tabs-vs.-Spaces-Diskussionen immer so vor, dass Spaces-Befürworter

                    1. Fakten ignorieren
                    2. alternative Fakten auftischen

                    LLAP 🖖

                    -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
      3. Lieber TS,

        Wenn die Spaces bewußt den Tabs vorgezogen werden, hängt das mMn mit dem Wunsch zur Kontrolle des Direktionsrechtes zusammen,

        wiebitte?! Man kann in seinem Quelltext auf formalisierte Weise die Breite von Tabs voreinstellen. Wie der Code-Betrachter die Breite von Tabs dann tatsächlich einstellt, obliegt einzig und alleine ihm! Das ist wie der Zoom im Browser. Meine Güte!

        den jeder Programmierer haben sollte. Wer sich nicht dafür interessiert, wie sein Code interpretiert werden könnte (und sei es nur die Darstellung im Editor), der ist eben ein wenig fahrlässiger als Andere.

        Wie mein Code interpretiert wird, regelt der verwendete Parser der jeweiligen Sprache, sonst niemand!

        Liebe Grüße,

        Felix Riesterer.

        1. wiebitte?! Man kann in seinem Quelltext auf formalisierte Weise die Breite von Tabs voreinstellen. Wie der Code-Betrachter die Breite von Tabs dann tatsächlich einstellt, obliegt einzig und alleine ihm! Das ist wie der Zoom im Browser. Meine Güte!

          Das ist eher wie padding-left. 😉

          1. @@mermshaus

            wiebitte?! Man kann in seinem Quelltext auf formalisierte Weise die Breite von Tabs voreinstellen. Wie der Code-Betrachter die Breite von Tabs dann tatsächlich einstellt, obliegt einzig und alleine ihm! Das ist wie der Zoom im Browser. Meine Güte!

            Das ist eher wie padding-left. 😉

            Eher wie tab-size.

            LLAP 🖖

            -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
    2. Ich glaube, es ist eher eine Frage davon, ob jemand sorgfältig arbeitet oder nicht. Es ist fraglos möglich, mit Tabs und auch mit Spaces zur Einrückung Code zu schreiben, der von der Form her korrekt ist.

      Ich habe beispielsweise kürzlich was mit dem R-Quiz von @Felix Riesterer gebastelt. Ich nehme das als Beispiel, weil Felix auch hier im Thread gepostet hat und weil der Code Tabs nutzt. (Disclaimer: Ich bin überzeugter Spaces-Nutzer.) Ich habe mir vorhin spaßeshalber den Code in Sachen Einrückungen angesehen, und der Code ist bis auf ein oder zwei geschenkte Kleinigkeiten in der Hinsicht absolut einwandfrei.

      Das ist nur leider in meinem Job-Alltag nicht der Normalfall, ohne mich als exemplarisch bezeichnen zu wollen. Ich arbeite jedenfalls oft mit bestehendem Code, der oft eine wilde Mischung aus Tabs und Spaces enthält. Das sieht ständig so aus:

      (Die Pfeile sind Tabs, die Punkte sind Spaces.)

      Das ist natürlich hochgradig falsch, aber es sieht korrekt aus, solange niemand was an der Einstellung ändert, dass die Tab-Weite genau 4 Leerzeichen entspricht.

      Ich bin deshalb schon allein (aber nicht ausschließlich) aus pragmatischen Gründen für die reine Nutzung von Spaces. Code, der nur Spaces nutzt, sieht immer falsch aus, wenn er falsch eingerückt ist. Bei der Nutzung von Tabs sieht man die Fehler nicht, wenn man nicht-druckbare Zeichen nicht anzeigen lässt oder keine andere Tab-Weite eingestellt hat. Deshalb entstehen dann so Sachen wie auf dem Screenshot oben. Das ist keine Boshaftigkeit, und ich würde es nicht mal als „Inkompetenz“ bezeichnen. Es passiert bloß einfach.

      Ich sage nicht, dass man das mit Tabs nicht auch richtig machen kann. Ich stimme durchaus zu, dass es nicht an Tabs liegt, sondern am Anwender, der keine ausreichende Disziplin aufweist. Aber: In meiner täglichen Arbeit hilft mir diese Erkenntnis nicht. Die Leute, die den Code geschrieben haben, mit dem ich arbeite, sind durchaus Profis, die damit ihr Geld verdienen. Trotzdem entsteht ständig dieser Mischmasch.

      Warum Spaces, warum nicht Tabs? Kann man nicht genauso argumentieren, dass das Problem die Nutzung von Spaces zur Einrückung ist, obwohl man nur Tabs nutzen sollte?

      Jain. Ein Argument für Spaces und gegen Tabs: Jedes Tab aus nahezu jedem Quellcode kann durch Spaces ersetzt werden, ohne dass sich an der grundsätzlichen Lesbarkeit des Codes etwas ändert. Spaces kann man hingegen nicht gänzlich entfernen, weil sie in jedem Fall innerhalb von Zeilen benötigt werden. Tabs sind aber unter fast allen Umständen völlig optional. Das Zeichen braucht in Quellcode nicht aufzutauchen. Würde man völlig auf Tabs verzichten, gäbe es die gesamte Klasse von Problemen, auf die ich auf dem Screenshot hingewiesen habe, nicht.

      (Es gibt Ausnahmen, in denen Tabs aus syntaktischen Gründen zwingend sind.)

      1. Tach!

        (Die Pfeile sind Tabs, die Punkte sind Spaces.)

        Das ist natürlich hochgradig falsch, aber es sieht korrekt aus, solange niemand was an der Einstellung ändert, dass die Tab-Weite genau 4 Leerzeichen entspricht.

        Nö, hochgradig falsch kann gar nicht sein, weil Tabs und Spaces im gezeigten Beispiel verlustfrei gegeneinander austauschbar sind und auch die Einrückung nur Optik ist und syntaktisch bedeutungslos ist. Wenn überhaupt, dann ist nur die Lesbarkeit betroffen. Das erschwert vielleicht das Verstehen und die Bearbeitung, aber "falsch" geht anders.

        Deshalb entstehen dann so Sachen wie auf dem Screenshot oben. Das ist keine Boshaftigkeit, und ich würde es nicht mal als „Inkompetenz“ bezeichnen. Es passiert bloß einfach.

        Das passiert nicht "bloß einfach", Wenn man mit zu einfachen Editoren statt einer Entwicklungsumgebung arbeitet oder einem auf Programmieren ausgelegten Editor, die einen darauf hinweisen, wenn man Tabs und Leerzeichen gemischt einsetzt, und außerdem die Einrückung selbständig vorschlagen. Mischmasch ist also einfach vermeidbar.

        Ein Argument für Spaces und gegen Tabs: Jedes Tab aus nahezu jedem Quellcode kann durch Spaces ersetzt werden, ohne dass sich an der grundsätzlichen Lesbarkeit des Codes etwas ändert. Spaces kann man hingegen nicht gänzlich entfernen, weil sie in jedem Fall innerhalb von Zeilen benötigt werden. Tabs sind aber unter fast allen Umständen völlig optional. Das Zeichen braucht in Quellcode nicht aufzutauchen. Würde man völlig auf Tabs verzichten, gäbe es die gesamte Klasse von Problemen, auf die ich auf dem Screenshot hingewiesen habe, nicht.

        Das sind Gedanken, die man sich mit den passenden Werkzeugen überhaupt nicht machen muss. Code-Reformatieren unter Berücksichtigung des Kontextes ist für IDEs und Programmierer-Editoren kein Problem und nur ein Tastendruck.

        dedlfix.

        1. Tach!

          (Die Pfeile sind Tabs, die Punkte sind Spaces.)

          Das ist natürlich hochgradig falsch, aber es sieht korrekt aus, solange niemand was an der Einstellung ändert, dass die Tab-Weite genau 4 Leerzeichen entspricht.

          Nö, hochgradig falsch kann gar nicht sein, weil Tabs und Spaces im gezeigten Beispiel verlustfrei gegeneinander austauschbar sind und auch die Einrückung nur Optik ist und syntaktisch bedeutungslos ist. Wenn überhaupt, dann ist nur die Lesbarkeit betroffen. Das erschwert vielleicht das Verstehen und die Bearbeitung, aber "falsch" geht anders.

          Also, das war jetzt vielleicht nicht das beste Beispiel, sondern eins, das ich mir schnell aus meiner Twitter-History ergooglet habe. In dem Sinne sorry für die Faulheit. :) Ich weiß nicht, ob da Tabs und Spaces wirklich austauschbar wären.

          Mein Punkt sollte jedenfalls sein: Sobald man eine andere Tab-Weite nutzt als der Autor des Codes, wird die Einrückung falsch, weil Tabs und Spaces zu ungünstig vermischt sind. Da geschätzte 92,7 % aller Entwickler eine Tab-Weite von 4 Spaces nutzen, ist das in der Regel zwar wenig problematisch, aber sobald irgendwer oder irgendwas dann doch mal eine Tab-Weite von 8 oder 2 oder so nutzt, wird es von der Einrückung her Kraut und Rüben. (Das kann ich prinzipiell auch durch Beispiele belegen, weil es mir wirklich ständig unterkommt.)

          Wenn du allerdings argumentierst, dass die Optik (bzw. Lesbarkeit) von Code den Code nicht (optisch und im Sinne der Lesbarkeit) „falsch“ macht, dann ist das meines Erachtens eine andere Diskussion.

          Deshalb entstehen dann so Sachen wie auf dem Screenshot oben. Das ist keine Boshaftigkeit, und ich würde es nicht mal als „Inkompetenz“ bezeichnen. Es passiert bloß einfach.

          Das passiert nicht "bloß einfach", Wenn man mit zu einfachen Editoren statt einer Entwicklungsumgebung arbeitet oder einem auf Programmieren ausgelegten Editor, die einen darauf hinweisen, wenn man Tabs und Leerzeichen gemischt einsetzt, und außerdem die Einrückung selbständig vorschlagen. Mischmasch ist also einfach vermeidbar.

          Trotzdem tritt er auf. Ich erfinde das nicht. Und ehrlich gesagt: Ich halte es für ein Märchen, dass jeder „gute Editor“ so was vermeidet. Abgesehen von dem Aspekt, dass Code meines Erachtens auch mit simplen Mitteln sinnvoll editierbar sein sollte.

          Ein Argument für Spaces und gegen Tabs: Jedes Tab aus nahezu jedem Quellcode kann durch Spaces ersetzt werden, ohne dass sich an der grundsätzlichen Lesbarkeit des Codes etwas ändert. Spaces kann man hingegen nicht gänzlich entfernen, weil sie in jedem Fall innerhalb von Zeilen benötigt werden. Tabs sind aber unter fast allen Umständen völlig optional. Das Zeichen braucht in Quellcode nicht aufzutauchen. Würde man völlig auf Tabs verzichten, gäbe es die gesamte Klasse von Problemen, auf die ich auf dem Screenshot hingewiesen habe, nicht.

          Das sind Gedanken, die man sich mit den passenden Werkzeugen überhaupt nicht machen muss. Code-Reformatieren unter Berücksichtigung des Kontextes ist für IDEs und Programmierer-Editoren kein Problem und nur ein Tastendruck.

          Es bleibt dennoch eine Klasse von Problemen, die viele Leute und viele Workflows gewissermaßen überfordert und die ohne weiteres vermeidbar wäre.

      2. Hallo mermshaus,

        Jain. Ein Argument für Spaces und gegen Tabs: Jedes Tab aus nahezu jedem Quellcode kann durch Spaces ersetzt werden, ohne dass sich an der grundsätzlichen Lesbarkeit des Codes etwas ändert. Spaces kann man hingegen nicht gänzlich entfernen, weil sie in jedem Fall innerhalb von Zeilen benötigt werden. Tabs sind aber unter fast allen Umständen völlig optional. Das Zeichen braucht in Quellcode nicht aufzutauchen. Würde man völlig auf Tabs verzichten, gäbe es die gesamte Klasse von Problemen, auf die ich auf dem Screenshot hingewiesen habe, nicht.

        Mein persönliches Empfinden ist, dass ich mit Tabs schneller die notwendige/gewünschte Einrücktiefe erhalte. Mein persönlicher Favorit bei unter den Editoren (notepad++) wandelt mir die Tabs automatisch in 2 Leerzeichen um, und zwar on the fly und nicht erst beim speichern. (Ob es intern nicht doch erst beim Speichern passiert, ist mir egal. Jedenfalls werden sofort zwei Punkte statt eines Pfeils angezeigt.)

        Bis demnächst
        Matthias

        -- Rosen sind rot.
      3. Hej mermshaus,

        Jain. Ein Argument für Spaces und gegen Tabs: Jedes Tab aus nahezu jedem Quellcode kann durch Spaces ersetzt werden, ohne dass sich an der grundsätzlichen Lesbarkeit des Codes etwas ändert. Spaces kann man hingegen nicht gänzlich entfernen,

        leading spaces schon…

        Marc

    3. Aloha ;)

      Ich wage mal eine Erklärung:

      Entwickler, die das Programmieren im Rahmen einer Berufsausbildung (z.B. Fachinformatiker) gelernt haben, haben auch die formellen Aspekte vermittelt bekommen.

      Entwickler mit mathematisch-naturwissenschaftlicher Ausbildung (Diplom oder Master in Mathe, Physik oder Ingenieure) haben das Programmieren meistens im Rahmen ihres Studiums gelernt oder sich selbst beigebracht. Da wurde auf formelle Aspekte weniger Wert gelegt.

      Das geht aber davon aus, dass es ein klares „formell richtig“ gibt. Das ist aber längst nicht so klar der Fall. Wir haben hier gesehen, dass es gute Argumente für das Verwenden von Tabs gibt. Andererseits wurde mir im Kontext von Haskell von Dozentenseite nahegelegt, Spaces zu verwenden (bzw. das sogar explizit verlangt). Es ist nicht ganz so einfach, in diesem Aspekt ein „formell richtig“ auszumachen.

      Ich wage auch mal eine Erklärung. Sie findet sich in den Kommentaren zu dem ursprünglichen Artikel:

      I think it’s more likely that spaces are just more prevalent in a certain type of commercial environment that also happens to pay higher salaries.

      Der Coding Style (und damit auch die Frage, wie man Einrückungen vornimmt) wird im professionellen Umfeld im Zweifelsfall vom Arbeitgeber vorgeschrieben. Ich halte es für eher wahrscheinlich, dass unter den Arbeitgebern mit Space-Bevorzugung mehr sind, die ihre Mitarbeiter besser bezahlen als andere - rein zufällig (bzw. aus dem Grund, den @1unitedpower nannte - größere Projekte, mehr finanzielle Mittel, häufigerer Einsatz von Coding Styles, mehrheitlich Spaces in eingesetzten Coding Styles).

      Ich glaube, dass der Individualisierungsaspekt durch den Editor, den @1unitedpower anspricht, im statistischen Mittel eher wieder herausfällt. Das wird zwar ziemlich sicher genutzt, aber ich gehe davon aus, dass die meisten Programmierer sich (zumindest auf lange Sicht hin) in ihrer Gewohnheit dem anpassen, was der Arbeitgeber sowieso verlangt (selbst wenn das mit entsprechenden Werkzeugen nicht notwendig ist).

      Damit hätten wir eine recht nüchterne Erklärung, die die Lohnunterschiede eben nicht mehr auf individuelle Gewohnheiten zurückführt, sondern nur noch auf die Lohnunterschiede bei verschiedenen Unternehmen, die eben auch verschiedene Coding Styles verwenden, und damit ist auch das eher fatalistische Bild, das @Felix Riesterer da befürchtet zu sehen, wieder vom Tisch.

      Grüße,

      RIDER

      -- Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller

      # Twitter # Steam # YouTube # Self-Wiki #

      Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
      1. @@Camping_RIDER

        Damit hätten wir eine recht nüchterne Erklärung, die die Lohnunterschiede eben nicht mehr auf individuelle Gewohnheiten zurückführt, sondern nur noch auf die Lohnunterschiede bei verschiedenen Unternehmen, die eben auch verschiedene Coding Styles verwenden

        TL;DR: Scheinkorrelation

        LLAP 🖖

        -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
    4. Entwickler, die das Programmieren im Rahmen einer Berufsausbildung (z.B. Fachinformatiker) gelernt haben, haben auch die formellen Aspekte vermittelt bekommen.

      Das klingt eher nach einer Wunschvorstellung, als der von mir erlebten Realität zu entsprechen.

  3. Lieber dedlfix,

    Gefunden bei Fefe.

    habe ich dort auch gesehen und mir den verlinkten Artikel durchgelesen. Dass dieses aus meiner Sicht leidige Thema zu messbaren Lohnunterschieden führt, pervertiert für mich diese Industrie! Da kann ich nur hoffen, dass die teureren Space-Schreiber tatsächlich aufgrund höheren Alters und Erfahrung diese Statistik "schief" werden lassen.

    Wer meinen Code anders eingerückt sehen will, der soll in seinem Editor die Breite von Tabs gefälligst auf seine Wünsche hin anpassen! Ich schreibe weiterhin Tabs! Und gottseidank verdiene ich mein Geld nicht mit dem Schreiben von Software.

    Liebe Grüße,

    Felix Riesterer.

    1. Hallo Felix,

      habe ich dort auch gesehen und mir den verlinkten Artikel durchgelesen. Dass dieses aus meiner Sicht leidige Thema zu messbaren Lohnunterschieden führt, pervertiert für mich diese Industrie! Da kann ich nur hoffen, dass die teureren Space-Schreiber tatsächlich aufgrund höheren Alters und Erfahrung diese Statistik "schief" werden lassen.

      wenn zwei Größen korreliert sind, heist das nicht, das die eine von der anderen abhängt. Sie können auch beide die gleiche Ursache haben.

      Gruß
      Jürgen

      1. wenn zwei Größen korreliert sind, heist das nicht, das die eine von der anderen abhängt. Sie können auch beide die gleiche Ursache haben.

        Meine Vermutung: Höheren Gehältern geht oft eine bessee Finanzierung des Software-Projekts voraus. An besser finanzierten Projekten sind häufig mehre Entwickler beteiligt. Wo mehrere Entwickler involviert sind, kommen häufiger Coding-Styleguides als Grundlage der Zusammenarbeit zum Einsatz. Und schließlich bevorzugen die meisten Coding-Styleguides Spaces vor Tabs.

        @Felix Riesterer in der Praxis ist das auch gar nicht so wild, weil gute IDEs dich in deinem persönlichen Coding-Style arbeiten lassen und beim Speichern automatisch deinen Code entsprechend des Styleguides formatieren.

        1. Hello,

          Meine Vermutung: Höheren Gehältern geht oft eine bessee Finanzierung des Software-Projekts voraus. An besser finanzierten Projekten sind häufig mehre Entwickler beteiligt. Wo mehrere Entwickler involviert sind, kommen häufiger Coding-Styleguides als Grundlage der Zusammenarbeit zum Einsatz. Und schließlich bevorzugen die meisten Coding-Styleguides Spaces vor Tabs.

          Interessanter Ansatz. Dann wären Ursache und Wirkung vertauscht.
          Und dann dürfte man auch keine individuellen Zusammenhänge mehr unterstellen.

          Liebe Grüße
          Tom S.

          -- Es gibt nichts Gutes, außer man tut es
          Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
        2. Interessehalber: Welche IDEs machen das, was du beschreibst?

          Ich weiß, dass es Tools/Scripts gibt, die so was automatisieren können (ist im Zweifel auch – verhältnismäßig – trivial selbst zu basteln), aber als integraler Bestandteil eines Workflows ist mir das bislang nicht wirklich untergekommen. Oder anders formuliert: Gibt es wirklich Entwickler, die so viel Wert auf ihren eigenen Stil legen, dass sie so was nutzen? Ich finde das irgendwie schon schräg, weil man zum Beispiel auch bedenken muss, dass sich etwa durch unterschiedliche Tab-Weiten mitunter recht stark abweichende Zeilenlängen ergeben können. Ich finde das reichlich eigentümlich.

      2. Hallo JürgenB,

        wenn zwei Größen korreliert sind,

        Ist das korrektes deutsch? Hab ich so noch nie gehört. Ich kenne nur die Verwendung der Verb-Form1 also „Wenn zwei größen korrelieren“

        Bis demnächst
        Matthias

        1. nicht das Partizip 😉

        -- Rosen sind rot.
        1. Hello,

          wenn man dem wiktionary trauen darf

          Liebe Grüße
          Tom S.

          -- Es gibt nichts Gutes, außer man tut es
          Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
        2. Hallo Matthias,

          Ist das korrektes deutsch?

          spielt das seit der Rechtschreibreform noch eine Rolle?

          Gruß
          Jürgen

          1. Hallo JürgenB,

            Ist das korrektes deutsch?

            spielt das seit der Rechtschreibreform

            Welcher? 1996, 2004, 2006 oder 2011? Oder gar 1876?

            noch eine Rolle?

            Die Rechtschreibung hat außerhalb der Lehranstalten und der Ämter doch noch nie eine Rolle gespielt? 😉😝

            LG,
            CK

            -- https://wwwtech.de/about
  4. Hello,

    was mich aber nun neben dieser eher philosophischen Diskussion noch interessieren würde:

    Könnten wir bitte die Tab-Size für das Forum z. B. auf 4 einstellen? Ich halte 8 eindeutig für zu viel für die schmale Anzeigebreite, die üblicherweise zur Verfügung steht.

    Eure Meinung?

    Für meine persönliche Anzeige habe den Selector (bzw. Class) zwar schon ausfindig gemacht, aber für die Textarea zur Erfassung klappt es noch nicht. Und es nützt ja auch nichts, wenn sich das nur die angemeldeten Besucher einstellen können und alle anderen eine eher unlesbaren Text erhalten.

    Liebe Grüße
    Tom S.

    -- Es gibt nichts Gutes, außer man tut es
    Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
    1. @@TS

      Könnten wir bitte die Tab-Size für das Forum z. B. auf 4 einstellen? Ich halte 8 eindeutig für zu viel für die schmale Anzeigebreite, die üblicherweise zur Verfügung steht.

      Eure Meinung?

      Ja, unbedingt. Das wurmt micht auch schon einige Zeit.

      Ich würde sogar auf 2 runtergehen. Das ist wohl, was die meisten zur Einrückung bei Codebeispielen hier im Forum verwenden.

      Ich nehme das mal als <I> zu den anderen Styling-Sachen auf meiner Liste hinzu.

      LLAP 🖖

      -- “When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory
      1. Hallo Gunnar Bittersmann,

        Ja, unbedingt. Das wurmt micht auch schon einige Zeit.

        Ich würde sogar auf 2 runtergehen. Das ist wohl, was die meisten zur Einrückung bei Codebeispielen hier im Forum verwenden.

        Ich finde die Idee auch nicht schlecht.

        Allerdings kann der IE nicht damit um.

        https://github.com/ckruse/cforum/pull/750

        Bis demnächst
        Matthias

        -- Rosen sind rot.
        1. Hello,

          das DIV für die Darstellung später sollte auch nicht vergessen werden.

          Liebe Grüße
          Tom S.

          -- Es gibt nichts Gutes, außer man tut es
          Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.
          1. Hallo TS,

            das DIV für die Darstellung später sollte auch nicht vergessen werden.

            Stimmt, ansonsten ist das ziemlich witzlos. 😂 Ich habs den Code-Elementen zugeschlagen.

            Bis demnächst
            Matthias

            -- Rosen sind rot.
            1. Ich habe es in diesem Thread schon geschrieben, aber: Ihr wollt also Tabs nutzen, aber nur dann, wenn sie eine fest definierte Tab-Weite haben, die eher gering ist?

              Das ergibt einfach keinen Sinn. Wenn ihr eine fest definierte Weite haben möchtet, müsst ihr Spaces nutzen! So leid mir das tut.

              8 Spaces ist eine völlig normale Tab-Weite. Wem das zu viel ist, der darf keine Tabs nutzen. Das ist das Gesetz. Es ist mir auch egal, wie viele Downvotes das im Zweifel gibt. Es ist einfach so. Wenn ihr diese Flexibilität wollt, dann müsst ihr diese Flexibilität bitte auch zugestehen.

              Vergleiche zum Beispiel: https://www.kernel.org/doc/html/v4.10/process/coding-style.html (Punkt 1.)

              1. Ergänzend: Dabei ist zum Beispiel auch zu bedenken, was passiert, wenn Beispielcode hier aus dem Forum kopiert wird. Der mag dann hier mit 2 oder 4 Spaces eingerückt sein, weil euch/uns das hier so gefällt, aber das trifft eben überhaupt keine Aussage darüber, wie es beim Nutzer eingerückt sein wird. Wir treffen dann hier eine Annahme, dass 2 oder 4 Spaces super sind, aber es sind eben nicht 2 oder 4 Spaces. Und nach dem Kopieren sieht es beim Anwender dann eben irgendwie aus, wie es hier nie intendiert war. Das Problem, dass es doof aussieht, wird dann letztlich bloß weitergeschoben.

                1. Tach!

                  Ergänzend: Dabei ist zum Beispiel auch zu bedenken, was passiert, wenn Beispielcode hier aus dem Forum kopiert wird. Der mag dann hier mit 2 oder 4 Spaces eingerückt sein, weil euch/uns das hier so gefällt, aber das trifft eben überhaupt keine Aussage darüber, wie es beim Nutzer eingerückt sein wird. Wir treffen dann hier eine Annahme, dass 2 oder 4 Spaces super sind, aber es sind eben nicht 2 oder 4 Spaces. Und nach dem Kopieren sieht es beim Anwender dann eben irgendwie aus, wie es hier nie intendiert war. Das Problem, dass es doof aussieht, wird dann letztlich bloß weitergeschoben.

                  Das sieht nicht nur wegen der Einrückung anders aus, sondern auch wegen Klammernstil und gegebenenfalls Leerzeichensetzung zwischen den Ausdrücken. Das alles ist kein Beinbruch, weil die Einrückungen für den Code in den meisten Fällen bedeutungslos sind, es mit einem Tastendruck so formatiert ist wie man das persönlich mag und damit sowieso anders als beim ursprünglichen Autor aussah. Einzige Voraussetzung, man verwendet eine IDE oder einen Editor mit Reformatierung.

                  dedlfix.

              2. Hallo

                … Wenn ihr eine fest definierte Weite haben möchtet, müsst ihr Spaces nutzen! So leid mir das tut.

                Nein! Ich persönlich bevorzuge Einrückung mit Tab-Weite 2. Ich zwinge das aber Niemanden auf, denn wenn jemand anderes meine Programme verwendet und lieber 32 Stellen einrückt, kann er seinen Editor entsprechend konfigurieren.

                8 Spaces ist eine völlig normale Tab-Weite. Wem das zu viel ist, der darf keine Tabs nutzen. Das ist das Gesetz.

                Nein. Die Tab-Weite ist frei wählbar.

                Gruß
                Jürgen