Tabs vs. Leerzeichen

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
lunar

Dienstag 6. März 2007, 16:43

Mad-Marty hat geschrieben:Ich benutze zum beispiel 3 leerzeichen.
Wichtig ist einfach nur das du es konsistent machst.
IDEs erkennen das meist auch.
Das erzähl mal einem OpenSource Programmierer...

In der Realität sitzt man nicht alleine am Code, sondern arbeitet in der Regel im Team. Da ist es nicht wichtig, dass du konsistent bist, sondern dass alle konsistent sind.

Deswegen gibts ja Style Guides. Python stellt den Programmierer da nicht vor große Auswahl, den jenseits von PEP 8 gibt es nicht viel. Und was PEP 8 sagt, das wissen wir ja...
BlackJack

Dienstag 6. März 2007, 23:35

Noch ein Argument für 79/80 Zeichen pro Zeile: Häufiger als reinen Quelltext sehen sich viele Programmierer Patches oder Diffs aus der Versionsverwaltung in einem Terminal an.

Diese Diffs sind auch ein Argument gegen Tabs, weil man in Terminals normalerweise nicht einstellen kann, dass ein Tab nur 4 Zeichen entspricht und man damit dann wieder schnell die Standardbreite sprengt. Ausserdem gibt's in vielen Projekten Leute die sich alle Diffs vom Repository per Mail zuschicken lassen oder sich den Quelltext und Diffs per Webbrowser im Repository anschauen, in beiden Fällen hat man auch keine Kontrolle über die "breite" eines Tabs.
oliver1974
User
Beiträge: 97
Registriert: Donnerstag 26. Oktober 2006, 15:01

Mittwoch 7. März 2007, 10:05

Ich gestehe freimütig, dass ich mit den 80 Zeichen auch so meine Probleme habe... Das ist schon ARG wenig, wenn dann noch halbwegs sprechende Variablennamen / Methodenbezeichner hat, die dann auch nicht gerade kurz sind, ist man ruckzuck über 80 hinaus.

Ich sehe die Gründe ja alle irgendwie ein, aber ich bekomme irgendwo immer Augenkrebs wenn ich öfters umbrechen muss, damit ich EOL79 erfülle.

Irgendwie muss ich das mit mir auch selber ausmachen.. momentan sind meine Python-Skripte eher kleine, übersichtliche Progrämmchen, weil man "eben mal ein Tool" braucht... Dass die Skripte in einem Diff angezeigt werden oder irgendwie mal auf einer Konsole, ist an der Grenze zur totalen Unwahrscheinlichkeit.... Gedruckt habe ich Quellcode übrigens schon seit JAHREN nicht mehr..... Bin überrascht, dass das wirklich noch Leute machen.. Aber jeder hat da wohl seinen eigenen "Style" :-)

Es gibt x gute Gründe für EOL79, habt Ihr hier ja so schön dargelegt.. aber ich hab da eben irgendwie meine Probleme mit, ich komm leichter mit Quellcode klar der nicht diesen Umbruch drin hat...

Dass ich im Fall des Falles dann irgendwie Rücksicht nehmen muss (z.B. beim Posten in das Forum hier noch mal über den Code gehen und Umbrechen...) ist klar.
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 7. März 2007, 10:53

btw. [wiki]Lange Zeilen im Sourcecode[/wiki] :lol:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Mittwoch 7. März 2007, 13:43

Gerade Side-by-side-Diffs im Web (z.B. Trac), in separaten Diff-Anwendungen oder in IDEs wie Eclipse sind nur wirklich nützlich, wenn die Zeichenbreite vernünftig begrenzt ist. Und selbst das ist bei 1024x768 schon knapp, wenn Sidebars dazu kommen, umso mehr.

Die Gründe für EOL 79 sind handfest, praktisch und jeder Entwickler sollte durch Ausdrucke und Diffs mehr als einmal davon profitiert oder sich bei Nichteinhaltung geärgert haben. Einleuchtender geht es meiner Meinung nach nicht.

Achso, und sowas wie "wenn ich auf Tab drücke, will ich X Leerzeichen Einrückung, und Ausrücken über Umschalt-Tab o.ä. sollte das entsprechend rückwärts machen" kann *jeder* vernünftige Programmiereditor, so auch das von mir nachwievor verwendete SciTE (und entsprechend alle, die auf dessen Hauptwidget aufbauen [und die Konfigurationsoptionen dazu zulassen/nicht verbauen]).
lunar

