Seite 1 von 1

ThumbMaker - HTML/PHP Bildergallerie

Verfasst: Samstag 25. November 2006, 17:03
von SigMA
Tach :)

Ich habe mir ein kleines Skript geschrieben, dass eine Bildergallerie erstellt, wo die einzelnen Seiten über PHP mit ?tid angesprochen werden können. Ich habe bisher keine gesehen, die eine solche Funktion hat, sondern bei den meisten lagen einfach unmengen von HTML Dateien in einem Ordner. Bei mir ist alles in eine "index.php" Datei reingefasst.

Noch habe ich keinen HTML Header reingebaut, da ich es erstmal für meine Bedürfnisse nicht brauche, weil ich es eh in ein Design includiere und mir deswegen nicht die mühe machen wollte. (wer das haben will kann es ja einfach am Ende und Anfang in den Code einfügen)

Es stellt sich sicherlich die Frage, warum man eine so halbstatische Gallerie will. Entweder statisch HTML oder dynamisch mit PHP. Das mag wohl richtig sein, aber leider gibt es Anbieter (vor allem FreeHoster), die keine dynamischen Bildergallerien erlauben, da diese ihnen zu viel Serverleistung beansprucht. Daher habe ich dieses Skript geschrieben. Schön kompakt eine PHP Datei und Seiten wechsel via URL

Link: http://paste.pocoo.org/show/207/

Was haltet ihr davon?
SigMA

Verfasst: Samstag 25. November 2006, 18:10
von sape
Also bis zu 'self.pic_save' sah der Code echt gut aus :) PEP 8 lower_case, etc. (Einzige was nicht stimmt ist das der klassen Name mit einen kleinen Buchstaben anfängt.)

Ab ''self.pic_save' EOL über 80 :? Besonder Zeile 129 und 147 sind echt extrem (EOL 150?).

Die Kommentare hinter Zeile 95 und 99 würde ich auch wegmachen. Lieber über Zeile 95 und 99 schrieben. Gleiches gilt für Zeile 43-51.

lg

Verfasst: Samstag 25. November 2006, 18:39
von Leonidas
Igitt, Inline-Kommentare! Fangen schon in Zeile 26 an und werden dann exzessiv im Rest der Datei benutzt (besonders in maker.__init__()).

Würde ich auf jeden Fall ändern.

Shebang würde ich auch ändern:

Code: Alles auswählen

#!/usr/bin/env python
(keine Leerzeichen zwischen #! und dem Pfad zu env)

Verfasst: Samstag 25. November 2006, 19:06
von sape
Auch wenn ich jetzt auf Kritik stoße :P -> Ich würde alle Atribute, die wirklich nicht öffentlich verwendet werden sollen (oder keinen Sinn ergeben das man sie öffentlich aufruft) und halt nur intern in der klasse, mit einen unterstrich beginnen lassen. Alles mit einen unterstrich markiert das es Privat ist und das man die Sachen nicht anfasen soll.

Bevor jetzt kommt, wir sind doch alle erwachsen und so weiter: Es dient auch der Übersicht. So kann man leichter unterscheiden welche Sachen sinnvoll sind außerhalb der Klasse zu benutzen und welche nicht :) Das Hilft mir immer die Übersicht zu behalten (nicht nur bei meinen Klassen sondern auch bei fremden. Ein blick darauf und ich weiß was ich benutzen kann/soll und was nicht).

Aber das ist sicherlich auch Geschmacksache.

lg

Verfasst: Samstag 25. November 2006, 19:17
von Leonidas
XtraNine hat geschrieben:Auch wenn ich jetzt auf Kritik stoße :P
Aber sicher :D
XtraNine hat geschrieben:Es dient auch der Übersicht.
Es stört beim Schreiben (zumindest tippe ich Unterstriche nur ungerne), stört beim Lesen und außerdem macht das kaum einer, und somit schreibt man Code, bei der sich die meisten Leute erstmal fragen: "Warum ist da ein Unterstrich?"

