PEP8, Indentation und Zeilenlänge

[frixhax]

Hi Leute!

Ich hab mal eine Frage bzgl. eurer Arbeitsweise: Wenn man nach PEP8 codet, ist die Zeilenlänge ja auf 79 begrenzt.
Ich benutze 4er Indentations, und wenn ich da was einigermaßen Verschachteltes habe, def -> for -> if -> for oder so, dann klauen mir ja alleine die Einrückungen schon einen Großteil der Zeile. Es kann doch nicht der Sinn der Sache sein, dass man dann zig Zeilen hat, die jeweils nur noch ein paar Zeichen enthalten. Wie macht ihr das?

Viele Grüße

[BlackJack]

@mohack: Nicht so tief verschachteln. Anfangen die inneren Ebenen in eigene Funktionen heraus zu ziehen.

[cofi]

Die Zeichenlaenge ist ein wunderbarer Sanity-Check: Tief verschachtelte Konstrukte sind meist schwer zu lesen und zu verstehen. Soll heissen: Wenn du lange Zeilen hast, ist meist nicht PEP 8 dein Problem, sondern der Code an sich.

...
Flat is better than nested.
...
Special cases aren't special enough to break the rules.
Although practicality beats purity.
...

[/me]

Zusätzlich zu dem anderen bereits Gesagten sollte man auch noch passend umbrechen, so dass nicht alles am Ende der Zeile steht.

Code: Alles auswählen

call_function(
    this_is_a_very_long_and_braindamaged_variable_name,
    now_it_gets_shorter,
    None
    )

[BlackJack]

Oft kann man auch Ebenen sparen wenn man mit Iteratoren, Generatorausdrücken, und den entsprechenden Bibliotheksfunktionen arbeitet. Ein Beispiel für ``for``/``if``/``for``:

Code: Alles auswählen

    def method(self, things):
        result = list()
        for thing in things:
            if predicate(thing):
                for piece in thing:
                    result.append(self.do_something(piece))
        return result
    
    # =>
    
    def method(self, things):
        result = list()
        for thing in ifilter(predicate, things):
            result.extend(imap(self.do_something, thing))
        return result

Mit `ifilter()` und `imap()` aus dem `itertools`-Modul.

[ws]

Wenn man z.B. mit nosetests oder ähnlichen Test-Frameworks die Test-Coverage seines Codes misst und versucht, eine maximale Testabdeckung zu erreichen, erkennt man relativ schnell, warum tiefe Verschachtelungen ungünstig sind. Für jedes if/else muss zusätzlicher Testcode geschrieben werden, damit diese Zweige durchlaufen werden. Aber einer bestimmten Verschachtelungstiefe ist der Code mit vernünftigem Aufwand überhaupt nicht mehr testbar. Eine Verschachtelungstiefe von 3 würde ich normalerweise in einer Funktion nicht überschreiten wollen.

[cofi]

Eins vergass ich - darum auch das `Practicality beats Purity` Zitat: Wenn es Sinn macht die Regel nicht einzuhalten, dann tue es auch nicht. Aber denk davor zweimal darueber nach

[frixhax]

Danke euch allen, das hilft mir weiter