Werden php Kommentare mitverarbeitet/geparst?

[dedlfix]

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";