Aber machs wie du willst - XtraNine wird weiter Unterstriche schreiben, und der Rest wird weiter ohne auskommen ;)

Verfasst: Samstag 25. November 2006, 19:35
von BlackJack
Den Docstring vom Modul "per Hand" an `__doc__` zu binden ist ungewöhnlich. Das habe ich bisher nur zweimal so gesehen.

Die Zielordner werden in der `__init__()` erstellt, ohne das man die Chance hätte die Namen zu ändern.

Die Vergleiche eines Wahrheitswertes mit den literalen `True` und `False` sind überflüssig und werden von vielen deshalb als schlechter Stil angesehen.

Den Namen `i` in einer Schleife an etwas anderes als Integer-Objekte zu binden ist sehr verwirrend.

``s.split("/").pop()`` splitted eine Zeichenkette in viele Teile und entfernt aus der resultierenden Liste das letzte Element. Das heisst die Zeichenkette wird komplett durchlaufen und die Liste wird durch das `pop()` verändert, obwohl sie gar nicht mehr in der veränderten Form benötigt wird. Effizienter wäre ``s.rsplit('/', 1)[1]``. Das durchläuft die Zeichenkette nur bis zum ersten '/' von hinten und verändert die Ergebnisliste nicht unnötig.

``(size[0], size[1])`` ist eine umständliche Art ``size`` zu schreiben. Und ist der Test ob einer der Werte 0 ist, wirklich nötig?

Die PHP/Python-Mischung ist sehr unübersichtlich, und `i` jetzt in einer ``while i:``-Schleife als Abbruchbedingung zu nutzen... Argh!

Und der Docstring bei `make_me_all()` drückt sehr schön aus, das es sich eigentlich um Funktionen handelt. Das das alles in einer Klasse steht, hat eigentlich keinen tieferen Sinn, das hätte man auch prima mit ein paar Funktionen lösen können.

Verfasst: Samstag 25. November 2006, 20:23
von sape
Leonidas hat geschrieben:[...]
Aber machs wie du willst - XtraNine wird weiter Unterstriche schreiben, und der Rest wird weiter ohne auskommen ;)
Ach was, jetzt übertreibst du ;) ca. 90% der Module machen das auch in ihren Klassen. Sogar in den Standardmodulen die von Python mitgeliefert werden. Ich glaube bei Pocoo habe ich auch schon Unterstriche gesehen ^^

Verfasst: Samstag 25. November 2006, 21:32
von SigMA
BlackJack hat geschrieben:Die Zielordner werden in der `__init__()` erstellt, ohne das man die Chance hätte die Namen zu ändern.
ähm ... der erste Teil ist doch config Teil. Da kann man auch den Pfad ändern. Ich wollte nur nicht, alles __init__() zuübergeben,
BlackJack hat geschrieben: Den Namen `i` in einer Schleife an etwas anderes als Integer-Objekte zu binden ist sehr verwirrend.
Bei mir ist 'i' eine Standart Schleifen Variabel. Zeugt vllt. von schlechtem Stil, aber das ist quasi ein Reflex
BlackJack hat geschrieben:``(size[0], size[1])`` ist eine umständliche Art ``size`` zu schreiben. Und ist der Test ob einer der Werte 0 ist, wirklich nötig?
:oops: ja .. öhm *hust* Das war absicht ;D Und ja die Abfrage nach dem Wert != 0 ist wichtig, da wenn Wert == 0 ist er das Bild nicht verkleinern/vergrößern soll.
BlackJack hat geschrieben:Die PHP/Python-Mischung ist sehr unübersichtlich, und `i` jetzt in einer ``while i:``-Schleife als Abbruchbedingung zu nutzen... Argh!
Wie gesagt die PHP/Python Mischung, weil es eine PHP Datei wird und Python die erstellt. FreeHoster unterstützen Python eben nicht^^

