Hugo Egon Balder: Werden php Kommentare mitverarbeitet/geparst?

Hi,

ich habe die Angewohnheit, so gut wie jede php-Aktion mit einem Kommentar zu versehen, weil ich festgestellt habe, dass da schon beim Programmieren viele Fehler vermieden werden, da einem durch das Hinschreiben dessen, was da passiert, viele Denkfehler bewußt werden.

Nun frage ich mich, wie das die Ladezeit einer Seite beeinflußt.

Wenn der php-Parser zu einer Zeile kommt, die mit // beginnt, arbeitet er die dann ab, was zu einer Vergrößerung der Ladezeit führen würde, oder springt er sofort zur nächsten Zeile, was die Ladezeit einer Seite mit Kommentaren zu der einer Seite ohne selbigen nicht verändern würde?

MfG

Hugo Egon Balder

  1. Glück auf!

    Wenn der php-Parser zu einer Zeile kommt, die mit // beginnt, arbeitet er die dann ab, was zu einer Vergrößerung der Ladezeit führen würde, oder springt er sofort zur nächsten Zeile, was die Ladezeit einer Seite mit Kommentaren zu der einer Seite ohne selbigen nicht verändern würde?

    Ersteres; ein schließendes PHP-Tag (?> bedeutet ja immer das Ende eines PHP-Bereiches (auch wenn es innerhalb eines Kommentares steht). Würde er direkt zur nächsten Zeile springen, würde er dies ja nicht finden.

    Ich würde bei der Kommentierung meiner Scripte immer die Übersichtlichkeit in den Vordergrund stellen und den Zeitfaktor (der vlt. messbar, aber kaum spürbar sein sollte) vernachlässigen.

    Freundliche Grüße

    zwerg Alex

    1. Hi zwerg Alex,

      Ersteres; ein schließendes PHP-Tag (?> bedeutet ja immer das Ende eines PHP-Bereiches (auch wenn es innerhalb eines Kommentares steht). Würde er direkt zur nächsten Zeile springen, würde er dies ja nicht finden.

      Ist logisch, ja. Habe ich auch gerade im Quakenet-Tutorial nachgelesen.

      Und bei mehrzeiligen Kommentaren muß der Parser ja logischerweise auch _alles_ abarbeiten, damit er weiß, wo und dass es nach dem kommentarabschließenden */ wieder "weitergeht".

      Ich würde bei der Kommentierung meiner Scripte immer die Übersichtlichkeit in den Vordergrund stellen und den Zeitfaktor (der vlt. messbar, aber kaum spürbar sein sollte) vernachlässigen.

      Dass es nicht spürbar ist, sehe ich auch so. Ich wollte es nur interessenshalber prinzipiell wissen. Hätte ich nur ein paar Minuten länger nachgedacht, wäre die Frage vielleicht von selbst beantwortet gewesen.

      Danke!

      MfG

      Hugo Egon Balder

  2. Hallo,

    ich habe die Angewohnheit, so gut wie jede php-Aktion mit einem Kommentar zu versehen

    das ist eine gute Angewohnheit - du hilfst damit sowohl dir selbst, wenn du Monate später mal wieder an das Script drangehst, als auch anderen, die vielleicht einmal müssen oder dürfen.

    weil ich festgestellt habe, dass da schon beim Programmieren viele Fehler vermieden werden, da einem durch das Hinschreiben dessen, was da passiert, viele Denkfehler bewußt werden.

    Vorausgesetzt, man schreibt den Kommentar so, dass er den *Zweck* der Anweisungen als Ganzes oder als Block beschreibt, und nicht jeden einzelnen Schritt ohne Zusammenhang.

    Wenn der php-Parser zu einer Zeile kommt, die mit // beginnt, arbeitet er die dann ab, was zu einer Vergrößerung der Ladezeit führen würde, oder springt er sofort zur nächsten Zeile, was die Ladezeit einer Seite mit Kommentaren zu der einer Seite ohne selbigen nicht verändern würde?

    Die Antwort kannst du dir eigentlich selbst geben, wenn du darüber nachdenkst, wie Textdateien (nichts anderes ist ein PHP-Script eigentlich) organisiert sind. Sie enthalten einen fortlaufenden Strom an Zeichen, und zwischendurch taucht immer mal wieder ein Zeilenumbruch auf, der aber auch nur ein "gewöhnliches" Zeichen ist (wenn auch mit Sonderbedeutung).
    Trifft der Parser nun auf einen Kommentar, der mit // eingeleitet wird, muss er den Quellcode weiter Zeichen für Zeichen durchgehen, bis er einen Zeilenumbruch findet. Ein "sofort zur nächsten Zeile springen" gibt es nicht, weil der Quelltext keine direkt "anspringbaren" Zeilenmarkierungen enthält. Schau dir mal eine Scriptdatei als Hexdump an, dann verstehst du, was ich meine.

    So long,
     Martin

    --
    Der Gast geht solange zum Tresen, bis er bricht.
    1. Hi Martin,

      Vorausgesetzt, man schreibt den Kommentar so, dass er den *Zweck* der Anweisungen als Ganzes oder als Block beschreibt, und nicht jeden einzelnen Schritt ohne Zusammenhang.

      wie meinst Du den letzten Teil Deines Statements?

      Die Antwort kannst du dir eigentlich selbst geben

      Du hast Recht. Ich habe in meiner Antwort an zwerg Alex gerade geschrieben, dass ich wohl etwas länger denken hätte sollen, um selbst auf die Antwort zu kommen.

      Danke für die gut formulierte Erklärung!

      MfG

      Hugo Egon Balder

      1. echo $begrüßung;

        ich habe die Angewohnheit, so gut wie jede php-Aktion mit einem Kommentar zu versehen, weil ich festgestellt habe, dass da schon beim Programmieren viele Fehler vermieden werden, da einem durch das Hinschreiben dessen, was da passiert, viele Denkfehler bewußt werden.

        Vielleicht nur ein Formulierungsfehler, aber hinzuschreiben was passiert, ist überflüssig. Das sieht man aus dem Code. Es ist sinnvoller, hinzuschreiben, was passieren _soll_, denn die Absicht des Autors kann man nur dann aus dem Code herauslesen, wenn der Autor hundertprozentig fehlerfrei gearbeitet hat. Für viele ist es jedoch einfacher, Fließtext zu verstehen als Programmcode.

        Vorausgesetzt, man schreibt den Kommentar so, dass er den *Zweck* der Anweisungen als Ganzes oder als Block beschreibt, und nicht jeden einzelnen Schritt ohne Zusammenhang.
        wie meinst Du den letzten Teil Deines Statements?

        Das große Ganze ergibt sich aus der Summe der Einzelteile. Nicht nur die kleinen Aufgaben sondern auch die Erläuterung des eigentlichen Zieles ist sinnvoll. Denn irgendwie müssen ja die Teile auch zusammenspielen, um das Ziel zu erreichen.

        echo "$verabschiedung $name";

        1. Hi dedlfix,

          Vielleicht nur ein Formulierungsfehler, aber hinzuschreiben was passiert, ist überflüssig. Das sieht man aus dem Code. Es ist sinnvoller, hinzuschreiben, was passieren _soll_

          ich verstehe den Unterschied nicht, den Du meinst.

          Das große Ganze ergibt sich aus der Summe der Einzelteile. Nicht nur die kleinen Aufgaben sondern auch die Erläuterung des eigentlichen Zieles ist sinnvoll. Denn irgendwie müssen ja die Teile auch zusammenspielen, um das Ziel zu erreichen.

          Laß uns das mal an Hand eines _völlig_ trivialen php-Beispiels ansehen. Das würde bei mir _so_ aussehen:

          <?php  
           // Setzen der utf-8 Kodierung für diese Datei:  
           header("Content-type:text/html;charset=utf-8");  
          ?>
          
          <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">  
            
          <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">  
            
           <head>  
            <meta http-equiv="content-type" content="text/html; charset=utf-8" />  
            <title>php-Beispiel</title>  
           </head>  
            
           <body>
          
            <?php  
             // BESTIMMUNG DES BRAUTPAARES  
             // ==========================  
             // 1.) Bestimmung der Namensvariablen:  
             $variable1='Hans';  
             $variable2='Herta';  
             // 2.) Ausgabe der Namen des Brautpaares:  
             echo"<p>".$variable1." und ".$variable2." sind ein Ehepaar.</p>\n";  
             // BESTIMMUNG DES JUBILÄUMS  
             // ========================  
             // 1.) Bestimmung der Jahreszahlen:  
             $hochzeitsjahr='1965';  
             $aktuellesjahr='2008';  
             // 2.) Berechnung des Jubiläums:  
             $ehedauer=$aktuellesjahr-$hochzeitsjahr;  
             // 3.) Ausgabe des Hochzeitjubiläums:  
             echo"  <p>Die beiden feiern heuer ihr ".$ehedauer.". Ehejahr.</p>\n";  
            ?>
          
           </body>  
            
          </html>
          

          Also abgesehen von der Sinnlosigkeit und Einfachheit dieser Seite, es geht hier jetzt nur um die prinzipielle Frage der Kommentierung: Wie würdest Du das anhand Deiner Kommentar-Kriterien lösen?

          MfG

          Hugo Egon Balder

          1. echo $begrüßung;

            Hi dedlfix,

            Vielleicht nur ein Formulierungsfehler, aber hinzuschreiben was passiert, ist überflüssig. Das sieht man aus dem Code. Es ist sinnvoller, hinzuschreiben, was passieren _soll_

            ich verstehe den Unterschied nicht, den Du meinst.

            Das große Ganze ergibt sich aus der Summe der Einzelteile. Nicht nur die kleinen Aufgaben sondern auch die Erläuterung des eigentlichen Zieles ist sinnvoll. Denn irgendwie müssen ja die Teile auch zusammenspielen, um das Ziel zu erreichen.

            Laß uns das mal an Hand eines _völlig_ trivialen php-Beispiels ansehen. Das würde bei mir _so_ aussehen:

            // Setzen der utf-8 Kodierung für diese Datei:
            header("Content-type:text/html;charset=utf-8");

            Das ist eigentlich trivial und braucht keinen Kommentar. Außerdem ist er nicht richtig. Diese Angabe teilt dem Empfänger mit, welcher MIME-Type und welche Kodierung vorliegt. Sie wird damit keineswegs beeinflusst, wie man den Kommentar deuten kann. Außerdem gibt es den Begriff Datei bei HTTP nicht. Es ist ein Dokument oder Ressource. Schließlich wird der auszuliefernde Inhalt erst erzeugt und ob der Client daraus eine Datei macht ist ungewiss und unerheblich.

            Inhaltlich würde ich es so formulieren: Informieren des Empfängers über die Art der Daten mittels eines HTTP-Headers.

            // BESTIMMUNG DES BRAUTPAARES

            Bestimmung ist mehrdeutig interpretierbar, was bedeutet es in diesem Fall konkret? Sinn und Zweck des Brautpaares oder Ermittlung von Daten über es?

            // 1.) Bestimmung der Namensvariablen:
               $variable1='Hans';
               $variable2='Herta';

            Variablen zu erstellen ist etwas, das man beim Programmieren gleich zu Anfang kennenlernt, also kein kommentierungswürdiger Vorgang an sich. Interessant wäre(n) die Aufgabe(n) der Variable(n), besonders bei solch einem unpassenden Variablennamen. Auch hier ist wieder "Bestimmung" ein ungünstiges Wort, denn es wird ja nichts ermittelt sondern nur aus festen Werten initialisiert. Vielleicht wird im eigentlichen Code der Inhalt von woanders hergeholt, dann wäre es vielleicht interessant über diesen Vorgang etwas zu erfahren, wenn das nicht zum Programmiergrundwissen gehört.

            // 2.) Ausgabe der Namen des Brautpaares:
               echo"<p>".$variable1." und ".$variable2." sind ein Ehepaar.</p>\n";

            echos alleinige Aufgabe ist nun mal die Ausgabe. Ein Kommentar in der Richtung ist überflüssig. abgesehen davon, dass die Variablen keine aussagekräftigen Namen haben. Ein Kommentar lohnt sich dann, wenn etwas nicht offensichtliches erfolgt. Beispielsweise vielleicht, wenn ein auszugebender (Teil)ausdruck eine Berechnung ist, dann wäre der Sinn der Berechnung interessant, so er sich nicht von selbst erklärt.

            // BESTIMMUNG DES JUBILÄUMS
               // ========================
               // 1.) Bestimmung der Jahreszahlen:
               $hochzeitsjahr='1965';
               $aktuellesjahr='2008';

            Siehe oben.

            // 2.) Berechnung des Jubiläums:
               $ehedauer=$aktuellesjahr-$hochzeitsjahr;

            Hier sieht man ebenfalls auf den ersten Blick, dass es sich um eine Berechnung handelt. Zudem ist schon durch die Wahl der Variablennamen der Sinn dieser Zeile gut zu erkennen.

            // 3.) Ausgabe des Hochzeitjubiläums:
               echo"  <p>Die beiden feiern heuer ihr ".$ehedauer.". Ehejahr.</p>\n";

            Ebenfalls siehe oben.

            Also abgesehen von der Sinnlosigkeit und Einfachheit dieser Seite, es geht hier jetzt nur um die prinzipielle Frage der Kommentierung: Wie würdest Du das anhand Deiner Kommentar-Kriterien lösen?

            Dieses Beispiel ist eben aufgrund seiner Einfachheit wenig geeignet, eine meiner Meinung nach gute Kommentierung zu zeigen. Stattdessen konnte ich nur die vorhandene kritisieren. Ich hoffe aber, dass trotzdem deutlich wurde, welche Art der Kommentierung ich bevorzuge: eine die nicht offensichtlichen Sinn und Zweck beschreibt sowie Hintergrundwissen zu einem bestimmten Vorgang vermittelt.

            echo "$verabschiedung $name";

            1. Hi dedlfix,

              // BESTIMMUNG DES BRAUTPAARES

              Bestimmung ist mehrdeutig interpretierbar, was bedeutet es in diesem Fall konkret? Sinn und Zweck des Brautpaares oder Ermittlung von Daten über es?

              Die Kommentare dienen ja in erster Linie _mir_, und wenn es sich um Code handelt, der über mehrere Seiten in meinem Editor geht, dann ist das sehr wohl eine Hilfe, alleine schon, um den entsprechenden Punkt schneller zu finden. Mir ist gestern als Kurzbeispel nichts Besseres eingefallen, aber ich verstehe die Wortklauberei nicht. An dem Punkt in diesem (inhaltlich sinnlosen) Code "entsteht" durch die Variablen sozusagen das Brautpaar. Und wenn dies das Teilstück einer langen Seite wäre, wüßte ich beim schnellen runterscrollen auf den ersten Blick: Aha, hier werden die Namen des Brautpaares definiert. Ob das Wort "Bestimmung" nun mehrdeutig ist oder nicht, interessiert mich ja in dem Zusammenhang nicht.

              // 1.) Bestimmung der Namensvariablen:
                 $variable1='Hans';
                 $variable2='Herta';

              Variablen zu erstellen ist etwas, das man beim Programmieren gleich zu Anfang kennenlernt, also kein kommentierungswürdiger Vorgang an sich.

              Das kann ich schon nachvollziehen, aber auch hier sehe ich es so, daß ich erstens die Stelle im Quellcode viel schneller finde (bei einer langen Seite) und zweitens bei einer Fehlermeldung wie zB Parse Error in Zeile soundso schon beim ersten Blick in den Code sehe, aha, bei der Berechnung von dem und dem ist ein Fehler drin. Natürlich ist es klar, daß eine Variablenerstellung was Simples und Eindeutiges ist und per se nicht kommentiert gehört, aber wenn ich das bei allen meinen php-Teilen so mache, dann empfinde _ich_ das einfach als eine größere Übersichtlichkeit. Tue ich das nämlich _nicht_, dann brauche ich bei einer komplexen Seite, die ich länger nicht vor mir hatte, schon sehr lange, bis ich mich zurechtfinde und sofort wieder weiß, was wofür da ist. Du darfst auch nicht vergessen, nicht jeder ist in Sachen php so gut wie zB. Du. Für mich sind Programmteile, die für Dich wahrscheinlich ohne Nachzudenken aus dem FF kommen, eine wirkliche Herausforderung. Und da _ist_ es einfach eine Hilfe, wenn ich mir alles kommentiere. Und wenn ich ein Problem habe und den Code jemanden zeige, weiß der auch sofort, was ich mir bei jedem Schritt gedacht habe und wozu der Teil jetzt gut ist oder gut sein _soll_.

              Interessant wäre(n) die Aufgabe(n) der Variable(n), besonders bei solch einem unpassenden Variablennamen. Auch hier ist wieder "Bestimmung" ein ungünstiges Wort, denn es wird ja nichts ermittelt sondern nur aus festen Werten initialisiert.

              siehe oben

              Vielleicht wird im eigentlichen Code der Inhalt von woanders hergeholt, dann wäre es vielleicht interessant über diesen Vorgang etwas zu erfahren, wenn das nicht zum Programmiergrundwissen gehört.

              [...]

              Beispielsweise vielleicht, wenn ein auszugebender (Teil)ausdruck eine Berechnung ist, dann wäre der Sinn der Berechnung interessant, so er sich nicht von selbst erklärt.

              Darum hätte ich ja gerne ein Beispiel gesehen, gerne auch ein etwas komplexeres, um zu sehen, wie _Du_ das löst mit dem Kommentieren.

              Ich hoffe aber, dass trotzdem deutlich wurde, welche Art der Kommentierung ich bevorzuge: eine die nicht offensichtlichen Sinn und Zweck beschreibt sowie Hintergrundwissen zu einem bestimmten Vorgang vermittelt.

              Was wäre zum Beipiel "nicht offensichtlicher Sinn und Zweck"?

              // Setzen der utf-8 Kodierung für diese Datei:
              header("Content-type:text/html;charset=utf-8");

              Das ist eigentlich trivial und braucht keinen Kommentar.

              siehe oben

              Außerdem ist er nicht richtig. Diese Angabe teilt dem Empfänger mit, welcher MIME-Type und welche Kodierung vorliegt. Sie wird damit keineswegs beeinflusst, wie man den Kommentar deuten kann.

              Aber es geht doch darum, daß der Empfänger dierser Ressource die Information bekommt, dass das, was hier gerade kommt, utf-8 codiert ist. Mit "Setzen" meinte ich die Tatsache, dass dies hiermit mitgeteilt wird.

              Außerdem gibt es den Begriff Datei bei HTTP nicht.

              Die Ressource liegt bei mir lokal als php-Dokument vor. Das _ist_ somit doch eine Datei, oder? Du hast mit all den technischen Begrifflichkeiten sicher Recht, warum ich das so formuliert habe, hab ich im letzten Absatz geschrieben.

              MfG

              Hugo Egon Balder

              1. echo $begrüßung;

                Ob das Wort "Bestimmung" nun mehrdeutig ist oder nicht, interessiert mich ja in dem Zusammenhang nicht.

                Sollte dich aber, denn der Leser muss es verstehen. Da hilft es ihm wenig, wenn es ihn auf eine falsche Fährte führen kann oder mehr Verwirrung stiftet als Erklärung das Ziel war.

                Eine nützliche Fähigkeit, die ich bei vielen wenig ausgeprägt finde, ist, etwas aus der Perspektive eines anderen zu betrachten. Nicht nur die eigenen Gedanken beachten sondern auch die Wünsche und Bedürfnisse der anderen Beteiligten berücksichtigen und welche Auswirkungen das eigene Tun und Lassen auf andere hat bzw. wie das Ergebnis auf andere wirken könnte.

                Variablen zu erstellen ist etwas, das man beim Programmieren gleich zu Anfang kennenlernt, also kein kommentierungswürdiger Vorgang an sich.
                Das kann ich schon nachvollziehen, aber auch hier sehe ich es so, daß ich erstens die Stelle im Quellcode viel schneller finde (bei einer langen Seite)

                Nun, ich denke, es gibt bessere Möglichkeiten der Strukturierung. Beispielsweise, indem man Abschnitte optisch trennt, genauso wie man Absätze im Fließtext eines Buches verwendet. Im Programmcode bieten sich dafür Leerzeilen an. Manche Systeme unterstützen solch eine Abschnittsbildung mit spezieller Syntax. C# beispielsweise:

                #region Bezeichnung
                  ...
                  #endregion

                In den .NET-IDEs lassen sich solche Abschnitte zusammenklappen, was auch zur Übersicht beiträgt.

                und zweitens bei einer Fehlermeldung wie zB Parse Error in Zeile soundso schon beim ersten Blick in den Code sehe, aha, bei der Berechnung von dem und dem ist ein Fehler drin.

                Das ist vielleicht grad ein schlechtes Beispiel, denn ein Parse-Error hat mit dem Inhalt des Codes nicht viel zu tun. Die Fälle, in denen man eine Kommentierung braucht, sind inhaltlicher Natur, wenn ein Programm zwar läuft, aber unerwartete Ergebnisse liefert. Dann muss man denn Sinn und Zweck einer Passage kennen, um harausfinden zu können, welcher Codeteil nicht der Intention entspricht und korrigiert gehört. Oder auch, dass ein bestimmter Teil explizit so geschrieben wurde und nicht anders, weil er sonst aus nicht offen sichtbaren Gründen Probleme gemacht hat.

                Und wenn ich ein Problem habe und den Code jemanden zeige, weiß der auch sofort, was ich mir bei jedem Schritt gedacht habe und wozu der Teil jetzt gut ist oder gut sein _soll_.

                Eben das ist der strittige Punkt. Ich sehe da nur, dass du da was hingeschrieben hast, aber deine Gedanken dazu kann ich dem nicht entnehmen. Das ist auch nicht so ganz einfach, denn im Moment des Schreibens weiß man oft nicht, was einen beim späteren Lesen interessiert und was man sich vom eigentlichen Vorgang noch gemerkt hat. Gute Kommentierung weiß man erst dann richtig zu schätzen und zu erstellen, wenn man genügend negative Erfahrungen mit der Kommentarqualität des eigenen Codes gemacht hat. Das ging mir ja schließlich genau so.

                Beispielsweise vielleicht, wenn ein auszugebender (Teil)ausdruck eine Berechnung ist, dann wäre der Sinn der Berechnung interessant, so er sich nicht von selbst erklärt.
                Darum hätte ich ja gerne ein Beispiel gesehen, gerne auch ein etwas komplexeres, um zu sehen, wie _Du_ das löst mit dem Kommentieren.

                Bei vielen Stringoperationen muss man Positionsangaben um 1 erhöhen oder verringern, weil man die Stelle vor oder hinter einem Zeichen meint. Außerdem sind die Zählweisen unterschiedlich. Der Mensch fäng üblicherweise bei 1 an, manche Systeme auch, andere bei 0. Das Zählweisenproblem, und welche Weise ein System verwendet, kennt ein erfahrener Programmierer. Als weniger Erfahrener kann man sich durchaus einen Hinweis notieren, ob ab 0 oder 1 gezählt wird. Auch schadet ein Beispiel nicht, das aufzeigt, wie aus einem bestimmten Ausgangswert etwas anderes ermittelt wird.

                Wenn eine Pfadangabe bearbeitet wird, ist es dann Absicht, dass ein / am Ende steht oder nicht? Diese Information geht aus unkommentiertem Code nicht hervor. Man sieht nur, dass der Code einen / stehen lässt oder nicht, und weiß erst bei weiteren Recherchen nach dem Verbleib der bearbeiteten Pfadangabe, ob dieser / ein Fehler ist oder nicht. Die Absicht eines (nicht) vohandenen / ist kommentierungswürdig. In dem Fall kann man das auch als

                # Ein / am Ende wird abgeschnitten.

                kommentieren, denn nun weiß man, aufgrund des Kommentars auf jeden Fall die Absicht, selbst wenn der Code des Abschneidens trivial übersichtlich ist.

                Ich hoffe aber, dass trotzdem deutlich wurde, welche Art der Kommentierung ich bevorzuge: eine die nicht offensichtlichen Sinn und Zweck beschreibt sowie Hintergrundwissen zu einem bestimmten Vorgang vermittelt.
                Was wäre zum Beipiel "nicht offensichtlicher Sinn und Zweck"?

                Das ist ganz sicher erfahrungsabhängig. Kontextgerechtes Behandeln beim Einfügen von Werten in den Ausgabedatenstrom mit den dafür vorgesehen und üblicherweise verwendeten Funktionen ist offensichtlich. Das Weglassen ist offensichtlich ein Fehler, kann aber im Einzelfall durchaus beabsichtigt sein. Das ausnahmsweise Verwenden einer unüblichen Alternative ist vielleicht ebenfalls nicht selbsterklärend. Dann ist das einen erklärenden Kommentar wert. (Dass es vielleicht bessere Möglichkeiten der Lösung des eigentlichen Problems gibt sei dahingestellt.)

                // Setzen der utf-8 Kodierung für diese Datei:
                header("Content-type:text/html;charset=utf-8");
                [...] Außerdem ist er nicht richtig. Diese Angabe teilt dem Empfänger mit, welcher MIME-Type und welche Kodierung vorliegt. Sie wird damit keineswegs beeinflusst, wie man den Kommentar deuten kann.

                Aber es geht doch darum, daß der Empfänger dierser Ressource die Information bekommt, dass das, was hier gerade kommt, utf-8 codiert ist. Mit "Setzen" meinte ich die Tatsache, dass dies hiermit mitgeteilt wird.

                Unklare Formulierungen können verwirrend sein. Man erlebt des öfteren, dass Anfänger fragen: "Ich hab meinen Header umgeschrieben, warum werden meine Daten nicht auch so ausgeliefert?" Sie lasen vermutlich irgendwo "Setzen der UTF-8-Kodierung" und interpretierten das falsch. Sie interpretieren eine Aktion hinein und wussten nicht, dass das nur eine Information ist.

                Außerdem gibt es den Begriff Datei bei HTTP nicht.
                Die Ressource liegt bei mir lokal als php-Dokument vor. Das _ist_ somit doch eine Datei, oder?

                Mitnichten, denn die Ressource ist aus Sicht dem Empfängers das, was der Webserver ausliefert. Der Browser sieht nicht die Quellcode-Datei sondern das Ergebnis ihrer Ausführung. Vielleicht hast du ja mehrere Dateien (Code, Daten) benötigt, oder andere Datenquellen angezapft um die Ausgabe zu erstellen. Das als (eine) Datei zu bezeichnen ist nun ganz offensichtlich nicht mehr richtig. Und letztlich für den Browser unwichtig und nicht nachvollziehbar. Und weil es unerheblich ist, wo seine empfangenen Daten herstammen und wieviel und welcher Art Quellen dazu verwendet wurden, und gerade deshalb, weil der Rückschluss, was der Browser empfängt, ist oder war eine Datei, nicht generell zutreffend ist, verwendet man den Begriff Datei in diesem Zusammenhang konsequenterweise gleich gar nicht. (P.s. Magst du Schachtelsätze? :-)

                Du hast mit all den technischen Begrifflichkeiten sicher Recht, [...]

                So bin ich nun mal. Ich versuche immer möglichst genau und mit den richtigen Begriffen zu formulieren, um Unstimmigkeiten bei der Informationsweitergabe zu vermeiden. (Gelingt mir nicht immer, aber ich arbeite ständig daran.)

                echo "$verabschiedung $name";

                1. Hi dedlfix,

                  ich kann mich nicht erinnern, hier schon mal Ratschläge _nicht_ befolgt zu haben. Auch Du warst mir schon öfters eine große Hilfe.

                  In _diesem_ Fall aber muß ich trotzdem feststellen. Ich lasse mich von meinem Standpunkt nicht abbringen.

                  Mir ist klar, dass eine Echo-Anweisung nur eine simple Ausgabe bewirkt. Entsprechend einfach ist dann auch ein Kommentar dazu.

                  Du magst das unnötig finden, _mir_ ist das eine Hilfe.

                  Bei mir bekommt entweder jeder einzelne Befehl oder ein Programmteil einen Kommentar, in dem steht, was in Folge passiert.

                  Ob das Wort "Bestimmung" nun mehrdeutig ist oder nicht, interessiert mich ja in dem Zusammenhang nicht.

                  Sollte dich aber, denn der Leser muss es verstehen. Da hilft es ihm wenig, wenn es ihn auf eine falsche Fährte führen kann oder mehr Verwirrung stiftet als Erklärung das Ziel war.

                  Wie ich schon mehrfach gesagt habe, der Leser bin _ich_, da mir diese Kommentare als Hilfe beim Schreiben des Codes dienen. Und sollte ich ein Problem haben und mich mit dem Code an jemanden wenden, dann weiß der auch ganz sicher, was ich mit den Kommentaren gemeint habe bzw. was mein Ziel beim entsprechenden Programmteil war.

                  Eine nützliche Fähigkeit, die ich bei vielen wenig ausgeprägt finde, ist, etwas aus der Perspektive eines anderen zu betrachten.

                  Wie war das mit den Steinen und dem Glashaus?

                  Und wenn ich ein Problem habe und den Code jemanden zeige, weiß der auch sofort, was ich mir bei jedem Schritt gedacht habe und wozu der Teil jetzt gut ist oder gut sein _soll_.

                  Eben das ist der strittige Punkt. Ich sehe da nur, dass du da was hingeschrieben hast, aber deine Gedanken dazu kann ich dem nicht entnehmen.

                  Also komm! Um bei meinem trivialen Ursprungsbeispiel zu bleiben:

                  // BESTIMMUNG DES BRAUTPAARES  
                  // ==========================  
                  // 1.) Bestimmung der Namensvariablen:  
                  $variable1='Hans';  
                  $variable2='Herta';  
                  // 2.) Ausgabe der Namen des Brautpaares:  
                  echo"<p>".$variable1." und ".$variable2." sind ein Ehepaar.</p>\n";
                  

                  Wenn ich Dich da um Hilfe bitten würde und Dir das so zeige, willst Du mir aber nicht sagen, dass Du durch meine Kommentare nicht verstündest, was ich damit meine und was das Ziel des entsprechenden Codeteils ist. Doppelbedeutung von technischen Ausdrücken hin oder her.

                  Ich hoffe aber, dass trotzdem deutlich wurde, welche Art der Kommentierung ich bevorzuge: eine die nicht offensichtlichen Sinn und Zweck beschreibt sowie Hintergrundwissen zu einem bestimmten Vorgang vermittelt.

                  Gut, dann haben wir einfach 2 unterschiedliche Auffassungen darüber. Belassen wir es dabei.

                  Ich bedanke mich für die Informationen und den Diskurs zu dem Thema.

                  MfG

                  Hugo Egon Balder

                  1. Wie ich schon mehrfach gesagt habe, der Leser bin _ich_, da mir diese Kommentare als Hilfe beim Schreiben des Codes dienen. Und sollte ich ein Problem haben und mich mit dem Code an jemanden wenden, dann weiß der auch ganz sicher, was ich mit den Kommentaren gemeint habe bzw. was mein Ziel beim entsprechenden Programmteil war.

                    Als Programmierer solltest du aber schon wissen, was die einzelnen Befehle tun. Was du anhand des Quelltextes nicht genau wissen kannst, ist aber der Sinn und Zweck der Befehle. Ich gebe dir mal ein passendes Beispiel in JavaScript:

                    Dein Kommentarstil:

                    function forEach(a,f,o){ // Bestimmung der Funktionsparameter  
                      for(var i=0,l=a.length /* Bestimmung der Schleifenvariablen */; i<l /* Bedingung der Schleife */; i++ /* Schleifenschritt */){  
                        f.call(o,a[i]);}} // Aufruf von f.call mit den Argumenten o und a[i].
                    

                    Erklärender Kommentarstil:

                    /* Durchläuft das Array a und ruft für jedes Element a[i] die Funktion f im Kontext o mit dem Element als Argument auf. */  
                    function forEach(a,f,o){  
                      for (var i=0,l=a.length;i<l;i++){  
                        f.call(o,a[i]);}}
                    

                    Wobei dieses Beispiel so trivial ist, dass es eigentlich keines Kommentars bedarf.

                    // BESTIMMUNG DES BRAUTPAARES

                    // ==========================
                    // 1.) Bestimmung der Namensvariablen:
                    $variable1='Hans';
                    $variable2='Herta';
                    // 2.) Ausgabe der Namen des Brautpaares:
                    echo"<p>".$variable1." und ".$variable2." sind ein Ehepaar.</p>\n";

                    
                    >   
                    > Wenn ich Dich da um Hilfe bitten würde und Dir das so zeige, willst Du mir aber nicht sagen, dass Du durch meine Kommentare nicht verstündest, was ich damit meine und was das Ziel des entsprechenden Codeteils ist. Doppelbedeutung von technischen Ausdrücken hin oder her.  
                    
                    Es dauert aber viel länger, weil er die Kommentare lesen müsste, die ihm keine Hilfe sind.  
                      
                    
                    > > > > Ich hoffe aber, dass trotzdem deutlich wurde, welche Art der Kommentierung ich bevorzuge: eine die nicht offensichtlichen Sinn und Zweck beschreibt sowie Hintergrundwissen zu einem bestimmten Vorgang vermittelt.  
                    >   
                    > Gut, dann haben wir einfach 2 unterschiedliche Auffassungen darüber. Belassen wir es dabei.  
                    
                    Da gibt es keine unterschiedlichen Auffassungen. `$a=$b+$c;`{:.language-php} benötigt keinen Kommentar, weil der Programmschnippsel selbsterklärend ist. Wer nicht weiß, was diese Anweisung macht, kann sowieso nicht programmieren (in PHP, in diesem Fall). Was derjenige u.U. aber nicht weiß, ist, warum `$b`{:.language-php} und `$c`{:.language-php} addiert werden und in `$a`{:.language-php} gespeichert werden.  
                      
                    
                    > Ich bedanke mich für die Informationen und den Diskurs zu dem Thema.  
                    
                    Wie sieht eigentlich der von dir generierte HMTL-Code aus?  
                    ~~~html
                    <!-- Überschrift 1. Grades -->  
                    <h1>Blabla</h1>  
                    <!-- Absatz -->  
                    <p>Bla bla bla.</p>  
                    <!-- Ungeordnete Liste -->  
                    <ul>  
                    <!-- Listenpunkt -->  
                    <li>Bla bla.</li>  
                    (...)
                    

                    ?
                    Und CSS?

                    p /* Selektiert alle p-Elemente (Absätze) */  
                    {  
                    color:red; /* Färbt die Schrift rot. */  
                    (...)  
                    }
                    

                    ?
                    Wäre ja nur konsequent.

                    --
                    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
                    Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|
  3. Guten Tag,

    Nun frage ich mich, wie das die Ladezeit einer Seite beeinflußt.
    Wenn der php-Parser zu einer Zeile kommt, die mit //
    beginnt, arbeitet er die dann ab, was zu einer Vergrößerung der Ladezeit
    führen würde, oder springt er sofort zur nächsten Zeile, was die Ladezeit
    einer Seite mit Kommentaren zu der einer Seite ohne selbigen nicht
    verändern würde?

    Nein, PHP liest den gesamten Text einer Seite ein, auch Blocks außerhalb der <?php-?>-Tags (das sind dann Inline-HTML-Blocks, T_INLINE_HTML (311). Der PHP-interne Tokenizer zerlegt ein Skript in seine Bestandteile, darunter gibt es auch das T_COMMENT-Token, welches den Inhalt des Kommentars enthält:

    jeschkec@shire:~$ php -r "var_dump(token_get_all('<?php // blubb ?>'));"

      
    array(3) {  
      [0]=>  
      array(3) {  
        [0]=>  
        int(367)  
        [1]=>  
        string(6) "<?php "  
        [2]=>  
        int(1)  
      }  
      [1]=>  
      array(3) {  
        [0]=>  
        int(365)  
        [1]=>  
        string(9) "// blubb "  
        [2]=>  
        int(1)  
      }  
      [2]=>  
      array(3) {  
        [0]=>  
        int(369)  
        [1]=>  
        string(2) "?>"  
        [2]=>  
        int(1)  
      }  
    }
    

    365 ist die interne Konstante für das T_COMMENT-Token, 367 und 369 für die Open- und Closing-Tags, 1 jeweils die Zeilennummer (in diesem Fall gibt es nur eine Zeile).

    Summa sumarum: Ja, Kommentare haben, genau wie Nicht-PHP-Blocks, Einfluss auf die Performance. Zumindest was Kommentare angeht, ist dieser aber gut investiert. Du solltest dir auch mal phpdoc anschauen.

    Man kann mit dem Tokenizer auch coole andere Sachen machen, zum Beispiel Call Charts.

    Hugo Egon Balder

    Karrierewechsel?

    Gruß
    Christoph Jeschke

    --
    Zend Certified Engineer
    Certified Urchin Admin
    1. Summa sumarum: Ja, Kommentare haben, genau wie Nicht-PHP-Blocks, Einfluss auf die Performance. Zumindest was Kommentare angeht, ist dieser aber gut investiert. Du solltest dir auch mal phpdoc anschauen.

      ergänzend gibt es zu sagen, dass php keinen byte cache hat und somit das script bei jedem aufruf in maschinensprache übersetzen muss - dass dabei einen logik greift, die kommentare entfernt, ist klar - aber das kostet (wenn auch nicht viel) zeit

      obs benchmarks zur art des kommentars gibt (// vs. /* */ weiss ich nicht, wäre aber auch interessant, wie groß der einfluss hierbei ist

      um dieses manko zu kompensieren, gibts zb dinge wie den eAccelerator