Website-Struktur und Skript-Stil oder so ähnlich

[foomaker]

Ich möchte mal eine (vermutlich nicht die erste, aber wohl hoffentlich auch nicht die letzte) Diskussion anregen über das spannende (meine ich ernst) Thema "Website-Struktur und Skript-Stil".

Worum geht es?
Stichpunkte: Große website (also groß genug, um planvoll und strukturiert vorgehen zu MÜSSEN), php, html, javascript, perl, dokumentiert, phpdoc

Ich habe Weiterentwicklung und Pflege eine site übernommen, auf die folgende Merkmale zutreffen:

• Skriptstil uneinheitlich
• Spaghetticode
• html, php und javascript fröhlich gemischt
• ganze Skriptteile ungenutzt, weil sich offenbar niemand traute was zu löschen. Es könnte ja in irgendeinem noch zu includierenden Skript zu was nutze sein
• include-Labyrinthe vom Feinsten. Jeder (!!!) Link ruft die index.php mit einem Rattenschwanz an Parametern auf. Von dort aus wird fleissig includiert - bis in die 5. Ebene.
• apropos Parameterübergabe: Mal session-Vars, mal post, mal get - keinesfalls ein System erkennbar.
• Dokumentation Fehlanzeige
• tote Skripte, die nur zu Testzwecken mal erstellt, aber nie eingebunden wurden
• und und und

Nun ist also ein "Kollege" der Ansicht, das sei üblicher Skript-Stil. Ich wiederum sehe das ganz anders. Aufgeräumter Code, Dokumentation, einheitlicher Stil, Übersichtlichkeit, Struktur sind meiner Meinung nach das A & O guter Programmierung. Einwand "Kollege": "Das kostet doch alles viel zu viel Zeit."
Das kostet Zeit - da hat er wohl Recht, aber Zeit, die sich am Ende wieder rechnet - nämlich bei Erweiterungen und Änderungen, wenn man nicht tagelang ergründen muss, was sich der Skripter wohl bei diesem und jenem gedacht haben könnte.

Manches ist sicher begründet auf persönlichen Vorlieben. Aber auch, wenn ich vlibTemplate sehr schätze, also php und html strikt trenne, käme ich doch mit sauberer heredoc-Syntax klar, wenn denn dies einer bevorzugen sollte. Darum gehts mir nicht.
Aber php-Code, der vor Variablen strotzt (einheitliche Gross- und Kleinschreibung übrigens Fehlanzeige, weil's ja "egal" ist) wie z.B. "$kn" für Kundennummer statt $kundennummer oder wenigstens $kdnr, macht mir eine Gänsehaut des Grauens. ;-)

Also ich rede nicht von Geschmacksfragen, sondern von einer Art "Grundregeln für sauberen Programmierstil" - sicherlich übergreifend gültig auch für Perl, Java, Delphi, C++ u.a.

Wie ist Eure Meinung? Habt Ihr eine "Bibel" für so etwas? Wie wichtig ist Euch dieses Thema? Wie sind eure Erfahrungen? Includiert Ihr auch auf Teufel komm raus, weil das "das Einfachste" ist? Dokumentiert Ihr ordentlich, vieleicht wie ich mit phpdoc?

So, lass mal lesen. ;-)

Gruß vom foomaker

[Tom]

Hello,

https://forum.selfhtml.org/?t=163299&m=1063271

ich sag mal "Doppelposting". Zwar nicht Deins, aber die Fortführunge des anderen Threads wäre sicherlich fruchtbarer.

Vielleicht kopierst Du Deinen dorthin, dann kann dieser hier geschlossen werden.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[foomaker]

Vielleicht kopierst Du Deinen dorthin, dann kann dieser hier geschlossen werden.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

Kann geschlossen werden. hab ich "dorthin" kopiert. Danke. ;-)

[Kai345]

Grütze .. äh ... Grüße!

http://forum.de.selfhtml.org/my/?t=163299&m=1063271

ich sag mal "Doppelposting". Zwar nicht Deins, aber die Fortführunge des anderen Threads wäre sicherlich fruchtbarer.

