Codestyle: Einrücken von Leerzeilen?

Hacker schrieb:

Edit: Widerspruch: HF!! Was laberst du da! Wer proggt ohne Tabs? Ja, ein Oldschool-Progger hat hier nix zu suchen, wahrscheinlich schreibt er noch iostream.h.

Siehe:

Damit das ganze sauber funktioniert sollte man immer die gleiche Anzahl von Zeichen einrücken. Früher war es üblich, mit Hilfe eines Tabs einzurücken. Somit ergab sich eine Laufweite von 8 Zeichen. Heutzutage ist es eher üblich Tabs zu vermeiden und weniger einzurücken. Heute übliche Größen sind 4 Leerzeichen oder 2 Leerzeichen:

http://www.proggen.org/doku.php?id=c:style

Er hat uns auch die Einrückung mit 2 Leerzeichen beigebracht, damit wurden Tabs völlig unnötig.

Insofern ist das was unser Prof uns gelehrt hat, hoch modern. Du machst es falsch. Bist du Java Programmierer? Da ist es nämlich normal mit riesigen Tabs zu arbeiten, siehe die ganzen IDEs wie Eclipse und Co, die mindestens 4 zeichen mit einem Tab einrücken.

Hier sind sich die Leute übrigens auch einig, ohne Tabs zu arbeiten:
http://www.mikrocontroller.net/topic/130218

Einer Begründet es auch.

Die Google Coding Guidlines schreiben auch vor Leerzeichen zu verwenden und keine Tabs:

http://programmers.stackexchange.com/questions/114560/c-spaces-vs-tabs

Fazit:
Wer Tabs nimmt, der hat keine Ahnung.
Und mein Professor hatte Recht.

Aber deswegen bist du ja auch daheim selbst beigebrachter Hacker und kein an einer Hochschule mit akademischem Grad studierter Informatiker.

Daheim brüht man sich oft schlechte Angewohnheiten an, die man dann nicht mehr los wird.

Die Boost Library verlangt auch Leerzeichen anstatt Tabs.

Und die Boost Entwickler müssen es ja wissen.

Zum Thema:

use what ever you want for indenting, but use spaces for aligning.

Genau darum macht es Sinn auf Tabs gänzlich zu verzichten.
Denn dann kann man in seiner IDE bzw, in seinem Editor einstellen, daß alle Tabs beim Speichern in Leerzeichen umgewandelt werden sollen und beim eigentlichen Programmieren spart man sich dann Tipparbeit, weil man beim Ausrichten dann auf die Tab Taste zurückgreifen kann, ohne das es später stört.
Die Tabs werden ja dann schließlich vom Editor in Leerzeichen umgewandelt.

Wer also nur Leerzeichen für den gespeicherten Code benutzt, ist somit bei der Arbeit viel effizienter.

Eimfaches Beispiel
Ihr könnte ja mal so etwas ausrichente:

int megasuperlang 1;
  double kurz 2.0;
  char c 'c';
  String megalangersuperstring "blabla";

Wer hier zwischen den Wörtern die Tabs-Taste benutzen darf, weil der Editor sowieso alle Tabs in Leerzeichen umwandelt, erspart sich sehr viel Zeit beim Programmieren.

Somit habt ihr nun auch eine gute Begründung warum Tabs Pfui sind.

tntnet

Also wir verwenden bei unseren Projekten grundsätzlich Leerzeichen. Man kann sich natürlich darüber streiten, aber mein Argument ist, dass ich das leichter prüfen kann.

Ich kann einfach im Editor (oder mit grep über alle Dateien) nach Tabs suchen. Wenn ich einen finde, ist die Regel gebrochen.

Andersrum wenn Tabs zur Einrückung verwendet werden und ich nach Leerzeichen suche, werde ich wohl eine Menge false-positives bekommen da fast alle Codezeilen Leerzeichen enthalten .

Wenn ich Code lese, und er sieht gut aus, ist es nur bei Leerzeichen gewährleistet, dass der Code auch bei anderer Tabeinstellung des Editors noch gut aussieht. Ich sehe einfach zu oft Codestellen, wo eine Zeile mit Tabs eingerückt ist und die nächste Zeile mit Spaces. Und die übernächste Zeile verwendet 2 Tabs, die mit einem Space getrennt sind. Solche Sachen sind einfach zu üblich. Und mit grep kann ich solche Sachen aber auch sehr einfach lokalisieren.

