ich weiß nicht welche Tabulatorbreite gängig benutzt wird wenn man C++ (oder auch andere Sprachen) programmiert? Ich habe bisher entweder 8 oder 4 benutzt wobei ich 4 "schöner" finde.

Gibt es Richtlinien (coding standard) die was vorgeben?

Danke euch

Bouncer schrieb:

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

ob das wichtig ist oder nicht, muss er wohl selber entscheiden

Bouncer schrieb:

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

ob das wichtig ist oder nicht, muss er wohl selber entscheiden

natürlich, wenn man's nur mit eigenen codes zu tun hat, dann ist es egal.

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

Wieso keine Tabs?

Sobald ich sie unter kate/kwrite ändere sind sie wieder unter vim anders.

ich weiß nicht welche Tabulatorbreite gängig benutzt wird wenn man C++ (oder auch andere Sprachen) programmiert?

das ist völlig wurst. und ich bevorzuge sogar echte tabs und keinen whitespace müll. denn code-einrückungen sollten semantisch sein und nicht "schön".

int    foo;
double bar;
for(;;)
    stuff();

sowas sieht "nett" aus, hat aber keinen mehrwert. interessant ist nur, dass der schleifenkörper eine einrückung hat.

int            foo;
double bar;
for(;;)
    stuff();

sieht zwar mit nem verhunzten tab komisch aus, verliert aber kein stück an einrückungsbedeutung.

am besten is dann eh so

int foo;
double bar;
for(;;)
    stuff();

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.

meinen code werden eine reihe anderer leute lesen, meist unter linux, deswegen frage ich .....also wie kann ich es hinbekommen dass die leute die ihn lesen auch was sauberes vor sich liegen haben?

Wenn du in einem Team arbeitest, mach das mit dem Team aus. Aber ganz egal ob du jetzt alleine programmierst oder mit anderen. Wichtig ist: erarbeitet euch (bzw. erarbeite dir, wenn du allein arbeitest) Code-Conventions und haltet euch alle daran. Zum Thema "lesserlicher Code" gehoert ja noch wesentlich mehr als "Tabulatorbreite", sondern auch Fragen wie "kommen die { und } auf eigene Zeilen oder nicht" und "wie benenn ich meine Variablen (cammelCase oder underscore_separated, ...)". Da hat jeder seine eigenen Vorstellungen und Geschmaecker, und es gibt zig Flamewars und Diskussionen zu diesen Themen (auch hier im Forum).

Egal ob du jetzt im Team arbeitest oder nicht, du wirst es nie Allen recht machen koennen! Es gibt hier keinen "richtigen" Weg, das ist echt nur eine Frage von Vorlieben. Es gibt auch in der Linuxwelt zig verschiedene Konventionen, und wenn du jetzt fragst, an welche du dich halten sollst, wirst du nur einen Flamewar heraufbeschwoeren. Such dir einen Stil, der dir gefaellt und halt dich daran, und basta
(Wenn du im Forum/Google z. B. nach "Coding Convention" suchst, wirst du garantiert genug Material finden, aus dem du deine eigenen Conventions zusammenstoepseln kannst)

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

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

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.

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.

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.

Edit: Allman heisst der Mensch...

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.

Tabs darf man nur benutzen wenn (...)

wer bistn du? die tab-polizei?

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

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)

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