BlackJack hat geschrieben:@snakeseven: Das ist ziemlich, äh Barock. Gross, umständlich, schlecht entworfen, teilweise ziemlich unsinnig.
Nur mal so schnell durchgeschaut:
Aus der `__init__()` wird nicht ersichtlich welche Attribute die Klasse im Laufe ihres Lebens haben wird.
Weil in einigen Methoden der Klasse weitere Attribute hinzugefügt werden?
Ich weiss, sollte man lassen. Wirklich schlimm finde ich es zwar nicht, sollte mich aber bemühen, es in Zukunft anders zu machen.
`loadpagesources()`: Warum wird `src` übergeben aber nicht verwendet? Was ist bitte `bol`? Wozu soll `online` gut sein? Warum gibt die Funktion (denn eine Methode scheint das vom Inhalt her nicht zu sein) einen "Fehlercode" zurück? Dafür wurden Ausnahmen erfunden.
'src' wird an 'source1', bzw. 'source2' übergeben, 'bol' ist ein boolscher Wert, der zeigt, ob der Sourcecode der Seite geladen werden konnte, oder nicht. Mit try/except wäre es natürlich auch gegangen. So aber kann ich mir detailiert anzeigen lassen, was da schief gelaufen ist.
Genauso in `single_line_parser()`, wobei der Boolean-Wert da auch noch redundant ist, denn anscheinend ist das dritte Element immer genau dann `False` wenn das erste die leere Zeichenkette ist, und `True` wenn im ersten Element keine leere Zeichenkette steht. Aber auch hier wäre eine Ausnahme angebrachter.
Ja, klar, mit try/except kann man ganz schlank und übersichtlichen Code erstellen. Aber mir ist auch hier wichtig, jeden Schritt des Miniparsers überprüfen und ausgeben zu können. Hier arbeite ich nur mit einer Suchmaschine. Wenn es aber 10 sind, oder mehr, dann gibt es immer wieder Situationen, wo unsauberer HTML-Code zu putzigen Ergebnissen führt. Das will ich mir dann einfach in einem der 'else'-Zeilen ausgeben lassen können.
Methodennamen sollten beschreiben was die Methode tut. Das kann ich bei `airmp3()` nicht erkennen. Ausserdem ist die Methode definitiv zu lang und zu komplex.
Ja, da gebe ich dir recht. Im 'Mutterprogramm' heißt das Ding auch 'parse_airmp3'. Zu lang ? Kann man für 'Gastleser' sicherlich übersichtlicher gestalten. Weiss aber nicht, ob ich persönlich das dann noch übersichtlich finde.
`checkifnumbers()` wird nirgends benutzt, aber falls es benutzt würde, was wäre der Vorteil gegenüber der `isdigit()`-Methode auf Zeichenketten? Selbst wenn man diese Methode nicht kennt *und* sonst eher in "low level"-Sprachen programmiert, ist die Funktion ziemlich gruselig. Das würde man selbst in C oder BASIC nicht so umständlich lösen.
Hat in diesem Programmauszug tatsächlich keine Bedeutung. War ein Notbehelf, weil ichs mit "Re" nicht hinbekommen hatte. Hat mal Nummern als solche erkannt und mal nicht. 'isdigit' kenn ich nicht, danke für den Tipp.
Diese ganze HTML-Parserei und das hin- und herkodieren ist ein schlechter Witz.
Das Hin- und Herkodieren ist ein Erbe aus dem eigentlichen (Haupt-)programm, welches unter wxPython läuft und mir nur so garantiert, dass auch alles auf der GUI dargestellt werden kann. Was den Witz angeht, so muss es an meiner Art von Humor liegen
``try``/``except`` ohne konkrete Ausnahme und dann auch noch mit ``pass`` ist Böse™.
Ich kann nur Ausnahmen definieren, die mir bekannt sind. Das sind sie mir aber oft nicht. Falsche Codierung? Timeout? Defekter HTML-Header? usw.
Da geht dann manchmal nur das allgemeine try/except.
Gruss, Seven