C++ Welche Tabulatorbreite?

[groovemaster]

Bouncer schrieb:

ist egal. wichtig ist nur, dass du keine 'echten tabs' benutzt, sondern spaces (0x20).

Totaler Käse. Wichtig ist nur, dass du Tabs und Spaces nicht mischst. Und wie Blue-Tiger sagt, wenn du im Team arbeitest, dass du dich an eine gemeinsame Konvention hältst.

thordk schrieb:

und ich bevorzuge sogar echte tabs und keinen whitespace müll

Yep, mache ich auch. Denn wenn man das strikt durchzieht, braucht man sich um Tab-Breite überhaupt keine Gedanken machen. Das hat lediglich Auswirkungen auf die Darstellung, nicht aber die Einrückung selbst.

[Bouncer]

LordJaxom schrieb:

Bouncer schrieb:

also mit linuxern ist das so'ne sache. die haben anstatt cr/lf nur eins davon am zeilenende.

Das hat erstens nichts mit Linux zu tun, und zweitens würde ich gerade gern wissen, was das mit der Frage zu tun hat, Apeman.

irgendwie war mir so, als hätte der OP erwähnt, dass er textfiles zwischen linux und win austauschen möchte. deshalb hab' ich ihn auf den unterschied hingewiesen.

groovemaster schrieb:

Bouncer schrieb:

ist egal. wichtig ist nur, dass du keine 'echten tabs' benutzt, sondern spaces (0x20).

Totaler Käse. Wichtig ist nur, dass du Tabs und Spaces nicht mischst.

naja, kann ja sein, dass du deine quelltexte mit 'nem editor schreibst, bei dem tabs und spaces unterschiedlich angezeigt werden (word? openoffice?). sowas wäre mir zu nervig. wenn ich die tab-taste drücke, dann will ich einfach nur schneller nach rechts als mit der space-taste und deshalb ist es besser, wenn der editor dann 4 spaces einfügt als einen tab-character, dessen breite nicht festgelegt ist.

groovemaster schrieb:

Das hat lediglich Auswirkungen auf die Darstellung, nicht aber die Einrückung selbst.

alles klar, du weisst bescheid

[groovemaster]

Bouncer schrieb:

naja, kann ja sein, dass du deine quelltexte mit 'nem editor schreibst, bei dem tabs und spaces unterschiedlich angezeigt werden (word? openoffice?). sowas wäre mir zu nervig. wenn ich die tab-taste drücke, dann will ich einfach nur schneller nach rechts als mit der space-taste und deshalb ist es besser, wenn der editor dann 4 spaces einfügt als einen tab-character

Begründung?

Bouncer schrieb:

dessen breite nicht festgelegt ist.

Was vollkommen belanglos ist, wenn du "echte" Tabs verwendest statt Spaces.

[Bouncer]

groovemaster schrieb:

Bouncer schrieb:

naja, kann ja sein, dass du deine quelltexte mit 'nem editor schreibst, bei dem tabs und spaces unterschiedlich angezeigt werden (word? openoffice?). sowas wäre mir zu nervig. wenn ich die tab-taste drücke, dann will ich einfach nur schneller nach rechts als mit der space-taste und deshalb ist es besser, wenn der editor dann 4 spaces einfügt als einen tab-character

Begründung?

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

groovemaster schrieb:

Bouncer schrieb:

dessen breite nicht festgelegt ist.

Was vollkommen belanglos ist, wenn du "echte" Tabs verwendest statt Spaces.

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 (zum glück gibt es 'indent' und ähnliche tools, die das wieder ausbügeln können).

[thordk]

auf der seite ist das beispiel hier:

typedef struct
{
  int _mp_alloc;                /* Number of *limbs* allocated and pointed
                                   to by the D field.  */
  int _mp_size;                 /* abs(SIZE) is the number of limbs
                                   the last field points to.  If SIZE
                                   is negative this is a negative
                                   number.  */
  mp_limb_t *_mp_d;             /* Pointer to the limbs.  */
} __mpz_struct;

wer so kommentiert, bei dem ist eh schon hopfen und malz verloren :p

