als Abschluss dieses Schuljahres haben wir uns in kleinen Gruppen daran versucht, Rundenanzahl und Zeit einer Slotcarbahn zu messen, sowohl mit eigener Software als auch selbst zusammengebauter Hardware. Die Software habe ich komplett übernommen, da es allerdings einerseits wegen Zeitmangel höchstwahrscheinlich nicht mehr von unserem Lehrer bewertet werden kann, andererseits wir in der Schule nicht Python, sondern C lernen und ich nicht weiß, wie gut er sich mit Python auskennt, würde ich mich darüber freuen, wenn ihr mich auf typische Anfänger- / "C-Umsteiger"fehler hinweisen würdet, ich habe wenig praktische Erfahrung mit Python und möchte mir von vornherein keinen schlechten Stil angewöhnen. Beispielsweise habe ich es anfangs immerwieder geschafft, Dinge wie:
Code: Alles auswählen
liste = ['a', 'b', 'c', 'd']
for i in range(0, len(liste)):
tu_was_mit(liste[i])
Einige Fragen habe ich im Quelltext in Form von Kommentaren festgehalten, einige davon poste ich noch hier mit hinzu, damit sie nicht in Vergessenheit geraten:
- Eine Methode verwendet mehrfach "self.builder". Ist es in Ordnung, zuvor "b = self.builder" zu schreiben, um die Zeilen zu kürzen und Zeilenumbrüche zu sparen (siehe PEP 8, maximal 79 Zeichen pro Zeile)? Verwirrt ein Kürzel eher, oder erhöht es die Leserlichkeit durch weniger Zeichen? (imho letzteres, weshalb ich es hier so gemacht habe) (siehe auch Zeile 73)
- Laut PEP 8 soll man zu jeder Methode, Klasse, Funktion und Modul entsprechende Docstrings verfassen. Gilt dies auch für "spezielle" Methoden wie __init__? Mir fällt da nicht sonderlich viel zu schreiben ein...
Sollte man sich daran strikt halten, oder geht es auch in Ordnung, gelegentlich knapp über 80 Zeichen zu verwenden, statt gleich eine neue Zeile zu verbrauchen (was ja auch nicht unbedingt leserlich sein muss)?PEP 8 hat geschrieben:Limit all lines to a maximum of 79 characters.
Es sind zwar kurze Beispiele angegeben, trotzdem bin ich mir oft unsicher, was nun eine "angebrachte Einrückung" ist. Wenn man das in PEP 8 gegebene BeispielPEP 8 hat geschrieben:The preferred way of wrapping long lines is by using [...]. Make sure to indent the continued line appropriately.nimmt und noch etwas verlängert:Code: Alles auswählen
if width == 0 and height == 0 and (color == 'red' or emphasis is None):sieht es auch irgendwann merkwürdig aus, wenn alles in die letzten paar Spalten gequetscht wird. (Ein besseres Beispiel fällt mir gerade nicht einCode: Alles auswählen
if width == 0 and height == 0 and (color == 'red' or emphasis is None or (foobar26 is None and foopy30 is None and (color == 'red' or color == 'blue')):
)- Leerzeilen und deren Einrückung - im Folgenden zwei Beispiele, die Leerzeichen habe ich zur Verdeutlichung durch Punkte ersetzt:
Code: Alles auswählen
class foo(): .... .... ....def tuwas(): ........pass .... ....def machwas(): ........pass ....Gibt es für solch "unsichtbaren Einrückungen" Konventionen?Code: Alles auswählen
class foo(): ....def tuwas(): ........pass ....def machwas(): ........pass - Und weil's so schön ist, noch ein Codeschnipsel:
Das Ganze ist mir zu redundant, da beide Dictionarys dasselbe enthalten. Wie würde man das am elegantesten umsetzen?
Code: Alles auswählen
self.players = ({'name': 'Gast', 'current_round': 0, 'round_time': [0], 'best_round': 0, 'current_time': 0,}, {'name': 'Gast', 'current_round': 0, 'round_time': [0], 'best_round': 0, 'current_time': 0,},)
Bei der GTK Oberfläche war mir Glade behilflich, ich hoffe das war kein Fehler (ja, habe auch zuvor schon das ein oder andere manuell mit GTK erstellt) - hier die dazugehörige XML Datei: http://paste.pocoo.org/show/229128/
So, dann reißt mich und den Code mal auseinander...
Eins wollte ich noch loswerden: Python, GTK, PyGTK [...] unter Windows installieren ist doch ein Krampf, da lobe ich mir die Super Kuh Kräfte