SigMA

Verfasst: Samstag 25. November 2006, 21:46
von BlackJack
SigMA hat geschrieben:
BlackJack hat geschrieben:Die PHP/Python-Mischung ist sehr unübersichtlich, und `i` jetzt in einer ``while i:``-Schleife als Abbruchbedingung zu nutzen... Argh!
Wie gesagt die PHP/Python Mischung, weil es eine PHP Datei wird und Python die erstellt. FreeHoster unterstützen Python eben nicht
Das war kein Argument gegen PHP, sondern dass diese Funktion so wie sie da steht, furchtbar unübersichtlich ist. Das kann man besser trennen. Die PHP-Zeichenketten könnte man zum Beispiel mit Platzhaltern versehen, am Anfang der Funktion an Namen binden und dann mit `string.Template()` die Werte eintragen. Ein Mini-Template sozusagen.

Verfasst: Samstag 25. November 2006, 22:04
von rolgal_reloaded
Hallo,

Python zu verwenden um PHP Spaghetticode zu erzeugen :evil: :?:

0 Punkte.

W A R E I N S C H E R Z :!:

Muss man in diesem Forum doch immer besser dazuschreiben :D

Im Ernst:
Nimm dir Blackjacks Tipps zu Herzen.

Da Python eine Sprache ist, die explizit effiziente prozuderale-, funktionale- usw. sowie oop ermöglicht, sollte man nur dann Klassen definieren, wenn sie tatsächlich einen Mehrwert darstellen.
OOP in Python - no other way to do it ? - then do it.

Grundsätzlich würde ich im Konstruktor keine fixen Werte definieren, wenn möglich. Lieber Defaultwerte, die beim Aufruf aber auch geändert werden können.
Wenn das nicht zur Diskussion steht, würde ich mir überlegen diese als Klassenvariablen zu definieren.
Also:

Code: Alles auswählen

class maker:

        width = 5                     # Anzahl der Bilder in der Breite
        height = 5                    # Anzahl der Bilder in der Höhe
        thumb_size = (150, 150)       # Die Breite der VorschauBilder
        pic_size = (800, 600) 

        def __init__(self):
             """ irgendwas anderes passiert hier"""

Das mit dem Namen i habe ich mir auch abgewöhnt. Es ist auch für einen selber viel angenehmer, wenn man den Code leist.

@Leonidas
Das mit den Inlinekommentaren ist eine Frage wie man es lieber mag.
Es ist auch aus mediendidaktischer Sicht durchaus sinnvoll diese zu machen, weil es für einen Lesenden, Lernenden das Verständnis erleichtern kann - natürlich nicht muss.

Liebe Grüße

rolgal_reloaded

Verfasst: Samstag 25. November 2006, 22:04
von SigMA
Das war kein Argument gegen PHP, sondern dass diese Funktion so wie sie da steht, furchtbar unübersichtlich ist. Das kann man besser trennen. Die PHP-Zeichenketten könnte man zum Beispiel mit Platzhaltern versehen, am Anfang der Funktion an Namen binden und dann mit `string.Template()` die Werte eintragen. Ein Mini-Template sozusagen.
Das ist ne gute Idee. Ich bau das morgen mal ein :)

SigMA

