Diskussion zu PEP8!
-
- User
- Beiträge: 97
- Registriert: Donnerstag 26. Oktober 2006, 15:01
Hi Gerold!
Das sind schon mal durchaus gute Gründe.
Ich benutze ansonsten auch eine IDE (Eclipse) für Java
(das Python Plug-In muss ich noch testen!), aber generell
habe ich da einen anderen Geschmack, bevor ich mir Zeilenumbrüche
antue, scrolle ich lieber.. ist durchaus der Regelfall, wenn man,
wie du schon erwähntest, mehrer Fenster nebeneinander hat.
Scheint jetzt irgendwie Geschmackssache zu sein, mich hat
das scrollen weniger gestört als das "zerreissen" der lines.
Na ja, mal sehen wie ich in Zukunft mit den 80 Zeichen zurecht komme...
Das sind schon mal durchaus gute Gründe.
Ich benutze ansonsten auch eine IDE (Eclipse) für Java
(das Python Plug-In muss ich noch testen!), aber generell
habe ich da einen anderen Geschmack, bevor ich mir Zeilenumbrüche
antue, scrolle ich lieber.. ist durchaus der Regelfall, wenn man,
wie du schon erwähntest, mehrer Fenster nebeneinander hat.
Scheint jetzt irgendwie Geschmackssache zu sein, mich hat
das scrollen weniger gestört als das "zerreissen" der lines.
Na ja, mal sehen wie ich in Zukunft mit den 80 Zeichen zurecht komme...
80 Zeichen ist die Standardbreite von Unix-Terminals.
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.
Wie man Fragen richtig stellt
Außerdem gibt es eine irrationale.
Wie man Fragen richtig stellt
- jens
- Moderator
- Beiträge: 8483
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ja... Auch wenn ich PyLucid noch einige längere Zeilen stecken, aber das sind meist alte Codezeilenoliver1974 hat geschrieben:An die Regel von wegen 80 Zeichen Länge.. Haltet Ihr euch wirklich dran?

Ansonsten beschränke ich mich auf 80 bzw. 79 Zeichen, seid dem ich weiß wie man in SciTE eine vertikale Linie an der Stelle hinsetzten kann:
# Vertikale Linie zur Textberenzung auf 79 Zeichen
edge.column=79
edge.mode=1
edge.colour=#dddddd

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hi oliver!oliver1974 hat geschrieben:Scheint jetzt irgendwie Geschmackssache zu sein, mich hat das scrollen weniger gestört als das "zerreissen" der lines.
Das Umbrechen ist gar nicht so schwer wie viele glauben. Hier ein paar Beispiele, die aufzeigen wie ich lange Zeilen umbreche. Man muss es ja nicht so wie ich machen... -- soll nur eine Anregung sein.
Code: Alles auswählen
def meine_funktion(
argument1, argument2, argument3, argument4,
argument5 = None, argument6 = None
):
if (
argument1 == "langer Text" and
argument2 == "langer Text" and
argument3 == "auch ein langer Text"
):
message = (
"Das ist die perfekte Welle. Das ist der perfekte Tag. "
"Das ist die perfekte Welle. Das ist der perfekte Tag. "
"Das ist die perfekte Welle. Das ist der perfekte Tag. "
"Das ist die perfekte Welle. Das ist der perfekte Tag.\n"
"Wir sind gekommen um zu bleiben. Wir sind gekommen um zu bleiben.\n"
"Wir sind gekommen um zu bleiben. Wir sind gekommen um zu bleiben.\n"
)
return message
else:
return "Hallo Welt"
a = meine_funktion(
argument1 = "Das ist langer Text", # hier kann auch eine Bemerkung stehen
argument2 = "Das ist langer Text",
argument3 = "Das ist langer Text", # hier kann auch eine Bemerkung stehen
argument4 = "Das ist langer Text", # hier kann auch eine Bemerkung stehen
)
print a
Gerold