Zeus

Widerspruch schrieb:

Hacker schrieb:

Edit: Widerspruch: HF!! Was laberst du da! Wer proggt ohne Tabs? Ja, ein Oldschool-Progger hat hier nix zu suchen, wahrscheinlich schreibt er noch iostream.h.

Siehe:

Damit das ganze sauber funktioniert sollte man immer die gleiche Anzahl von Zeichen einrücken. Früher war es üblich, mit Hilfe eines Tabs einzurücken. Somit ergab sich eine Laufweite von 8 Zeichen. Heutzutage ist es eher üblich Tabs zu vermeiden und weniger einzurücken. Heute übliche Größen sind 4 Leerzeichen oder 2 Leerzeichen:

http://www.proggen.org/doku.php?id=c:style

Er hat uns auch die Einrückung mit 2 Leerzeichen beigebracht, damit wurden Tabs völlig unnötig.

Insofern ist das was unser Prof uns gelehrt hat, hoch modern. Du machst es falsch. Bist du Java Programmierer? Da ist es nämlich normal mit riesigen Tabs zu arbeiten, siehe die ganzen IDEs wie Eclipse und Co, die mindestens 4 zeichen mit einem Tab einrücken.

Also die Seite als Referenz zu nehmen, sollte man vorsichtig sein, immerhin ist das Beispiel so gröttig schlecht, das vermittelt nix, weil sowohl "Guter Stil" und "Schlechter Stil" einfach schlechter Code ist.

Sorry, aber das Argument "Spaces garantieren, dass der Code überall gleich aussieht", ist einfach dämlich. Ich persönlich benutze Tabs mit Tabbreite 8, Ideone oder das Forum ersetzen durch 4 Spaces. Ich habe noch kein einziges mal gesehen, dass mein Code dadurch irgendwie hässlich geworden wäre, weil nun plötzlich die Einrücktungstiefe verändert wurde. Das ist doch gerade der Vorteil an Tabs: Jeder kann so weit einrücken, wie er will. Des Weiteren kann ich Tabs auch in jedem 08/15 Editor bearbeiten, bei Spaces muss ich X mal die Leertaste drücken, was nervig ist.

314159265358979__ schrieb:

Sorry, aber das Argument "Spaces garantieren, dass der Code überall gleich aussieht", ist einfach dämlich.

Nö, es ist fakt.

Merkt man dann, wenn man Code von Usern bekommt, die Tabs auch zum ausrichten verwenden.

Ich habe noch kein einziges mal gesehen, dass mein Code dadurch irgendwie hässlich geworden wäre, weil nun plötzlich die Einrücktungstiefe verändert wurde.

Teamwork ist wohl nicht dein Erfahrungsfeld.

Das ist doch gerade der Vorteil an Tabs: Jeder kann so weit einrücken, wie er will.

Und wenn er das dann auch zum Ausrichten verwendet hast du den Salat.

Des Weiteren kann ich Tabs auch in jedem 08/15 Editor bearbeiten, bei Spaces muss ich X mal die Leertaste drücken, was nervig ist.

Zum Progammieren verwende ich einen ordentlichen Editor oder eine Einrücktiefe von 2 Leerzeichen, weswegen micht das nicht stört.

Widerspruch schrieb:

Nö, es ist fakt.

Das bestreite ich ja nicht. Aber ich will das gar nicht so. Gerade weil ich eine unüblich hohe Einrückung von 8 Zeichen Breite verwende.

Widerspruch schrieb:

Merkt man dann, wenn man Code von Usern bekommt, die Tabs auch zum ausrichten verwenden.

Hab ja schon vorhin geschrieben, dass Tabs fürs Ausrichten ungeeignet sind.

Widerspruch schrieb:

Teamwork ist wohl nicht dein Erfahrungsfeld.

Ich bin kein beruflicher Programmierer, also richtig. Aber was willst du damit sagen?

Widerspruch schrieb:

Und wenn er das dann auch zum Ausrichten verwendet hast du den Salat.