Verfasst: Samstag 25. November 2006, 22:26
von Leonidas
rolgal_reloaded hat geschrieben:Das mit den Inlinekommentaren ist eine Frage wie man es lieber mag.
Es ist auch aus mediendidaktischer Sicht durchaus sinnvoll diese zu machen, weil es für einen Lesenden, Lernenden das Verständnis erleichtern kann - natürlich nicht muss.
PEP8 hat geschrieben:Use inline comments sparingly.
Aber PEP8 mal ganz nebenbei. Inline Comments finde ich aus mehreren Gründen schlecht:
  • mischen von Code und Kommentar in einer Zeile finde ich unübersichtlich
  • kann sehr lang werden und daher die Zeilenlänge unnötig verlängern
  • man weiß nicht wo er anfangen muss (d.h. wie weit das # reingerückt sein muss) damit es konsistent ist. Bei kommentaren die über dem Code stellen ist es ja ersichtlich: genauso weit eingerückt wie der Code den sie beschrieben. Ich mag konsistenz.
  • Kommentare, zumindest bei mir, auch mehrzeilig werden können und daher als Inline-Kommentare entweder sehr lang werden würden, oder umgebrochen werden müssten und dazu dann noch aufwendig formatiert.

Verfasst: Samstag 25. November 2006, 22:31
von rolgal_reloaded
@Leonidas

ich mag nicht wenn PEP8 zu einer Art Bibel wird.

Ich wollte eigentlich was anderes sagen. Es ist Fakt, dass jeder Präferenzen bez. des Layouts von Informationen hat.
Person A: bevorzugt Bild links, Text rechts.
Person B: bevorzugt genau das Gegenteil.

Das Beispiel ist plakativ, aber so verhaltet es sich mit vielen Dingen.

LG

rolgal_reloaded

Verfasst: Samstag 25. November 2006, 22:42
von Leonidas
rolgal_reloaded hat geschrieben:ich mag nicht wenn PEP8 zu einer Art Bibel wird.
Ich habe es hier nur der Vollständigkeit halber erwähnt und dann noch vier eigene Gründe hinzugefügt, warum ich Inlinekommentare nicht mag. Mehr als die offizielle Position und meine eigene zu erklären kann ich nicht. Allerdings finde ich, dass meine Gründe durchaus gut sind und auch nachvollziehbar, da ist keine Dogmatik dabei, das sind einfach meine eigenen Alltagserfahrungen die ich nach mehreren Jahren programmieren mit Python hir einbringe.

Verfasst: Samstag 25. November 2006, 22:45
von rolgal_reloaded
Leonidas hat geschrieben: Ich habe es hier nur der vollständigkeit halber erwähnt und dann noch vier eigene Gründe hinzugefügt, warum ich Inlinekommentare nicht mag. Mehr als die offizielle Position und meine eigene zu erklären kann ich nicht.
Habe ich auch nicht verlangt, oder? Deine vier Gründe haben ja eh bestätigt was ich gemeint habe.

Liebe Grüße

rolgal_reloaded

Verfasst: Samstag 25. November 2006, 23:22
von sape
@rolgal: Letztendlich entscheidend der eigene Geschmack, es sei den man Arbeitet mit mehreren an einem Projekt. Da hat die persönliche Note nichts zu suchen. Dort muss man sich einigen damit man einen einheitlichen Code schriebt und nicht einen Code gemischt aus verschiedenen persönlichen Styles. MMn ist da PEP 8 ne gut Richtlinie.

Ich denke Leonidas wollte aber nur mal generell darauf hinweisen, dass es nicht PEP 8 Konform ist. Ich persönlich finde es nicht schlecht. Hätte mich damals einige nicht darauf hingewiesen, würde ich immer noch mixedCase und sonstigen "Unsinn" verwenden, wie 'MyClassException' statt 'MyClassError' oder '(x+1) *' (y-1) statt '(x + 1) * (y - 1)' oder 'type()' statt 'isinstance()' und vieles mehr.

Aber gut, das mit inline Comments ist nun nicht so schlimm wie andere Sachen die im PEP 8 stehen.

Es gibt aber für mich immer noch einige Sachen die mich auch an PEP 8 selber stören.

z.B. Bei reservierten Worten: statt 'lst' soll man dann lieber im Zweifelsfall 'list_' schreiben (das ist der einzige Fall wo ich keine Unterstriche mag. Wenn Unterstriche dann am Anfang und nur um es als private zu kennzeichnen *gg)