http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
- jens
- Moderator
- Beiträge: 8483
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ich würde es ähnlich machen, allerdings nicht bei der funktions definition und nicht beim if... Ich mache es dann ehr mit einem "\":
Wobei das auch nicht ganz so aufgeräumt aussieht... Aber ich finde das "):" alleine auf einer Zeile irgendwie komisch.
Code: Alles auswählen
def meine_funktion(argument1, argument2, argument3, argument4, \
argument5 = None, argument6 = None):
if (argument1 == "langer Text" and argument2 == "langer Text" and \
argument3 == "auch ein langer Text"):
CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Wenn man in der Regel beträchtliche Einrückungen hat, dann deutet das aber auch auf ein Problem hin. Der Quelltext ist dann meistens so komplex, das es sich lohnt ihn in Unterfunktionen aufzuteilen.oliver1974 hat geschrieben:Hmm, ich benutze eigentlich nicht gerade mega-lange Klassen- und
Methodennamen, trotzdem finde ich es doch recht störend,
alle naselang umzubrechen, schließlich hat man ja in der
Regel auch beträchtliche Einrückungen.
Terminals/Konsolen sind in der Regel 80 Zeichen breit und manchmal muss man doch mal schnell den Quelltext dort lesen.Ich bin da echt drauf und dran, in diesem Zusammenhang die PEP8
zu ignorieren.... Abgesehen vom Stilbruch, was hat es sonst
für negative Auswirkungen?
Diffs werden schnell unleserlich wenn die Zeilen bei der Anzeige umgebrochen werden. Quelltextschnippsel in Mail oder Newsgroups sind keine gute Idee wenn das entspechende Programm überlange Zeilen umbricht, insbesondere bei Python wo das syntaktische Fehler produziert.
Quelltext in Dokumentation übernehmen funktioniert auch besser, wenn man ihn nicht mikroskopisch klein drucken will um die Zeilen auf's Papier bringen zu können.
Und rein vom Lesefluss sind bei Fliesstext ca. 60 Zeichen pro Zeile optimal. Bei Quelltext darf's ein bisschen mehr sein weil die Zeilen nicht so "vollgepackt" sind, aber irgendwann wirkt sich ein langer Weg vom Zeilenende zum Zeilenanfang auch hier negativ aus.
Die 80 Zeichen-Regel im Style-Guide wird in vielen Projekten/Firmen vorgeschrieben, egal bei welcher Programmiersprache.
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Das funktioniert natürlich auch wunderbar ohne "".jens hat geschrieben:Ich mache es dann ehr mit einem "":Code: Alles auswählen
def meine_funktion(argument1, argument2, argument3, argument4, \ argument5 = None, argument6 = None):
Ok, die Einrückungen spielen natürlich schon eine Rolle. Bei Google benutzt man zwei Spaces, das ist mir aber nicht undeutlich genug. Manche mögen acht Spaces oder Tabs dieser Breite benutzen - dann ist es natürlich ein Leichtes, horizontal an solche Grenzen zu stoßen. AFAIK empfielt PEP 8 aber eine Einrückung von vier Spaces (oder?).
Wenn das immer noch problematisch ist, kann man sich vielleicht bei Funktionsnamen etwas zurückholen; allemal aber bei Variablennamen. Eine Instanz der Klasse SuperXmlThingy muss man nicht `superXmlThingy`nennen, `sxt` tut wunderbar und erhöht die Übersicht sowie verringert die Wahrscheinlichkeit von Tippfehlern, wenn man sowas nicht per Copy/Past übernimmt (was wohl eher wenige tun). Und Auto-Vervollständigung ist IDEs vorbehalten und keinesweges vorauszusetzen.
BlackJack nennt auch richtig: Bei zu vielen Einrückungen, lässt sich vermutlich einiges auslagern und schon wird es wieder übersichtlicher.
Auch sollte man sich sinnvoll Einrückungen bedienen, um nicht unnötig tiefe, meist einfache Verschachtelungen zu erzeugen.
Ein Beispiel:
Wenn man sowieso was mit return zurückliefert anstatt wie her auszugeben, spart man sogar noch die eine oder andere Zeile komplett.
Ok, offenbar bin ich etwas langsam (oh, Seite 3 übersehen...), aber was soll's:
80 Zeichen machen sehr wohl Sinn, denn das ist die Standardbreite von Terminals. Auch bereits bei 90 Zeichen sieht man zwangsläufig Dinge nicht, und man kann nicht immer im Fullscreen (hier: mit einer höheren Anzahl Zeilen und Spalten) arbeiten. Im Terminal in einem Texteditor horizontal zu scrollen ist definitiv keine vernünftige Alternative, die man in Kauf nehmen kann.
Jens: Wenn du dich bei deinem Codebeispiel an der hier diskutierten PEP 8 orientiert hättest, hättest du auf die Leerzeichen um das Gleichheitszeichen in den Funktionsargumenten sowie die Klammern bei der if-Bedingung verzichtet und so schon einiges eingespart
Wenn das immer noch problematisch ist, kann man sich vielleicht bei Funktionsnamen etwas zurückholen; allemal aber bei Variablennamen. Eine Instanz der Klasse SuperXmlThingy muss man nicht `superXmlThingy`nennen, `sxt` tut wunderbar und erhöht die Übersicht sowie verringert die Wahrscheinlichkeit von Tippfehlern, wenn man sowas nicht per Copy/Past übernimmt (was wohl eher wenige tun). Und Auto-Vervollständigung ist IDEs vorbehalten und keinesweges vorauszusetzen.
BlackJack nennt auch richtig: Bei zu vielen Einrückungen, lässt sich vermutlich einiges auslagern und schon wird es wieder übersichtlicher.
Auch sollte man sich sinnvoll Einrückungen bedienen, um nicht unnötig tiefe, meist einfache Verschachtelungen zu erzeugen.
Ein Beispiel:
Code: Alles auswählen
# "schlecht"
def blubb(x):
if isinstance(x, list):
y = x.pop()
if y > 2:
print y ** 3
else:
print 'y should be greater than 2'
else:
print 'x must be a list!'
# "gut"
def blubb(x):
if not isinstance(x, list):
print 'x must be a list!'
return
y = x.pop()
if y <= 2:
print 'y should be greater than 2'
return
print y ** 3
Ok, offenbar bin ich etwas langsam (oh, Seite 3 übersehen...), aber was soll's:
80 Zeichen machen sehr wohl Sinn, denn das ist die Standardbreite von Terminals. Auch bereits bei 90 Zeichen sieht man zwangsläufig Dinge nicht, und man kann nicht immer im Fullscreen (hier: mit einer höheren Anzahl Zeilen und Spalten) arbeiten. Im Terminal in einem Texteditor horizontal zu scrollen ist definitiv keine vernünftige Alternative, die man in Kauf nehmen kann.
Jens: Wenn du dich bei deinem Codebeispiel an der hier diskutierten PEP 8 orientiert hättest, hättest du auf die Leerzeichen um das Gleichheitszeichen in den Funktionsargumenten sowie die Klammern bei der if-Bedingung verzichtet und so schon einiges eingespart

