Diskussion zu PEP8!

[Y0Gi]

Zum Thema Funktions- und Methodennamen:
Da diese *immer* ein Verb sein sollten (z.B. get..., reload..., parse...; auch wenn das in diversen uralten C-Libs nicht der Fall ist), ist es sowohl im Englischen als auch Deutschen nur konsequent und logisch, diese klein zu schreiben. Außerdem werden sie dadurch sehr gut von Klassennamen unterscheidbar, die man traditionell (soweit mir bekannt) groß schreibt (ok, zugegeben, Nomen schreibt man im Englischen klein, aber hey).

Ob man Erstgenannte allerdings mixedCase oder underscore_separated schreibt, ist noch am ehesten Geschmackssache. Ersteres habe ich so aus der Java-Welt übernommen, wo es eigentlich in der Regel ganz ordentlich und lesbar ist. Ausnahme sind dann Namen, die Abkürzungen oder Akronyme wie XML, HTTP oder dergleichen enthalten; sowohl getXMLData als auch getXmlData sind beide nicht ganz der Weisheit letzter Schluss. An dieser Stelle spielt die Underscore-Variante ihre Stärken aus, fordert dafür aber minimal mehr Zeichen für die zusätzlichen Unterstriche ein.
Da man in beiden Fällen fast gleich oft die Shift-Taste bemühen muss, ist der Unterschied vom Aufwand beim Tippen vernachlässigbar klein.