Mittwoch 7. März 2007, 14:34

Y0Gi hat geschrieben:Gerade Side-by-side-Diffs im Web (z.B. Trac), in separaten Diff-Anwendungen oder in IDEs wie Eclipse sind nur wirklich nützlich, wenn die Zeichenbreite vernünftig begrenzt ist. Und selbst das ist bei 1024x768 schon knapp, wenn Sidebars dazu kommen, umso mehr.
Full ack. Ich schaue meine SVN Diffs mit kompare an. Die wirklich coole und übersichtliche zweispaltige Darstellung dieses Programms ist total für'n A****, wenn man überlange Zeilen verwendet, weil man dann selbst bei 1280x1024 ohne Sidebars wild scrollen muss, um den ganzen Code zu sehen.
oliver1974 hat geschrieben:Ich gestehe freimütig, dass ich mit den 80 Zeichen auch so meine Probleme habe... Das ist schon ARG wenig, wenn dann noch halbwegs sprechende Variablennamen / Methodenbezeichner hat, die dann auch nicht gerade kurz sind, ist man ruckzuck über 80 hinaus.
Mmmh, was schreibst du denn für Ausdrücke? Mein Limit steht aus Gewohnheit bei 76 Zeichen und trotzdem hat mein Code in den seltensten Fällen unlesbare Umbrüche. Bei meinen letzten 1000 Zeilen kamen pi*Auge vielleicht 30-50 Umbrüche innerhalb von Ausdrücken (lange Ausgabestrings natürlich nicht mitgezählt) und die meisten davon auch nur wegen den ellenlangen optparse Funktionen.

Umbrüche kann man doch recht einfach vermeiden, in dem man temporäre Variablen verwendet und aufhört Funktionen zu "schachteln" (z.B. funktion1(funktion2(param1, param2)) einfach trennen). Das macht den Code imho auch lesbarer...
oliver1974 hat geschrieben:Ich sehe die Gründe ja alle irgendwie ein, aber ich bekomme irgendwo immer Augenkrebs wenn ich öfters umbrechen muss, damit ich EOL79 erfülle.
Ich arbeite seit mehreren Jahren mit dem Limit 76 und kann trotzdem noch sehen (aber auch nur mit Brille ;) )
oliver1974 hat geschrieben:Irgendwie muss ich das mit mir auch selber ausmachen.. momentan sind meine Python-Skripte eher kleine, übersichtliche Progrämmchen, weil man "eben mal ein Tool" braucht... Dass die Skripte in einem Diff angezeigt werden oder irgendwie mal auf einer Konsole, ist an der Grenze zur totalen Unwahrscheinlichkeit....
Mmmh, eine Menge Leute (gerade unter Unix-artigen Systemen, insbesondere Linux) bewegen sich beim programmieren hauptsächlich auf der Konsole. Die Hauptentwickler von KDE programmieren iirc fast alle mit emacs, vi und Konsolentools statt mit ausgefeilten graphischen IDEs und das, obwohl sie in C++ eine graphische Oberfläche entwickeln...
oliver1974 hat geschrieben:Gedruckt habe ich Quellcode übrigens schon seit JAHREN nicht mehr..... Bin überrascht, dass das wirklich noch Leute machen.. Aber jeder hat da wohl seinen eigenen "Style" :-)
Mmmh, Drucken ist extrem praktisch, wenn man fremden Code verstehen muss. Da kann man dann mal eben mit Kuli was unterstreichen, oder Notizen machen und mehrere Blätter nebeneinander legen, um alles im Blick zu haben...
oliver1974
User
Beiträge: 97
Registriert: Donnerstag 26. Oktober 2006, 15:01

Mittwoch 7. März 2007, 14:37

jens hat geschrieben:btw. [wiki]Lange Zeilen im Sourcecode[/wiki] :lol:
...und das erste Beispiel zeigt mir gleich, warum ich mit den Umbrüchen nicht warm werde...
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 7. März 2007, 14:48

Wobei ich das so auch nicht mache. z.Z. mache ich das i.d.R. so:

Code: Alles auswählen

def test(txt, txt2="default", txt3="default", txt4="default", txt5="default",
                                            txt6="default", txt7="default"):

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
lunar

Mittwoch 7. März 2007, 15:10

Allerdings ist auch das Beispiel mit den Klammern etwas seltsam:

Code: Alles auswählen

def test(txt, txt2="default", txt3="default", txt4="default", txt5="default",
    txt6="default", txt7="default"):
    print txt, txt2
