Tabs vs. Leerzeichen

[lunar]

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]

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]

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.

[jens]

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

[Y0Gi]

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]

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.

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

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 )

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

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]

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

...und das erste Beispiel zeigt mir gleich, warum ich mit den Umbrüchen nicht warm werde...

[jens]

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"):

[lunar]

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]

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.

[jens]

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

[lunar]

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]

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]

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]

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

[Leonidas]

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

Corporate Code? Das ist doch das was auf Worse Than Failure auftaucht und wo man immer rätselt von welchen Dämonen die Programmierer besessen waren?

[Nirven]

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

Wunschtraum

Und zumindestens meine kleinen Python-Sachen kann ich hier coden wie ich will, Richtlinien gibt es nur für die 'echten' Programmiere und ihr C++ *g*
Wobeio ich seit einem grausamen Erlebniss mit Boa
a) alles selber mache
und dabei versuche mich
b) an die PEP8 zu halten...

[Y0Gi]

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

Es geht gar nicht speziell um OSS. Es geht darum, dass auch *andere* deinen Code lesen können sollen, und das können entsprechend auch (ggf. zukünftige) Kollegen von dir sein. Und genau die werden dich nicht ganz zu Unrecht verfluchen, dass du dich nicht an einheitlich für alle Python-Projekte (empfehlend) vorgegebene Richtlinien (aka. PEP hältst - sie aber schon, wie sie es bei anderen Projekten gelernt haben.

[birkenfeld]

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

In der Tat. Ich hab das mal repariert, komischerweise scheint Moin etwas
in den Backslash hineininterpretieren zu wollen, sodass ich die zweite Zeile mehr einrücken musste als angezeigt wird...

Zumindest emacs rückt so ein. Backslashes verwende ich nie, da man Umbrüche auch immer mit Klammern erreichen kann.

ACK. Emacs FTW!

[joost]

Zu Richtlinien betreffs Einrückungen und Namenskonventionen:
Man hält den eigenen Code für sich selbst lesbarer, wenn man sich daran hält. Ich bin da ziemlich streng gegenüber meinen eigenen und verwende z.B. i immer für ints.

Von i abhängige ints in einer Schleife bekommen möglichst ii - das halte ich nicht zwingend ein, aber wenn ich ein ii sehe, kann ich sehr sicher sein, dass darüber ein i zumindest in früheren Versionen des Codes einmal existiert hat. Wenn ich in solchen Fällen i eliminieren kann, ändere ich 'ii' auch meist auf 'i'. Für 'iii' (selten) gilt Analoges.

Und ... Thus spoke the Lord ... finde ich sehr lustig und sehr richtig zugleich.