Siehe oben. Tabs zum Ausrichten sind Käse.

Widerspruch schrieb:

Zum Progammieren verwende ich einen ordentlichen Editor oder eine Einrücktiefe von 2 Leerzeichen, weswegen micht das nicht stört.

Wenn ich nur eine kleine Änderung durchführen möchte, möchte ich nicht warten, bis meine IDE gestartet ist. Da tut's der Standard-Text-Editor des Systems auch.

314159265358979__ schrieb:

Das ist doch gerade der Vorteil an Tabs: Jeder kann so weit einrücken, wie er will.

Ne, das ist kein Vorteil, sondern im Team ein Nachteil! Wenn jeder verschiedene Tabweiten hat, dann können die Einrückungen bei dem einen noch gut aussehen, beim anderen aber besch...

Sieht bei dem Einen vielleicht so aus:

public void foo(arg1, arg2, arg3, arg4,
                arg5, arg6) {

Bei dem anderen vielleicht so:

public void foo(arg1, arg2, arg3, arg4,
    arg5, arg6) {

In deinem Beispiel wird nicht eingerückt, sondern Ausgerichtet. Also ein Fall für Spaces.

Jo, dann versuche mal diese Regel in einem Texteditor einzubauen...

Einfach so lange auf der Leertaste bleiben, bis entsprechend ausgerichtet ist. Wo liegt das Problem?

Das Problem ist, dass das nicht jeder im Team machen wird!
Hast du hingegen eine Regel in der IDE die ggf. auch noch den Code nach jedem Speichern entsprechend formatiert, ist das Thema gegessen.

Antoras

Diese Diskussion ist ein wenig obsolet - zumindest dann wenn man einen gescheiten Editor / eine gescheite Entwicklungsumgebung einsetzt. eclipse erlaubt es z.B. frei einzustellen wie viel Einrückung angezeigt wird und wie viel auch tatsächlich abgespeichert wird. Es ist also z.B. möglich zu sagen, dass zwei Leerzeichen abgespeichert, aber vier angezeigt werden sollen.
Wie gut das bei Ausrichtungen funktioniert kann ich nicht sagen, da ich die total dämlich finde und deshalb nie einsetze.

hustbaer

.

Antoras schrieb:

Wie gut das bei Ausrichtungen funktioniert kann ich nicht sagen, da ich die total dämlich finde und deshalb nie einsetze.

Gut ausgerichteter Code sorgt für mehr Übersicht.

Steffo schrieb:

314159265358979__ schrieb:

Das ist doch gerade der Vorteil an Tabs: Jeder kann so weit einrücken, wie er will.

Ne, das ist kein Vorteil, sondern im Team ein Nachteil! Wenn jeder verschiedene Tabweiten hat, dann können die Einrückungen bei dem einen noch gut aussehen, beim anderen aber besch...

Sieht bei dem Einen vielleicht so aus:
public void foo(arg1, arg2, arg3, arg4,
                arg5, arg6) {
Bei dem anderen vielleicht so:
public void foo(arg1, arg2, arg3, arg4,
    arg5, arg6) {

Dieses Beispiel ist nicht nur komisch - jeder im Team muss sich im klaren darüber sein, was eigentlich Ausrichtung und Einrückung heißt. Wenn einer zu dumm ist, ist ja klar, dass es nicht funktionieren kann. In deinem Beispiel müssen Leerzeichen verwendet werden; Prinzipiell dürfen überhaupt nur die Namensräume eingerückt werden, also wie hier:

void foo(int,
         double,
         std::string);///Leerzeichen, da von Leerzeichen oder anderen Zeichen und Wörtern und nicht von Tabs abhängig gemacht wird

int main()
{
    foo();//Tabs, hier ist ein "eigener" Namensraum
    int f,///Tabs...
        g;///Tabs und dann Leerzeichen, da von Leerzeichen und nicht von Tabs abhängig gemacht wird (siehe eine Zeile weiter oben bei int f)
}

void foo(int,
         double,
         std::string) {} ///Wieder nur Leerzeichen

@Hacker: Du meinst zwar vermutlich nicht Namensräume sondern Einrückungsebenen oder Scopes, aber du hast es erfasst.