Klaro! Und sowas steht ja auch in dem Artikel "How To Write Unmaintainable Code" in der Sektion "Naming". Sorry, aber damit hab ich mich schon so viel rumgeärgert. Nicht nur über Kollegen, die sowas machen und den Code somit vollkommen unverständlich machen, auch über mich selbst, wenn ich Monate später rausfinden muss, was ich mit der Variable r2 gemeint hab.Y0Gi hat geschrieben:Wenn das immer noch problematisch ist, kann man sich vielleicht bei Funktionsnamen etwas zurückholen; allemal aber bei Variablennamen. Eine Instanz der Klasse SuperXmlThingy muss man nicht `superXmlThingy`nennen, `sxt` tut wunderbar und erhöht die Übersicht
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.
Wie man Fragen richtig stellt
Außerdem gibt es eine irrationale.
Wie man Fragen richtig stellt
Das ist natürlich nix für in weiterem Kontext verfügbare Variablen, sondern nur für kleine, lokale. Ähnlich wie i und j, k und v. Wenn man aus dem Kontext nicht erkennt, was die Variable da wohl soll, dann ist ihr name noch das kleinere Problem.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hi Y0Gi!
Ich glaube, du hast da etwas falsch verstanden. Es ist nicht oberstes Gebot, den Code kurz zu halten. Python-Code soll gut lesbar und auch nach Jahren noch nachvollziehbar sein. -- Dann ist es guter Python-Code.
mfg
Gerold

Ich glaube, du hast da etwas falsch verstanden. Es ist nicht oberstes Gebot, den Code kurz zu halten. Python-Code soll gut lesbar und auch nach Jahren noch nachvollziehbar sein. -- Dann ist es guter Python-Code.
mfg
Gerold

http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
...Y0Gi hat geschrieben:Ähnlich wie i und j, k und v.
``i`` kenne ich. Das ist meist eine Zähler-Variable, die mit Ganzzahlen gefüllt sein soll. Wird oft in For-Schleifen eingesetzt.
``j``, ``k`` und ``v``??? -- noch nie in gut lesbaren Programmen gesehen.
mfg
Gerold