gerold: Auch du könntest den Apostroph bitte vorbildlich verwenden. Bei "ID´s" anstelle des korrekten "IDs" apostrohpierst du nicht nur fälschlicherweise, sondern verwendest auch noch einen französichen Akzent (´) anstelle des Apostroph-Zeichens ('). Nix für ungut

[BlackJack]

- ID´s werden nicht mehr gebraucht, da man mit ``Bind()``, Events auch an Objekte und nicht nur an ID´s binden kann.

Warum ist das der letzte Punkt Deiner Aufzählung? Diese IDs waren damals der Grund warum ich schreiend weggelaufen bin als ich wxWindows ausprobiert hatte. Zu jedem Objekt eine ID erzeugen und die stellvertretend in der Gegend herum zu reichen ist mir sowas von unpythonisch, aufwändig und überflüssig erschienen...

[gerold]

der Grund warum ich schreiend weggelaufen bin

-- das kann ich mir ziemlich gut vorstellen.

lg
Gerold

[sape]

Hi gerold:
Zum post vom Do Nov 09, 2006 23:03: Interessanter Ansatz und mMn auch sehr gut So weit hatte ich nicht gedacht. Das werde ich mit übernehmen. Danke

...

Warum keine IDs? Sollte ich die auch vermeiden und stattdessen lieber ein -1 setzen?

Ich mache immer nen Konstante zb. WXID_IRGENDWAS und mache dann ein wx.NewId(), das mir selber eine ID erzeugt -> WXID_IRGENDWAS = wx.NewId().

Danach übergebe ich das dann. Also doch lieber ein -1 übergeben?

[gerold]

Ich mache immer nen Konstante zb. WXID_IRGENDWAS und mache dann ein wx.NewId(), das mir selber eine ID erzeugt -> WXID_IRGENDWAS = wx.NewId().

Hi XtraNine!

Hier ein Beispiel, ohne Ids:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-

import wx

wx.SetDefaultPyEncoding("iso-8859-1")


class MyFrame(wx.Frame):
    
    def __init__(self, parent = None, id = -1, title = "Hallo Welt (ohne IDs)"):
        
        wx.Frame.__init__(self, parent, id, title)
        
        # Panel
        panel = wx.Panel(self)
        
        # Hauptrahmen (fuer den Abstand)
        vbox_rahmen = wx.BoxSizer(wx.VERTICAL)
        panel.SetSizer(vbox_rahmen)
        
        # vbox (innherhalb des Hauptrahmens mit 5px Abstand)
        vbox = wx.BoxSizer(wx.VERTICAL)
        vbox_rahmen.Add(vbox, proportion = 1, flag = wx.ALL | wx.EXPAND, border = 5)
        
        # Label
        label = wx.StaticText(
            panel, -1, u"Ich werde geändert, wenn der Button geklickt wird!",
        )
        self.label = label
        vbox.Add(label, proportion = 1, flag = wx.ALL, border = 5)
        
        # Button
        button = wx.Button(panel, -1, "Klick mich!")
        vbox.Add(button, proportion = 0, flag = wx.ALL | wx.EXPAND, border = 5)
        button.Bind(wx.EVT_BUTTON, self.aendere_labeltext_per_button) # Eventhandler binden
        
        # Menüleiste
        menubar = wx.MenuBar()
        
        # Hilfe-Menü
        menu_help = wx.Menu()
        menuitem = menu_help.Append(-1, "&Info")
        # Ausnahme! Menüs müssen über das Frame-Objekt an ein Event gebunden werden.
        self.Bind(wx.EVT_MENU, self.aendere_labeltext_per_menue, menuitem)
        menubar.Append(menu_help, "&Hilfe")
        
        # Menüleiste an Frame binden
        self.SetMenuBar(menubar)
        
        # Minimalgröße festlegen 
        panel.Fit()
        self.Fit()
        self.SetSizeHintsSz(self.GetSizeTuple())
        
        # Zentrieren
        self.Center()
    
    
    def aendere_labeltext_per_button(self, event = None):
        
        label = self.label
        label.SetLabel(u"Es wurde der Button geklickt!")

    
    def aendere_labeltext_per_menue(self, event = None):
        
        label = self.label
        label.SetLabel(u"Es wurde das Info-Menü ausgewählt!")


def main():
    
    app = wx.PySimpleApp()
    f = MyFrame()
    f.Show()
    app.MainLoop()


if __name__ == "__main__":
    main()

lg
Gerold

[oliver1974]

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

... einige Sachen wie TreeViews sind auch in PyGTK unnötig komplex.

Ja, das GTK-TreeView.... Ich hab mich auch vor kurzem am Kopf gekratzt
und gedacht: "...ich will doch nur einen stinknormalen Tree.... Und
ein paar Spalten!!"

Hammer auch, das die "Tabelle" ein Sonderfall vom Tree ist
(hab ich doch jetzt richtig in Erinnerung, oder?), da muss man
erstmal drauf kommen.... Da sucht man sich ja erst dumm und dämlich!

Überhaupt, Tutorials und GUI-Apis unter Pyhton scheinen so ein
Thema zu sein, auch das PyGTK-Tutorial ist nicht mehr so Up-To-Date,
an manchen Stellen fliegen einem ja beim Nachprogrammieren
nur so die "deprecation warnings" um die Ohren.

Irgendwie scheint mir da echt eine "Marktlücke" zu sein, oder... ?

[Y0Gi]

An die Regel von wegen 80 Zeichen Länge.. Haltet Ihr euch wirklich dran?

Ja, allerdings. Und ich finde, das klappt recht problemlos, insbesondere wenn man Klassen- und Methodennamen nicht mehr als 40 Zeichen spendiert, wie das in der Java-Welt ja nichts ungewöhnliches ist. Und irgendwann muss man sowieso umbrechen, das geht dann auch bei Spalte 80 (bzw. 79) nicht wirklich schlechter.


Ich weiß nicht, wieso das hier so GUI-Toolkit-lastig (sprich: OT) ist, aber wo wir schon dabei sind...

Überhaupt, Tutorials und GUI-Apis unter Pyhton scheinen so ein Thema zu sein, auch das PyGTK-Tutorial ist nicht mehr so Up-To-Date, an manchen Stellen fliegen einem ja beim Nachprogrammieren nur so die "deprecation warnings" um die Ohren.

Irgendwie scheint mir da echt eine "Marktlücke" zu sein, oder... ?

Beim Lernen von wx bin ich auch über viel, ja, unbrauchbaren oder wertlosen Code gestolpert. Das mag aber daran liegen, dass diese API (und das mag auf andere, außer vielleicht die von Tkinter, wohl auch zutreffen) umfangreich geändert wurde. IDs und diverse Initialisierungen wurden überflüssig usw. Für Neueinsteiger ist der jeweils aktuelle Zustand der API sicherlich eine bessere Ausgangsposition, aber das Vorhandensein von nun unbrauchbarem Code ist natürlich ein unangenehmer Trade-Off.

[oliver1974]

An die Regel von wegen 80 Zeichen Länge.. Haltet Ihr euch wirklich dran?

Ja, allerdings. Und ich finde, das klappt recht problemlos, insbesondere wenn man Klassen- und Methodennamen nicht mehr als 40 Zeichen spendiert, wie das in der Java-Welt ja nichts ungewöhnliches ist. Und irgendwann muss man sowieso umbrechen, das geht dann auch bei Spalte 80 (bzw. 79) nicht wirklich schlechter.

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.

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?

Heute fährt doch kaum einer Auflösungen, wo eine Zeile mit 90 - 100 Zeichen ein Problem darstellt, oder?
Abgesehen natürlich von den Leuten mit Sehproblemen, die lieber generell
große Fonts und eventuell eine insgesamt niedrigere Auflösung bevorzugen...

[birkenfeld]

"Stilbruch" ist eher schon zu dramatisch gesagt . 90 Zeichen ist IMO sehr vernünftig, gerade in Code, der etwas verschachtelter ist.

[gerold]

Heute fährt doch kaum einer Auflösungen, wo eine Zeile mit 90 - 100 Zeichen ein Problem darstellt, oder?

Hi oliver!

Du übersiehst da ein paar Dinge:

- Viele verwenden eine IDE und nicht nur einen reinen Editor zum Entwickeln. An den Seiten sind in den meisten IDEs Tool-Fenster eingeblendet, die beim Entwickeln helfen. Z.B. ein Fenster in dem die Klassen und Funktionen des gerade bearbeiteten Moduls angezeigt werden. Oder z.B. ein Code-Assistent, der ständig Informationen über die aktuellen Attribute aufzeigt... Da ist man froh, wenn die anderen ihren Code so um die Spalte 80 herum umgebrochen haben, damit man diesen komplett lesen kann.

- Wenn du Code ins Python-Forum einfügst, dann hast du in der Anzeige auch nicht die volle Breite zur Verfügung. Als Richtwert für den Zeilenumbruch die Spalte 80 zu verwenden ist auch hier nicht unbedingt eine schlechte Idee. Es stört niemanden, wenn mal eine Zeile ein wenig länger ist. Aber die Ausnahme sollte nicht zur Regel werden.

- Nicht jeder entwickelt immer in einem Fenster das die volle Breite des Screens ausnutzt. Viele haben mehrere Fenster offen, um während des Entwickelns den Code schnell mal testen zu können und/oder sofort die Auswirkungen des geänderten Codes anzeigen zu lassen. Auch hierfür ist man froh, wenn sich alle am Projekt beteiligten Entwickler an die 80 Zeichen halten.

Das sind mir fürs Erste genug Gründe um 80 Zeichen als Richtwert für den Zeilenumbruch zu verwenden.

mfg
Gerold

[oliver1974]

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

[N317V]

80 Zeichen ist die Standardbreite von Unix-Terminals.

[jens]

An die Regel von wegen 80 Zeichen Länge.. Haltet Ihr euch wirklich dran?

Ja... Auch wenn ich PyLucid noch einige längere Zeilen stecken, aber das sind meist alte Codezeilen
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

[gerold]

Scheint jetzt irgendwie Geschmackssache zu sein, mich hat das scrollen weniger gestört als das "zerreissen" der lines.

Hi oliver!

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

mfg
Gerold

[jens]

Ich würde es ähnlich machen, allerdings nicht bei der funktions definition und nicht beim if... Ich mache es dann ehr mit einem "\":

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

Wobei das auch nicht ganz so aufgeräumt aussieht... Aber ich finde das "):" alleine auf einer Zeile irgendwie komisch.

[BlackJack]

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.

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.

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?

Terminals/Konsolen sind in der Regel 80 Zeichen breit und manchmal muss man doch mal schnell den Quelltext dort lesen.

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]

Ich mache es dann ehr mit einem "":

Code: Alles auswählen

def meine_funktion(argument1, argument2, argument3, argument4, \
                                        argument5 = None, argument6 = None):

Das funktioniert natürlich auch wunderbar ohne "".

[Y0Gi]

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:

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

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

[N317V]

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

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]

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.