Vielleicht kopierst Du Deinen dorthin, dann kann dieser hier geschlossen werden.

Da mich das Thema Code-Strikturierung auch sehr interessiert:
Ich seh beim verwiesenen Thread nur eine einzige Nachricht von kölir?

Cü
Kai

[Kai345]

Grütze .. äh ... Grüße!

ich sag mal "Doppelposting". Zwar nicht Deins, aber die Fortführunge des anderen Threads wäre sicherlich fruchtbarer.

Vielleicht kopierst Du Deinen dorthin, dann kann dieser hier geschlossen werden.

Da mich das Thema Code-Strikturierung auch sehr interessiert:
Ich seh beim verwiesenen Thread nur eine einzige Nachricht von kölir?

Habe es jetzt selber gefunden: Der andere Thread ist Thema PHP, was ich ausgeblendet habe.
Warum wird dieser Thread, der genau in der korrekten Kategorie eröffnet wurde, als Doppelposting markiert und auf einem Programmiersprachen-spezifischen Thread verwiesen? Gibt es Codestrukturierung etwa nur in PHP? Was soll der Mist?

sehr verärgert,

Kai

[Siechfred]

Warum wird dieser Thread, der genau in der korrekten Kategorie eröffnet wurde, als Doppelposting markiert und auf einem Programmiersprachen-spezifischen Thread verwiesen? Gibt es Codestrukturierung etwa nur in PHP? Was soll der Mist?

Nur weil Tom es als „Doppelposting“ deklariert hat, bedeutet das noch lange nicht, dass der Thread als solches markiert wurde. Würde die Moderation die Ansicht teilen (tut sie nicht, siehe Antwort von Sven), wäre dieser Thread gesperrt, doch das ist er nicht.

sehr verärgert,

Es gibt keinen Grund dafür :)

Siechfred

[Sven Rautenberg]

Moin!

ich sag mal "Doppelposting". Zwar nicht Deins, aber die Fortführunge des anderen Threads wäre sicherlich fruchtbarer.

Sicherlich nicht!

Das hier ist nicht mal im geringsten Ansatz ein Doppelposting.

Vielleicht kopierst Du Deinen dorthin, dann kann dieser hier geschlossen werden.

Ich hab die Kopie gelöscht, dieser Thread hier wird weitergeführt.

- Sven Rautenberg

[McKinsey]

Guten Tag zusammen,

meiner Meinung nach enthält der Begriff "Sauberer Programmierstil" bereits die wichtigsten Grundregeln desselben. Dazu gehören sicherlich ein aufgeräumter, übersichtlicher, gut kommentierter Programmcode, ein einheitlicher Stil was Klammersetzung und Bezeichner angeht und auf auf jeden Fall das Beachten der Grundregeln einer Sprache.

Ferner sollte man sich an die vorgeschlagenen Standards halten, wie sie in den meisten Büchern stehen (Beispiel PHP: Konstanten groß schreiben, Funktionsnamen möglichst im Imparativ etc.).

Damit ist ein sauberer Programmierstil gegeben.

Eine Dokumentation des entsprechenden Projekts anfertigen fasse ich jedoch nicht zum sauberen Programmstil, da er je nach Projekt nicht unbedingt erforderlich ist. Diesen Punkt würde ich eher in "saubere Projektführung" fassen.

MfG,

McKinsey

[Harlequin]

Yerf!

Nun ist also ein "Kollege" der Ansicht, das sei üblicher Skript-Stil.

Das mag ja sein... aber das heißt noch lange nicht, das es so gut ist.

Ich wiederum sehe das ganz anders. Aufgeräumter Code, Dokumentation, einheitlicher Stil, Übersichtlichkeit, Struktur sind meiner Meinung nach das A & O guter Programmierung.

Definitiv. Leider wirst du nie ein Projekt finden, bei dem das wirklich 100%ig durchgezogen wird. Spätestens wenn termindruck dazukommt wird doch weider schnell was "reingehackt" ohne zu Kommentieren oder auf die Form zu achten.

