Codestyle: Einrücken von Leerzeilen?

[314159265358979__]

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.

[Widerspruch]

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.

[314159265358979__]

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.

[Gast]

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

[314159265358979__]

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

[Gast]

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

[314159265358979__]

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

[Gast]

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]

.

[Widerspruch]

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.

[Gast]

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

[314159265358979__]

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

[Gast]

314159265358979__ schrieb:

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

Naja, nicht "Namensräume" vor denen namespace steht, aber ich seh was du meinst

[LordJaxom]

schlaumeier2 schrieb:

Es ist wichtig, dass keine Zeile mit einem Leerzeichen beendet wird. Auch Leerzeilen müssen unbedingt immer ganz leer sein. Sonst gehen die compilezeiten in die Höhe, da der Parser immer unnötigerweise Leerzeichen überspringen muss.

Einrückungen können mit Tabs erledigt werden. Ein Tab ersetzt mehrere Leerzeichen und spart dadurch compilezeit. Vom Speicherplatz auf der Platte ganz zu schweigen. Wer viel einrückt verschwendet auf seiner Festplatte sehr schnell mal das eine oder andere Kilobyte. Und wenn man daran denkt, was so ein Kilobyte früher mal gekostet hat...

Hat sehr zur Heiterkeit des heutigen Tages beigetragen

[Antoras]

Hacker schrieb:

void foo(int,
         double,
         std::string);

Selten einen hässlicheren Code gesehen. Wenn man schon jeden Parameter in einer Zeile haben möchte, dann kann man auch dem Ersten diese Zeile gewähren:

void foo(
  int a,
  double b,
  std::string c
);

Zumahl ich es absolut nutzlos finde die Parameter einer Funktion auf mehrere Zeilen umzubrechen solange diese nicht Gefahr laufen über den Bildschirmrand rauszugehen. Wenn man Parameter dokumentieren möchte, dann benutzt man dafür Dokumentationskommentare, die vor einer Funktion platziert werden und nicht zwischendrin.

Das Ziel sollte sowieso sein möglichst wenige Parameter an eine Funktion zu übergeben. Ein oder zwei sind ok, bei dreien wird es schon kritisch und bei allem was darüber hinaus geht sollte man sich über Refactoring Gedanken machen (von speziellen Ausnahmen wie z.B. Factory-Methoden mal abgesehen).

class A {
  int a;
  double b;
  std::string c;
}
void foo(A a);

So etwas nennt man dann objektorientiert (oder zumindest strukturiert). Hier besteht gar nicht mehr die Möglichkeit sich über so etwas dümmliches wie Code-Ausrichtungen Gedanken machen zu müssen.

Hacker schrieb:

int f,
        g;

Würg. Warum nicht

int f;
int g;

Dein Code spart ein paar Zeichen, dafür muss man sich aber über Code-Ausrichtung Gedanken machen, was nicht besser ist. Code auszurichten kostet Zeit und ist schwerer wartbar, da man den Typ nicht ändern kann, ohne dass man die restlichen Codezeilen wieder speziell darauf abstimmen muss.

Die beiden Beispiele oben zeigen imho nur, dass man sich dort mehr Gedanken über den Codestyle gemacht hat als über die Codedokumentation. Wenn auch nur der leiseste Verdacht aufkommen könnte, dass ein Codestück missverstanden wird, dann hat man was falsch gemacht. Wer selbsterklärenden Code schreibt, der schreibt auch schönen Code. Das eine folgt also aus dem anderen, anders herum ist das aber nicht der Fall (Anderer Meinung? Dann zeig mir ein Gegenbeispiel).

Ich möchte hier noch erwähnen, dass es kein Grund ist die Verantwortung für guten Code von sich wegzuschieben wenn eine Programmiersprache nicht genügend syntaktische Möglichkeiten bietet um optimalen Code zu schreiben.
Wenn der Typ zu lang ist und vllt. auch noch parametrisiert ist, dann muss man halt die Zeile umbrechen:

VeryLongType<AnotherLongType> andAVeryLongVarName =
  doSomething(param1);
VeryLongType<AnotherLongType> andAVeryLongVarNameNumber2 =
  doSomething(param2);

Egal ob man das jetzt als schön betrachtet oder nicht, man muss sich keine Gedanken über Codestyle machen, der Code stylt sich selbst.

Hier noch mal einen Hinweis zu eclipse. Dort muss ich nur schreiben

doSometing(param);

Dank einer speziellen Tastenkombination generiert mir eclipse darauf den Code

VeryLongType<AnotherLongType> doSomething = doSomething(param);

wobei der Variablenname selektiert wird, so dass man ihn anpassen kann. Kein Grund also sich darüber aufzuregen, dass man lange Typen schreiben muss.

[Gast]

Hacker schrieb:

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

Vielleicht werden PI und dir irgendwann klar, dass es die Welt da draußen gibt und eure Welt. Es wird genügend Leute geben, denen es zu dumm ist mehrere Sekunden lang auf die Leertaste zu drücken, nur um auszurichten. Mir persönlich ist es auch zu dumm. Ich sage dem Editor lieber, dass er Tabs durch 2 oder 4 Leerzeichen ersetzen soll und dann kann ich damit sehr effektiv einrücken UND ausrichten und da man das Ganze als Regel festlegen kann, kann auch niemand mehr dazwischen funken. Da man euren Vorschlag nicht als Regel in einer IDE einrichten kann (zumindest ist mir das nicht bekannt), ist euer Vorschlag auch weniger praktikabel. Aber vielleicht merkt ihr das irgendwann, wenn ihr mal in einem größeren Team zusammengearbeitet habt...

[AlterSack]

Hacker schrieb:

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.

Ach Kindchen. Du hast noch so unendlich viel zu lernen. Täusche doch bis dahin keine Erfahrung vor, die du noch nicht hast.

[noergel]

Klasse Comedy.
Trettet ihr damit auch auf. Bitte unbedingt die Tournedaten veröffentlichen.

[fdfdg]

Ich finde das Prinzip "mit Tabs einrücken, mit Spaces ausrichten" dem "nur Spaces" weit überlegen. Leider hat das Ganze zwei Probleme:

1. Zu viele Programmierer kapieren es einfach nicht, sind zu dumm. Besagter Prof zum Beispiel. Keine Ahnung, was daran so schwer sein soll, aber dann werden doch wieder Tabs zum Ausrichten und Spaces zum Einrücken verwendet. Deshalb ist es ein Graus, damit in einem Team zu arbeiten, die Leute kriegen es einfach nicht auf die Reihe.

2. Ich kenne keine IDE, die das anständig unterstützt. Tabs in Leerzeichen umzuwandeln können alle, aber z.B. nur ausrichtende Tabs in Leerzeichen umzuwandeln kann keine mir bekannte. Dabei würde das ja Problem (1) hinfällig machen, eine gute Unterstützung in Visual Studio könnte einiges bewirken.

Gibt es eigentlich Sourcecode-Cleaner, die daraufhin korrigieren können?