typedef struct
{
  /* Number of *limbs* allocated and pointed
   * to by the D field.
   */
  int _mp_alloc;                

  /* abs(SIZE) is the number of limbs                                  
   * the last field points to.  If SIZE
   * is negative this is a negative
   * number.
   */
  int _mp_size;                 

  /* Pointer to the limbs.  */
  mp_limb_t *_mp_d;
} __mpz_struct;

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

[Blue-Tiger]

Bouncer schrieb:

groovemaster schrieb:

Bouncer schrieb:

naja, kann ja sein, dass du deine quelltexte mit 'nem editor schreibst, bei dem tabs und spaces unterschiedlich angezeigt werden (word? openoffice?). sowas wäre mir zu nervig. wenn ich die tab-taste drücke, dann will ich einfach nur schneller nach rechts als mit der space-taste und deshalb ist es besser, wenn der editor dann 4 spaces einfügt als einen tab-character

Begründung?

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

Es gibt genauso gute Argumente FUER Tabs
http://www.movementarian.org/docs/whytabs/
http://www.derkarl.org/why_to_tabs.html

In fact, the advantage of hard-tabs is demonstrated by the kde cvs repository. Most applications are indented with spaces, most of those are inconsistently tabbed. Of the few tabbed modules (aRts, Noatun), the code is exactly 100% consistent.

[But god didn't listen]

Blue-Tiger schrieb:

Es gibt genauso gute Argumente FUER Tabs

ja, es ist, wie so vieles beim programmieren, eine glaubensfrage.
ich z.b. verwende nur spaces und gehe damit von vorn herein allen tab-problemen aus dem weg.

[Gast]

Persönlich 4. Ist aber dank indent total egal. Ebenso Tab/Space, Allman/K&R/GNU, ...

Edit: Allman heisst der Mensch...

[einGastZuViel]

Ah ich danke allen für ihren regen Beitrag - ihr habt mir (auch wenn ihr es nicht glaubt) doch um einiges weitergeholfen. Ich hoffe das eskaliert hier jetzt nicht

[DrGreenthumb]

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

void func(int a,
          int b)
{
}

Tabs darf man nur benutzen wenn man genau weiß was man tut. Die wenigsten tun das aber und sobald der Code dann mal mit anderer Tabweite dargestellt wird ist er verhunzt.

[tolulol]

DrGreenthumb schrieb:

Tabs darf man nur benutzen wenn (...)

wer bistn du? die tab-polizei?

[rüdiger]

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

[Blue-Tiger]

*g* gut, wenn der Threadersteller jetzt eh seine Antwort hat koennen wir ja noch etwas weiterdiskutieren. Finds cool mal einen ernsthaften Thread ueber das Thema zu haben

DrGreenthumb schrieb:

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

void func(int a,
          int b)
{
}

Tabs darf man nur benutzen wenn man genau weiß was man tut. Die wenigsten tun das aber und sobald der Code dann mal mit anderer Tabweite dargestellt wird ist er verhunzt.

Ich bin Tab-Verfecheter, aber das wuerd ich natuerlich mit Spaces einruecken ==> Tabs for indentation, spaces for alignment.

anderes Beispiel:

if (a && b)
{
    doSomething(a_very_long_parameter,
                another_one);
}

wuerd ich so einruecken:

if (a && b)
{
[i]<tab>[/i]doSomething(a_very_long_parameter,
[i]<tab>[/i]............another_one);
}

Sprich: was nicht Einrueckung ist, sondern zum "Code-Formattieren" gehoert, mach ich mit Spaces damit es auch bei anderen Tab-Widths noch vernuenftig ausschaut (was bei Spaces-Einrueckungen nicht moeglich ist, da ist die Einrueckbreite "fix"). Aber der "echte" Grund, warum ich Tabs bevorzuge, ist folgender:

if (a)
{
    int x = blubb();
    doSomething();
    int y = frablabla();
}

Angenommen ich moechte jetzt was auskommentieren:

// MIT TABS: layout bleibt erhalten
if (a)
{
    int x = blubb();
//  doSomething();
    int y = frablabla();
}

// MIT SPACES: layout bleibt nicht erhalten
if (a)
{
    int x = blubb();
//    doSomething();
    int y = frablabla();
}

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)

[DrGreenthumb]

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.

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

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