Einwand "Kollege": "Das kostet doch alles viel zu viel Zeit."
Das kostet Zeit - da hat er wohl Recht, aber Zeit, die sich am Ende wieder rechnet - nämlich bei Erweiterungen und Änderungen, wenn man nicht tagelang ergründen muss, was sich der Skripter wohl bei diesem und jenem gedacht haben könnte.

Das zu erkennen, da fehlt den Leuten meist der Überblick. Dazu müsste man erst enimal Abstand nehmen und von außen betrachten, womit man eigentlich seine Zeit  beim Programmieren verbringt. Ist es wirklich produktives Arbeiten oder ein sich im Wust zurechtfinden müssen?

Wie ist Eure Meinung? Habt Ihr eine "Bibel" für so etwas? Wie wichtig ist Euch dieses Thema? Wie sind eure Erfahrungen?

Eine "Bibel" sicher nicht, eher so etwas wie gelebte Praxis die sich bewährt hat, aber sicher noch verbesserungsfähig ist. z.B. wird zumindest jeder Codeblock kurz kommentiert, was die Aufgabe ist und natürlich gibts auch nen Kommentar für spezielle Tricks. Manche finden das zu wenig aber es reicht um den Überblick zu behalten. Dann noch ein paar Konventionen für Bebennungen von Methoden und Variablen und eine halbwegs übersichtliche Objektstruktur. Damit kann man schon ganz gut Arbeiten.

Includiert Ihr auch auf Teufel komm raus, weil das "das Einfachste" ist? Dokumentiert Ihr ordentlich, vieleicht wie ich mit phpdoc?

Da ich kein PHP verwende hab ich diese Probleme nicht so ;-)
Allerdings könnte man sicherlich auch in ASP.Net einige schlimme Dinge verbrechen, wie z.B. Code direkt in den ASPX-Seiten oder ähnliches...

Gruß,

Harlequin

[foomaker]

Da ich kein PHP verwende hab ich diese Probleme nicht so ;-)
Allerdings könnte man sicherlich auch in ASP.Net einige schlimme Dinge verbrechen, wie z.B. Code direkt in den ASPX-Seiten oder ähnliches...

Dann möchte ich noch mal näher auf diesen Punkt eingehen:

Mal ein Miniprojekt: Habe 2 Variablen "$summand1" und "$summand2". In diesem Beispiel sollen sie schlicht addiert werden, aber stellen wir uns mal vor, dass sei nicht mit einer Anweisung, sondern mit unter 20 Codezeilen nicht getan, dann steht "$ergebnis = $summand1 + $summand2" stellvertretend für 20 Zeilen Code, okay?

Skript 1 sähe dann so aus:

  
$summand1 = 5;  
$summand2 = 4;  

an dieser Stelle habe ich die Wahl:
a) ich baue die 20 Zeilen Code zur Addition an dieser Stelle direkt ein (nicht schön, macht Skript unübersichtlich)
b) ich packe die 20 Codezeilen in eine Funktion (kann in einem anderen Skript stehen) und rufe diese auf.
das sähe dann so aus:

  
$summand1 = 5;  
$summand2 = 4;  
$ergebnis = addiere_summanden($summand1,$summand2);  

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

  
$ergebnis = $summand1 + $summand2;  

Skript 1 müsste dann also so aussehen:

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

Ja, schon klar. Einfach lächerlich in diesem Beispiel. Aber ich denke, das Prinzip ist klar.

So, jetzt muss man sich nur vorstellen, dass in Skript 2 womöglich nicht addiert, sondern auch noch multipliziert werden soll. Das aber wiederum macht Skript 3, das in Skript 2 inkludiert wird. und so weiter und so weiter (ich merke wie schon wieder mein Blutdruck steigt)

So, nun nochmal meine Frage an unsere website-PHP-Tüftler: Inkludiert ihr auch bis zu 5 mal ineinander oder wie struktiert ihr große website-Projekte? Ich verrate dann auch meinen Lieblingsstil. ;-)

Gruß, foomaker

[Tom]

Hello,

