Website-Struktur und Skript-Stil oder so ähnlich

[foomaker]

a) ich baue die 20 Zeilen Code zur Addition an dieser Stelle direkt ein (nicht schön, macht Skript unübersichtlich)

Wenn der Code nur an dieser Stelle benötigt wird und direkt zum Ablauf des umgebenden Codes gehört mach ich das durchaus. Ich finde das so besser lesbar, als wenn man sich erst die Funktion suchen muss. Allerdings wird dann der Abschnitt mit Kommentaren eingerahmt, damit man ihn sofort als zusammengehörigen Block mit der entsprechenden Aufgabe erfassen kann. (Außerdem kennt das Visual Studio #region-Blöcke für Codefolding im Editor)

Absolut einleuchtender Standpunkt solange es tatsächlich der Übersichtlichkeit dient.

b) ich packe die 20 Codezeilen in eine Funktion (kann in einem anderen Skript stehen) und rufe diese auf.

Ansonsten ist das der normale Weg. Ob die Funktion im gleichen File steht hängt davon ab, ob es eine universelle Funktion ist, die öfters benötigt wird, oder ob sie nur für diese Seite relevant ist. Universelle Hilfsfunktionen werden in statischen Klassen gesammelt.

Ganz genau. ;-)

c) ich includiere ein Skript, das diese Aufgabe übernimmt. Dieses Skript 2 sieht dann so aus:

$ergebnis = $summand1 + $summand2;

>   
> Und hier kommt der Punkt, wo ich sage "STOP!"  
> Das Script beeinflusst hier Variablen, die nicht zu seinem Bereich gehören.  
  
Stimmt. Auch aus meiner Sicht eine Katastrophe.  
  

> > Skript 1 müsste dann also so aussehen:  
> > ~~~php
  

> > $summand1 = 5;  
> > $summand2 = 4;  
> > include("skript2.php");  
> > echo $ergebnis; //Ausgabe des Ergebnisses  
> > 

Und bei der späteren Verwendung ist absolut nicht mehr klar, woher $ergebnis eigentlich kommt. Von den ganzen anderen Seiteneffekten die hier entstehen könnten gar nicht zu sprechen...

Wie dieser Stil entsteht kann ich mir aber gut vorstellen: Durch die Vermischung von HTML und Code die bei PHP möglich ist und vor allem Anfänger gerne machen (ist ja auch schön einfach) macht man sich um Funktionen und Trennung von Verarbeitung und Ausgabe kaum gedanken. Wenn man dann einen Code-Block öfter braucht nimmt man ihn einfach per Cut&Paste in eine Include-Datei und fertig. Das schlimme ist dann, dass man an Gewohntem festhält, egal wie groß die Projekte werden und wie sinnvoll eine andere Herangehensweise wäre...

Absolut richtig, Harlequin.

Schön, dass wir uns da verstehen.

"Vermischung von HTML und PHP" vom Allerfeinsten. Ich habe es hier mit Code zu tun, wo kryptische, nicht-dokumentierte Variablennamen wie $pf_art2 vorkommen, wo nahezu nichts "sprechend" ist, Funktionen nach dem Bauernkalender benannt wurden oder was-weiss-ich. Aber man soll ja  nicht lästern. Die (Haupt-)index.php strotzt von if(...) include(...) elseif(...) include(...) elseif...
Selbst die *.inc.php-Dateien mit Funktionen inkludieren nochmal andere Dateien mit Funktionen.

Anyway. :-)

Das Prinzip ist durchschaubar. Das, was fast alle Seiten (oder Gruppen von Seiten) gemeinsam haben, soll statisch auf der 1. index-Seite bleiben, während Veränderliches nach Bedarf inkludiert wird.

Ich bevorzuge das Gegenteil: Das, was auf jeder Seite gleich bleibt, wird inkludiert, z.B. Navi, Logo, Kopfzeile, Fusszeile u.a., aber auch Funktionen, Klassen, define-Listen. Und was sich ändert, kriegt neue, eigenständige Seiten.
Beispiel: Will ich von der Startseite aus das "Impressum" aufrufen, verlinke ich nicht zu "index.php?content=impressum" und um von dort dann das Kontaktformular aufzurufen mit "index.php?content=impressum&sub=kontakt (so machte es nämlich mein Vorgänger), SONDERN ich verlinke zu impressum.php - punkt. Dort werden Navi und was sonst noch der Startseite gleich ist, inkludiert.
Wobei es zu jeder content-bezogenen php-Seite noch ein entsprechendes HTML-Template gibt, da ich konsequent Inhalt und Form trenne.
Ich inkludiere niemals Teil-Content wie Teile einer table nach Bedarf. Das erledigt php und template, z.B. {tmpl_if name=adresse_vorhanden}<tr><td>...</td></tr>{/tmpl_if}

Vom sonstigen Stil her halte ich mich strikt an die "PHP Coding Standard - Regeln und Empfehlungen" von Claus van Beek, mit Ausnahme vielleicht von den Variablennamen - die sind bei mit normalerweise deutsch, obwohl mein Englisch ganz gut ist.

Gruß vom foomaker