Normalerweise sind doch die folgenden Zeilen in gleicher Spalte wie die Klammer:

Code: Alles auswählen

def test(txt, txt2="default", txt3="default", txt4="default", txt5="default",
         txt6="default", txt7="default"):
    print txt, txt2
Zumindest emacs rückt so ein. Backslashes verwende ich nie, da man Umbrüche auch immer mit Klammern erreichen kann.
oliver1974
User
Beiträge: 97
Registriert: Donnerstag 26. Oktober 2006, 15:01

Mittwoch 7. März 2007, 15:30

Mmmh, was schreibst du denn für Ausdrücke?
Nichts ungewöhnliches, wirklich keine Monster... Ich wundere mich nur, warum da andere augenscheinlich immer so locker mit 79 Zeichen auskommen.
Umbrüche kann man doch recht einfach vermeiden, in dem man temporäre Variablen verwendet und aufhört Funktionen zu "schachteln"
Ehrlich gesagt, finde ich es aber auch nicht wirklich elegant, erstmal eine ganze Latte temporärer Variablen anzulegen, nur um dann Zeilenlängen-mäßig hinzukommen...
Ob das dann auch wirklich lesbarer wird , wenn ich jedesmal
"kurz = meinlangername" deklarieren muss.. na ja.

Ebenso das "Schachteln" von Funktionen... Dass die Schachtelung auf x-Ebenen nicht mehr wirklich übersichtlich ist, ist klar.. aber eine Schachtelung auf 2 Ebenen für Funktionen ist doch nun wirklich nicht so ungewöhnlich.. und halte ich auch
für eigentlich leichter zu lesen als vorher die ganzen einzelnen Funktionen erst rauszuziehen und deren Ergebnisse vorher wegzuspeichern...

Na ja, ich kann ja sonst mit allen StyleGuide Geschichten leben... Nur halt mit dem EOL79 hab ich leichte Probleme...

EDIT: Bei den geklammerten Geschichten habe ich auch generell weniger Probleme, die sind ja, wie beschrieben, leicht umzubrechen und sehen auch noch anständig aus, wenn die nächste Zeile in derselben Spalte steht. Aber die Variante mit den Backslashes ist (für mich) immer etwas hässlich.
Zuletzt geändert von oliver1974 am Mittwoch 7. März 2007, 15:56, insgesamt 1-mal geändert.
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mittwoch 7. März 2007, 15:42

zum Schachtel von Funktionen: Für das Debugging ist es auch nützlich wenn alles Schritt für Schritt gemacht wird ;)

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
lunar

Mittwoch 7. März 2007, 17:14

oliver1974 hat geschrieben:
Mmmh, was schreibst du denn für Ausdrücke?
Nichts ungewöhnliches, wirklich keine Monster... Ich wundere mich nur, warum da andere augenscheinlich immer so locker mit 79 Zeichen auskommen.
Siehst du, und ich wundere mich, wie man den über 80 Zeichen hinauskommt... ;)
Umbrüche kann man doch recht einfach vermeiden, in dem man temporäre Variablen verwendet und aufhört Funktionen zu "schachteln"
Ehrlich gesagt, finde ich es aber auch nicht wirklich elegant, erstmal eine ganze Latte temporärer Variablen anzulegen, nur um dann Zeilenlängen-mäßig hinzukommen...
Ob das dann auch wirklich lesbarer wird , wenn ich jedesmal
"kurz = meinlangername" deklarieren muss.. na ja.
Das mache ich ja auch nicht. Allerdings verwende ich auch keine Variablennamen mit mehr als 15 Zeichen. Wenn man einen ganzen Satz braucht, um eine Variable zu benennen

Code: Alles auswählen

ich_bin_eine_schoene_variable = True
dann ist da irgendwo was schiefgelaufen.

Die temporären Variablen nehme ich nur für Funktionsaufrufe. Statt

Code: Alles auswählen

print '\n'.join(map(str, instanz_liste))
würde ich im Zweifelsfall (z.B. bei Gefahr einer Überschreitung des Längenlimits) eher folgendes machen:

Code: Alles auswählen