So, nun nochmal meine Frage an unsere website-PHP-Tüftler: Inkludiert ihr auch bis zu 5 mal ineinander oder wie struktiert ihr große website-Projekte? Ich verrate dann auch meinen Lieblingsstil.

Da ich in meinen Include-Datei grundsätzlich keine Ausgaben auf die Standardausgabe mache, mit Ausnahme von Fatal Error mit sofortigem Abbruch und den auch nur dann, wenn ich ihn nicht vorhergesehen habe...

Es wird im Prinzip nur im jeweiligen Hauptscript includiert. Die Include-Dateien sind so geteilt, dass ich nicht immer alle benötige. Benutzer_VERWALTUNG benötige ich eben nur, wenn sich ein "Admin" anmeldet, den "Bunte-Tabellen-Generator" benötige sich nicht, wenn ich Anschriften erfassen will, usw...

Grundfunktionen und Grundkonfiguration gehören in eine Include-Datei. Die kennt auch den Pfad zur Modulübersicht. Zusdatzmodule werden nur dann geladen, wenn sie benötigt werden und vorhanden sind. das wird natürlich vorher geprüft.

Diese ganez Betrachtungsweise noch ohne OOP. Da habe ich bisher nur ganz kleine Projekte gemacht, so paradox sich das anhört. Meine Toolboxen sind eben fertig und die sind (aus der PHP4-Zeit) alle noch  ohne explizites OOP, aber teilweise mit zur Fuß gemachten OOP-Ansätzen.

"Array of Procedure" ist so ein Ding...

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Harlequin]

Yerf!

an dieser Stelle habe ich die Wahl:
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)

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.

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.  
  

> 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...

Gruß,

Harlequin

[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

[Sven Rautenberg]

Moin!

Ich habe Weiterentwicklung und Pflege eine site übernommen, auf die folgende Merkmale zutreffen:

Mein Beileid.

Nun ist also ein "Kollege" der Ansicht, das sei üblicher Skript-Stil. Ich wiederum sehe das ganz anders. Aufgeräumter Code, Dokumentation, einheitlicher Stil, Übersichtlichkeit, Struktur sind meiner Meinung nach das A & O guter Programmierung. Einwand "Kollege": "Das kostet doch alles viel zu viel Zeit."
Das kostet Zeit - da hat er wohl Recht, aber Zeit, die sich am Ende wieder rechnet - nämlich bei Erweiterungen und Änderungen, wenn man nicht tagelang ergründen muss, was sich der Skripter wohl bei diesem und jenem gedacht haben könnte.

Leute, die sich mit der Theorie von Softwareentwicklung beschäftigen, bezeichnen das, was man durch Quick-and-Dirty-Lösungen anhäuft, gerne mal als "technische Schulden". Genau wie Bankschulden erfordern auch diese Schulden das Zahlen von Zinsen. Das Problem ist nur, dass man die Zinshöhe nicht kennt, bevor man die Schulden macht.

Allerdings findet man das heraus, wenn man erstmal in den Schulden drinsteckt. Das mag eine Zeit lang noch ganz gut funktionieren, der Extra-Aufwand durch schlampiges oder unkonventionelles Vorgehen, nur um zu Beginn schnell eine Lösung zu erhalten, hält sich zunächst noch in Grenzen - weil die Anzahl solcher "Lösungen" noch gering ist, man den Überblick hat, man noch "im Code drin ist" etc. Und eventuell ist tatsächlich auch ein Teil dieser "Lösungen" wirklich für die Ewigkeit erstellt, d.h. nach der Indienststellung folgt nach einiger Zeit der Nutzung nur noch die komplette Einstampfung, aber keine zwischenzeitliche Anpassung mehr.

Aber je mehr Zeit vergeht, desto mehr "Zinsen" sammeln sich an, die irgendwann zurückgezahlt werden müssen, wenn man an einem bestehenden System wieder einmal etwas verändern muß - erhöhter Zeitaufwand, schlechte Erweiterbarkeit, hoher Arbeitswiderstand. :)

- Sven Rautenberg