Schriftbreite im Eingabefeld ermitteln

[suk]

@suk: PEP8 findet man hier. Das hätte übrigens auch eine kurze Google-Suche ergeben. Und die nummerierten Code-Tags verbergen sich hinter dem Dropdown-Menü „Code auswählen“.

Habe mir mal gestern PEP8 durchgelesen.
Da freut man sich, wenn man Fortschritte in der Syntax macht ... und dann ist noch soviel Design zu beachten. Macht ja alles sicher Sinn, ist jedoch sehr umfangreich.

Mit der Zeilenbegrenzung wird man m.E. irgendwann an Grenzen stoßen ...
Wie müsste ich denn folgenden Code umbrechen, um nach PEP8 die Zeilenlänge von 72? Zeichen noch einhalten zu können?

Code: Alles auswählen

        if var_font.measure(self.mydata.player_name[self.mydata.playerqueue[position]]) >= var_label_width_max:
            var_font_size = int(var_font_size * (var_label_width_max / var_font.measure(self.mydata.player_name[self.mydata.playerqueue[position]])))

Das Klammerargument und das Ergebnis von `len` in einen `int` umzuwandeln, hat ein wenig was von Cargo-Kult-Programmierung. `len` gibt immer einen `int` zurück. Wie sollte eine Sequenz auch 42,5 Werte enthalten? Oder `"foo"` viele Werte‽

.. Cargo-Kult nehme ich mal als Kompliment
Hast aber Recht, mit meinen bisher zwei Monaten Python habe ich mir noch viel zu erarbeiten. Aber dazu hoffe ich ja im Forum Anregungen und Hinweise zu bekommen.

[Sirius3]

@suk: die 72 Zeichen ist einer der wenigen Punkte, die nicht so streng gesehen werden. Bei Deinem Code sollte man ein paar Variablen einführen:

Code: Alles auswählen

player_name = self.mydata.player_name[self.mydata.playerqueue[position]]
width = var_font.measure(player_name)
if  width >= var_label_width_max:
    var_font_size = int(var_font_size * (var_label_width_max / width))

[narpfel]

@suk: Die 72 Zeichen beziehen sich auf Fließtext, also Docstrings und längere Kommentare. Da ist es im Prinzip egal, wo man umbricht, also sollte man die Zeilenlänge so beschränken, dass es gut lesbar bleibt.

Bei der Zeilenlänge für Code halte ich es auch eher mit Raymond Hettinger: Es ist besser, die 79 Zeichen ein wenig zu überschreiten, als dafür Lesbarkeit zu opfern, indem man Zeilen an schlechten Stellen umbricht oder Variablennamen verkürzt. Über die alternativ erlaubten 99 Zeichen würde ich aber nicht herausgehen.

Deinen Code könnte man verbessern, indem man Werte, die mehrfach berechnet werden, an Namen bindet:

Code: Alles auswählen

        player_name = self.mydata.player_name[self.mydata.playerqueue[position]]
        player_name_width = var_font.measure(player_name)
        if player_name_width >= var_label_width_max:
            var_font_size = int(var_font_size * var_label_width_max / player_name_width)

Alternativ finde ich auch so etwas in Ordnung:

Code: Alles auswählen

        player_name_width = var_font.measure(
            self.mydata.player_name[self.mydata.playerqueue[position]]
        )
        if player_name_width >= var_label_width_max:
            var_font_size = int(var_font_size * var_label_width_max / player_name_width)

Sonstige Anmerkungen: Ein `my`-Präfix vor Namen ist überflüssig, weil es keinerlei Aussagekraft hat. `data` ist auch ein sehr generischer Name, für den man eventuell etwas besseres finden könnte. Das `var_`-Präfix sieht auch komisch aus. Wozu ist das gut?

Eventuell macht es auch Sinn, eine `Player`-Klasse (oder ein `namedtuple`) zu schreiben, weil du in `mydata.playerqueue` anscheinend Indizes in andere Listen speicherst. Es ist sinnvoller, zusammengehörige Daten auch zusammen zu speichern. `playerqueue` ist als Name für eine Liste (?) auch suboptimal, weil es den Datentypen `Queue` gibt.