str_list = map(str, instanz_liste)
print '\n'.join(str_list)
Ebenso das "Schachteln" von Funktionen... Dass die Schachtelung auf x-Ebenen nicht mehr wirklich übersichtlich ist, ist klar.. aber eine Schachtelung auf 2 Ebenen für Funktionen ist doch nun wirklich nicht so ungewöhnlich.. und halte ich auch für eigentlich leichter zu lesen als vorher die ganzen einzelnen Funktionen erst rauszuziehen und deren Ergebnisse vorher wegzuspeichern...
Mmmh, das ist sicherlich eine Frage des Geschmacks, aber wirkliche Unterschiede zwischen dem getrennten Schreiben und der Schachtelung gibt es bei wenigen Funktionen (so 2 bis 3) nicht wirklich. Deswegen sehe ich kein Problem, Ausdrücke auseinander zu ziehen, wenn ich Gefahr laufe, das Längenlimit zu überschreiten. Allerdings komme ich mit solchen Schachtelungen selten über das Limit hinaus. Mir ging es deswegen eher um Schachtelungen von vier bis fünf Funktionen

Auch ansonsten kann man mit 76 Zeichen gut leben, wenn man - wie ich - tiefe Einrückungen vermeidet.
EDIT: Bei den geklammerten Geschichten habe ich auch generell weniger Probleme, die sind ja, wie beschrieben, leicht umzubrechen und sehen auch noch anständig aus, wenn die nächste Zeile in derselben Spalte steht. Aber die Variante mit den Backslashes ist (für mich) immer etwas hässlich.
ack. Aber deswegen verwendet man den Backslash ja auch nicht...
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Donnerstag 8. März 2007, 14:47

Temporäre Variablen soll man benutzen, wenn sie die Lesbarkeit deutlich erhöhen. Weiterhin muss man Bedingungskonstrukte nicht ewig tief verschachteln, ich kann mich sogar gerade an keinen Fall erinnern, bei dem ich mehr als zwei if-else-Einrückungen benutzen musste.

Beispiel:

Code: Alles auswählen

if os.path.exists(some_path):
    if not some_path.endswith('/'):
        # Hier passiert das Eigentliche.
    else:
        print 'Scheint ein Verzeichnis zu sein!'
else:
    print 'Pfad existiert nicht!'
optimiert:

Code: Alles auswählen

if not os.path.exists(some_path):
    print 'Pfad existiert nicht!'
    return
if some_path.endswith('/'):
    print 'Scheint ein Verzeichnis zu sein!'
    return
# Hier passiert das Eigentliche.
Mad-Marty
User
Beiträge: 317
Registriert: Mittwoch 18. Januar 2006, 19:46

Donnerstag 8. März 2007, 17:20

lunar hat geschrieben:
Mad-Marty hat geschrieben:Ich benutze zum beispiel 3 leerzeichen.
Wichtig ist einfach nur das du es konsistent machst.
IDEs erkennen das meist auch.
Das erzähl mal einem OpenSource Programmierer...

In der Realität sitzt man nicht alleine am Code, sondern arbeitet in der Regel im Team. Da ist es nicht wichtig, dass du konsistent bist, sondern dass alle konsistent sind.

Deswegen gibts ja Style Guides. Python stellt den Programmierer da nicht vor große Auswahl, den jenseits von PEP 8 gibt es nicht viel. Und was PEP 8 sagt, das wissen wir ja...

Das ist mir völlig wurst was sich ein imaginärer OS Programmierer dazu denkt. Der wird meinen corporate code eh nie lesen.
lunar

Donnerstag 8. März 2007, 18:02

Mad-Marty hat geschrieben:
lunar hat geschrieben:
Mad-Marty hat geschrieben:Ich benutze zum beispiel 3 leerzeichen.
Wichtig ist einfach nur das du es konsistent machst.
IDEs erkennen das meist auch.
Das erzähl mal einem OpenSource Programmierer...

In der Realität sitzt man nicht alleine am Code, sondern arbeitet in der Regel im Team. Da ist es nicht wichtig, dass du konsistent bist, sondern dass alle konsistent sind.

Deswegen gibts ja Style Guides. Python stellt den Programmierer da nicht vor große Auswahl, den jenseits von PEP 8 gibt es nicht viel. Und was PEP 8 sagt, das wissen wir ja...
Das ist mir völlig wurst was sich ein imaginärer OS Programmierer dazu denkt. Der wird meinen corporate code eh nie lesen.
Na dann... Aber auch für deinen Code wird es wohl Richtlinien geben. Ich kann mir nicht vorstellen, dass eine Firma ihre Programmierer blind los coden lässt, ohne vorher zumindest etwas Einheitlichkeit zu schaffen...
Antworten