http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Es geht mir ja auch nicht darum, auf Teufel komm raus jedes Zeichen einzusparen.
i und j sind gängig in zwei verschachtelten Schleifen; das ist IMHO Quasi-Standard, genau wie z.B. n und m bei Mathematikern oder im ER-Modell
k, v: `for k, v in some_dict.iteritems(): print k, '=', v` (kein optimales Beispiel, zugegeben, aber dass da von "key" und "value" die Rede ist, liegt einfach auf der Hand)
Wie ich ja schrieb: Der Kontext macht die Musik.
Oder, um aus Unmaintainable Code: Naming zu zitieren:
Um weiter o.g. darzustellen
Ersteres ist ja wohl deutlich über- und klar ersichtlicher als zweites, bei dem man sogar leicht die Instanz mit dem Klassennamen verwechseln kann.
i und j sind gängig in zwei verschachtelten Schleifen; das ist IMHO Quasi-Standard, genau wie z.B. n und m bei Mathematikern oder im ER-Modell
k, v: `for k, v in some_dict.iteritems(): print k, '=', v` (kein optimales Beispiel, zugegeben, aber dass da von "key" und "value" die Rede ist, liegt einfach auf der Hand)
Wie ich ja schrieb: Der Kontext macht die Musik.
Oder, um aus Unmaintainable Code: Naming zu zitieren:
Und dann hast du i und j noch nicht gesehen? Hm... dass du wenig Quelltext gelesen hast, wage ich mal zu bezweifeln - und davon sollte doch durchaus einiges als "gut lesbare Programme" durchgehen können, oder?anyone even hints at breaking the tradition honoured since FØRTRAN of using i, j, and k for indexing variables
Um weiter o.g. darzustellen
Code: Alles auswählen
def create_stuff(x):
sxt = SomeXmlThingy()
sxt.append(x)
sort(sxt)
return sxt
# versus
def create_stuff(x):
someXmlThingy = SomeXmlThingy()
someXmlThingy.append(x)
sort(someXmlThingy)
return someXmlThingy
Zuletzt geändert von Y0Gi am Montag 13. November 2006, 11:47, insgesamt 1-mal geändert.
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Ich finde auch, dass Instanznamen wie "elementTreeBuilder" etwas übertrieben sind.
Vielleicht hab ich als Physiker aber auch einen anderen Standpunkt, bei uns gibts für jede Größe nur einen Buchstaben, höchstens mal nen Index dazu
Vielleicht hab ich als Physiker aber auch einen anderen Standpunkt, bei uns gibts für jede Größe nur einen Buchstaben, höchstens mal nen Index dazu

Da schreibe ich trotzdem `key` und `value`. Es ist noch einen Tick deutlicher und nun wirklich nicht soviel länger.Y0Gi hat geschrieben:k, v: `for k, v in some_dict.iteritems(): print k, '=', v` (kein optimales Beispiel, zugegeben, aber dass da von "key" und "value" die Rede ist, liegt einfach auf der Hand)
Wie ich ja schrieb: Der Kontext macht die Musik.
Ich denke es geht speziell um Python. Zwei verschachtelte Schleifen über Integerwerte kommen da wirklich nicht allzu häufig vor. In anderen Sprachen sind das in der Regel Schleifen, die mit den Indizes auf "Container" zugreifen, wo man in Python direkt über deren Elemente iteriert.Oder, um aus Unmaintainable Code: Naming zu zitieren:Und dann hast du i und j noch nicht gesehen?anyone even hints at breaking the tradition honoured since FØRTRAN of using i, j, and k for indexing variables
Wenn Du Dich an PEP8 bei der Namensgebung gehalten hättest, dann wäre es schon unproblematischer. Beide Varianten leiden daran, dass der Name nicht die Bedeutung beschreibt, sondern den Typ, d.h. wenn `SomeXmlThingy` im Laufe der Zeit durch `SomeJSONThingy` ersetzt wird, dann ist der Name plötzlich "falsch".Um weiter o.g. darzustellenErsteres ist ja wohl deutlich über- und klar ersichtlicher als zweites, bei dem man sogar leicht die Instanz mit dem Klassennamen verwechseln kann.Code: Alles auswählen
def create_stuff(x): sxt = SomeXmlThingy() sxt.append(x) sort(sxt) return sxt # versus def create_stuff(x): someXmlThingy = SomeXmlThingy() someXmlThingy.append(x) sort(someXmlThingy) return someXmlThingy
Wenn man voraussetzt, dass der Funktionsname richtig gewählt wurde, dann könnte man den Namen `stuff` verwenden. Ich hätte wahrscheinlich den Namen `result` an dieser Stelle gewählt. Was erzeugt wird, sagt schon der Funktionsname und so weiss man die ganze Funktion hindurch, welches Objekt darauf vorbereitet wird am Ende als Rückgabewert zu dienen.