• Immer eine Empfehlung wert? Das PHPMagazin.

    von am 4. August 2008

    In einem seiner letzten Blog Beiträge empfiehlt das PHPMagazin 10 Codesnippets, die man immer mal gebrauchen kann. Dieser Tipp ging meiner Meinung nach leider nach hinten los, was eine handvoll weiterer Leser durch ihre Kommentare bestätigten.

    Ich will den Blog ja nicht rügen der diese Tipps veröffentlicht, sie haben sicherlich ihre Daseinsberechtigungen, aber warum das PHPMagazin sie unbedingt weiterempfehlen muss, ist und bleibt mir ein Rätsel. Codesnippets die einem zeigen, wie man eine Datenbankverbindung öffnent sind natürlich nicht uninteressant, aber wenn man mal ehrlich ist, wie oft verwendet man ein solchen Codeblock. Maximal einmal pro Projekt und dann auch über eine Datenbank Schicht, die einem das gröbste abnimmt. In professionellen Bereichen, sollte diese Snippet wohl nie zur Verwendung kommen.

    Der nächste Schnipsel handelt vom require Befehl. Programmiert man aber strikt objektorientiert, dann sollte auch dieser Befehl nie angewendet werden. require_once heißt hier die saubere Alternative. Als ein Grundsatz sollte immer gelten: pro Datei genau eine Klasse. Wenn man dies befolgt, wird klar, dass require nicht verwendet werden muss.

    Aber vielleicht sollte man nochmal schnell den Unterschied zwischen require und require_once erläutern. Der kleine ber feine Unterschied ist ledigleich, dass bei require_once die Datei genau einmal inkludiert wird, bei require jedoch jedes mal wenn der Befehl angewendet wird. Auch die anderen Tipps sind zwar nett, aber man wird auch ohne sie ein angenehmes Entwicklerdasein fristen können, da fast alle nur sehr selten verwendet werden sollten.

    Was man vielleicht abschließend noch erwähnen sollte ist, dass die Tipps, die präsentiert wurden nur so nach Sicherheitslücken schreien und man alleine aus diesem Grund einen solchen Blog Post nicht noch pushen sollte.

    Fazit: Es ist nicht immer Gold was glänzt und man sollte auch bei einem Blog wie dem des PHPMagazins nicht alles als beispielhaft erachten, was vorgestellt wird. Leider stärkt mich dieser Artikel in meiner Meinung über die PHP Community.

    Nils Langner

    Auch wenn Ihr es mir nicht glauben werdet, aber ich habe nichts gegen PHP. Ich rege mich einfach nur gerne auf. Ok so schlimm ist es auch nicht. Eigentlich wollte ich schon immer einen Blog haben und da ...

    Zum Profil von Nils Langner

    4 Kommentare »


    • Klaus
      am 30. August 2008 um 17:38 Uhr

      Hallo!

      Ein kleiner Unterschied besteht noch zwischen require und require_once:

      Letzteres ist langsamer, was schon Auswirkungen haben kann, wenn viele Files eingebunden werden.

      Gruss,
      Klaus


    • admin
      am 30. August 2008 um 20:04 Uhr

      Hallo Klaus, in welchem Fall würdest du denn require verwenden?


    • Klaus
      am 2. September 2008 um 13:17 Uhr

      Hallo!

      Wenn es mir a) auf Performance ankommt und ich b) einigermassen den Überblick über meine Includes behalten kann (also selbst darauf achten, dass ich nichts mehrfach einbinde), dann würde ich “require” nehmen.

      Ansonsten aus Bequemlichkeitsgründen “require_once” …

      Gruss,
      Klaus


    • admin
      am 2. September 2008 um 15:26 Uhr

      Ok, dann muss das Projekt aber wirklich sehr sehr klein sein.

    RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

    Hinterlasse einen Kommentar

    Werbung
    PHP Magazin
    Ausgabe 02/2010

    Dieses Mal mit Artikeln zu den Themen OpenSocial und Apache Shindig, Graphentheorie, Smarty3

    t3n
    Ausgabe 19

    Social Media (R)evolution. Weitere Themen sind noSQL, Crowdsourcing ...

    PHP Journal
    Ausgabe 2/2010

    PHP & Windows optimal nutzen, die besten PHP-CMS im Überblick, Google-API mit Zend Framework nutzen.

    Wir wurden schon öfters gefragt, ob man uns nicht irgendwie unterstützen kann. Die Antwort war immer einfach: Klar! Am einfachsten ist es eure nächsten Einkäufe bei Amazon über unsere Link abzuwickeln. Damit würdet ihr uns schon sehr helfen. Über Co-Autoren freuen wir uns aber noch mehr.