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
Diskussion zu PEP8!
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
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.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hi Y0Gi!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)
[...]anyone even hints at breaking the tradition honoured since FØRTRAN of using i, j, and k for indexing variables
Letzte Erklärung von mir zu diesem Thema:
Erstens zitierst du, dass i, j, und k Variablenamen sind, die gerne für Indizes heran gezogen werden und im gleichen Aufwischen verwendest du k um darin einen **Key** abzulegen. Was du dir mit ``k`` gedacht hast, ist nur im direkten Kontext ermittelbar.
Zweitens, möchte ich klar stellen, dass Programme wachsen und es nicht sicher ist, dass man 20 Zeilen weiter unten nicht doch wieder den Wert einer Variablen braucht, die vorher nur mit k, x oder v zugewiesen wurde.
Durch die Verwendung von nicht aussagekräftigen Variablenamen zwingst du andere oder später auch dich selbst dazu, mehr Code durchlesen zu müssen, um herauszufinden was den jetzt wirklich in k, x oder v drinnen steht.
Ich persönlich bevorzuge Code, den ich mit den Augen scannen kann. Also Quellcode, in dem ich ziemlich schnell die Stelle finde, in der ich z.B. ein Problem vermute. Wenn ich mir den Quellcode komplett durchlesen muss um eine Stelle zu finden, dann empfinde ich das als großen Nachteil.
Das Problem ist nicht das Verwenden von solchen Kurzbezeichnern in einfachen Schleifen, sondern die Verwendung von Kurzbezeichnern in komplexeren oder längeren Algorithmen. Und wenn ich nicht ausschließen kann, ob es komplexer wird, dann sind aussagekräftige Variablen schon etwas feines.
Das ist schon ein bischen übertrieben. Man könnte ja auch kürzere Namen finden, die trotzdem aussagen, was darin gespeichert ist. Z.B.:someXmlThingy = SomeXmlThingy()
Code: Alles auswählen
root = XmlThing().get_root()
# oder
article = get_article(1234)
# oder
for adr in cur.fetchall():
print adr["vorname"], adr["nachname"]
Wie auch immer... Meist ist der mittlere Weg nicht schlecht. In einfachen Schleifen kann man ja machen wie man will, aber in längeren sollten die Bezeichner aussagekräftig sein.
@birkenfeld: In der Physik haben diese Buchstaben eine, meist exakt definierte, Bedeutung. Wenn ich ein Programm schreiben würde, in dem mit Einheiten der Elektrik gerechnet wird, dann ist es ja auch für niemanden ein Problem, wenn ``v``, ``w`` oder ``a`` verwendet wird. Jeder weiß sofort, was damit gemeint ist. Wenn ich diese Variablenamen aber in einer Rezeptverwaltung verwende, dann weiß niemand was damit gemeint sein könnte. (Das ist wieder so ein Extrembeispiel, aber mir ist nichts besseres eingefallen.)
...just my two cent...
lg
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: Dass das 'k' in dem von mir zitierten Teil auftaucht, ist Pech für mich; ich wäre gerne nur bei i und j geblieben.
BlackJack: Bei enumerate() benutze ich gerne ein i, ist ja schließlich auch der Index.
Das riecht mir persönlich hier zu sehr schon nach Glaubenskrieg, obwohl wir vermutlich zu großen Teilen identische Ansichten haben. Insgesamt halte ich PEP 8 für ein sehr wichtiges "Feature von Python" und ich bin ebenso erfreut wie erstaunt, dass sich doch so viele Leute zu sehr großen Teilen daran halten. Dagegen ist das, was übrig bleibt, schon kaum mehr der Rede wert.
BlackJack: Bei enumerate() benutze ich gerne ein i, ist ja schließlich auch der Index.
Dass genau dieser Kontext für das Verständnis essentiell ist, habe ich glaube ich schon mehrmals geschrieben. Dass solche "super-lokalen" Variablen später verwendet werden sollen, habe ich ebenso wenig befürwortet. Wenn dann auch noch "20 Zeilen weiter unten" die Variable verwendet *würde*, hat man definitiv den Code nicht gut aufgeteilt. Wenn Programme wachsen, muss man beim Refactoring auch schon mal ein paar Variablennamen anpassen, *wenn* es denn sein muss.gerold hat geschrieben:Was du dir mit ``k`` gedacht hast, ist nur im direkten Kontext ermittelbar.
In ihrem - sehr kleinen - Kontext(sic!) sind die Namen sehr wohl aussagekräftig, da braucht man keine zehn Zeilen nach oben oder unten springen, um deren Bedeutung zu erfahren.gerold hat geschrieben:Durch die Verwendung von nicht aussagekräftigen Variablenamen zwingst du andere oder später auch dich selbst dazu, mehr Code durchlesen zu müssen, um herauszufinden was den jetzt wirklich in k, x oder v drinnen steht.
Das habe ich ebensowenig befürwortet!gerold hat geschrieben:Das Problem ist nicht das Verwenden von solchen Kurzbezeichnern in einfachen Schleifen, sondern die Verwendung von Kurzbezeichnern in komplexeren oder längeren Algorithmen.
Das riecht mir persönlich hier zu sehr schon nach Glaubenskrieg, obwohl wir vermutlich zu großen Teilen identische Ansichten haben. Insgesamt halte ich PEP 8 für ein sehr wichtiges "Feature von Python" und ich bin ebenso erfreut wie erstaunt, dass sich doch so viele Leute zu sehr großen Teilen daran halten. Dagegen ist das, was übrig bleibt, schon kaum mehr der Rede wert.
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hi Y0Gi!Y0Gi hat geschrieben:Das riecht mir persönlich hier zu sehr schon nach Glaubenskrieg, obwohl wir vermutlich zu großen Teilen identische Ansichten haben. Insgesamt halte ich PEP 8 für ein sehr wichtiges "Feature von Python" und ich bin ebenso erfreut wie erstaunt, dass sich doch so viele Leute zu sehr großen Teilen daran halten. Dagegen ist das, was übrig bleibt, schon kaum mehr der Rede wert.
...bin deiner Meinung!
lg
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:
Zum Post vom Fr Nov 10, 2006 17:39 :
Danke für das Beispiel. Ich werde dann auch überall eine -1 übergeben.
Ich finde EOL79 sehr sogar sinnvoll, da in einer Konsole max. 79 angezeigt werden kann. Ich benutze zwar die Konsole eher weniger, aber es gibt noch genug Läute die es benutzen und warum sollte man denen einen EOL90 oder gar ELO100 zumuten.
lg
Zum Post vom Fr Nov 10, 2006 17:39 :
Danke für das Beispiel. Ich werde dann auch überall eine -1 übergeben.
Jepp, jetzt halte ich mich auch dran. Vorher hatte ich ca. EOL90 und jetzt EOL79. Wen etwas länger ist als 79 dann breche ich einfach um. Bei Parametern die ich per Keywords übergebe, wird das jeder Parameter ehe von mir umgebrochen, weil es schöner aussieht.oliver1974 hat geschrieben:Mein erster Post hier im Forum und dann gleich mal hier voll einsteigen...
An die Regel von wegen 80 Zeichen Länge.. Haltet Ihr euch wirklich dran?
Das ist SEHR kurz, wie ich finde.....
Ich finde EOL79 sehr sogar sinnvoll, da in einer Konsole max. 79 angezeigt werden kann. Ich benutze zwar die Konsole eher weniger, aber es gibt noch genug Läute die es benutzen und warum sollte man denen einen EOL90 oder gar ELO100 zumuten.
lg
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Von was für Konsolen redet ihr hier eigentlich alle? Die, die ich kenne, haben alle variable Größe oder sind ziemlich viel breiter als 80 Zeichen.
Naja, ich meine z.B. die Eingabeaufforderung (DOS-Box) von Windows oder die Shell unter Linux Bei Linux bin ich mir nicht sicher (habe ich nicht), aber bei Windows hat die Eingabeaufforderung einen EOL von 80. Und ich glaube das einige Konsolen Editoren, auch nen EOL von 80 haben. Oder wenn man sich z.B. dann mit pydoc die Doku in der Konsole anschaut und die Zeilen über EOL80 sind, werden die umgebrochen was nicht schön aussieht.birkenfeld hat geschrieben:Von was für Konsolen redet ihr hier eigentlich alle? Die, die ich kenne, haben alle variable Größe oder sind ziemlich viel breiter als 80 Zeichen.
Auch das was gerold angesprochen hat kann ich zustimmen: Z.B. Unter Eclipse, hat man rechts eine Anzeige die alle Variablen, Klassen und Funktionen anzeigt. Wenn man im Editor dann ca. über EOL 80-90 hinaus ist, muss man vertikal scrollen was ein wenig nervt.
lg
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Also wer unter Windows die Eingabeaufforderung zum Editieren oder Code anzeigen verwendet, den musst du mir erst noch zeigen. Und zumindest bei mir bricht pydoc nicht bei 80 Zeichen um, wenn das Terminal breit genug ist.
Die Sache mit den Editoren ist allerdings schon eher einzusehen.
Die Sache mit den Editoren ist allerdings schon eher einzusehen.
Ich habe die schon ein paar mal für `svn` benutzt und mir dabei auch Diffs angeschaut. Auf dem Rechner war leider kein `xterm` und keine `bash` und das `svn` habe ich auch auf einem USB-Stick selbst mitgebracht.birkenfeld hat geschrieben:Also wer unter Windows die Eingabeaufforderung zum Editieren oder Code anzeigen verwendet, den musst du mir erst noch zeigen.
Oh, hat's noch keiner erwähnt? Ausdrucke! Über die exakte Breitengrenze, die ja irgendwo auch vom Editor samt Font-Einstellungen abhängt, kann ich nichts genaues sagen, aber IIRC war das meistens so ausgelegt, dass Code mit einem Monotype-Font in "humaner" Größe (vllt. 10 oder 12 Punkt, wer weiß) mit 80 Zeichen Breite gerade so draufpasste. Mag vielleicht auch von damals(tm) herrühren, als Ausgaben nicht nur auf Bildschirmen sondern auch (teilweise ausschließlich) auf Druckern landeten.
Stimme euch zu, 80 ist eine gute Grenze, wenn man mal Sachen nebeneinander betrachtet wird es sonst auch auf großen Monitoren eng, von Editoren ganz zu schweigen. Wobei ich sagen muss das ich noch recht frisch bekehrt bin, als ich PEP8 vor zwei Monaten oder so das erste Mal gelesen habe dachte ich auch "Was soll das denn?".
Kann man unter (aktuellem) Windows einstellen, manchmal ganz praktisch (bei Logfiles mit langen Zeilen und ähnlichem).
Bei mir ist die Eingabeaufforderung 130 Zeichen breitXtraNine hat geschrieben:birkenfeld hat geschrieben:Bei Linux bin ich mir nicht sicher (habe ich nicht), aber bei Windows hat die Eingabeaufforderung einen EOL von 80.
Kann man unter (aktuellem) Windows einstellen, manchmal ganz praktisch (bei Logfiles mit langen Zeilen und ähnlichem).