On 2017-08-25 10:28, Tobias Herp wrote:
a b und c enthalten strings. d=a+b+c besser als # Variante 1 d="{}{}{}".format(a,b,c) ? # Variante 2
Die zweite Variante ist das übliche Idiom, wenn es um die Kombination von Strings geht.
Wirklich? Himmel hilf!
Erst mal vorweg. Ich denke, dass es für dieses Problem (Strings zusammenfassen) nicht so kritisch ist, welche der drei Varianten (`format`, `+` oder `join`) man verwendet. Als ich schrieb, ich würde Variante 2 verwenden, meinte ich damit eine Präferenz, aber nicht, dass die anderen beiden Varianten "falsch" wären oder davon abzuraten wäre.
Das wäre wirklich die letzte Version, die mir einfallen würde - nicht nur, weil ich, der ich die Flexibilität der format-Methode praktisch nie benötige, diese selten verwende.
Ich und anscheinend auch andere verwenden `format` mittlerweile dort, wo sie früher Prozent-Formatierungen verwendet haben. Dann wird die Verwendung von `format` relativ häufig. (Mir ist klar, dass man über "`format` oder nicht?" ausgiebig diskutieren kann und ich gehe davon aus, dass das bei der Einführung von `format` auch passiert ist.)
PEP 20.2, "Explicit is better than implicit." PEP 20.3, "Simple is better than complex." [...]
In meine Präferenz spielen aus PEP 20 mit hinein: - Readability counts. Interessant finde ich, dass wir beide "Readability counts" anführen, aber unterschiedliche Dinge lesbar finden. - There should be one-- and preferably only one --obvious way to do it. _Den_ offensichtlichen Weg gibt es hier anscheinend nicht, aber die Verwendung von `format` ist aus meiner Sicht "the most obvious". Ich finde, wenn ich drei Strings mit "{}+{}-{}".format(a, b, c) zu einem neuen String kombiniere, sollte der Code nicht ganz anders aussehen, wenn keine Zeichen dazwischen stehen. Ich denke, hier spielt hinein, welches Idiom wir in dem Code jeweils sehen - einen String aus einem Template erzeugen (siehe auch die Mail von Ole) oder eine Reihe von Strings verketten. Dieses Idiom würde ich eher sehen, wenn die Strings schon in einer Liste vorliegen. Wenn es darum geht, möglichst fehlerarmen und lesbaren Code zu schreiben, ist mein Ansatz, möglichst geradlinigen, "langweiligen" Code zu schreiben. Ich verwende sehr selten explizite Typ-Prüfungen und normalerweise würde ich nicht Code extra so schreiben, dass er möglichst viele implizite Typ-Prüfungen durchführt. Wenn der Code leicht lesbar ist, ist es wahrscheinlicher, dass Fehler schon beim Schreiben auffallen beziehungsweise gar nicht erst gemacht werden. Die Typ-Fehler versuche ich eher, mit automatisierten Tests zu finden. Aber auch da verwende ich selten _explizite_ Typ-Prüfungen. Ein damit zusammenhängender Aspekt ist Kontext: Bei meiner Antwort bin ich (unbewusst) davon ausgegangen, dass in der Praxis die Namen nicht `a`, `b` und `c` heißen und dass zu erkennen ist, wo die Werte herkommen. Das reduziert die Wahrscheinlichkeit von falschen Typen schon mal ganz erheblich, so dass das bei der Wahl des konkreten Codes kaum noch eine Rolle spielt.
Ich kann sogar die Lesbar- und auch Änderbarkeit noch auf die Spitze treiben:
d = ''.join([a, # Erklärung des ganz woanders erzeugten Wertes a b, # dto. für b c, # dto. für c ])
Ich bin mir nicht so sicher, ob das den Code wirklich lesbarer macht. Ich würde eher versuchen, sprechende Bezeichner zu verwenden und die Funktion/Methode so kurz zu halten, dass auch ohne Kommentare erkennbar ist, um was für Werte es sich handelt. In extremen Fällen können zusätzliche Kommentare sinnvoll sein, aber ich finde nicht, dass der Code damit automatisch lesbarer wird (aber unter Umständen besser wartbar). Viele Grüße Stefan