Wie schreibt man möglichst guten Code?

[Marc]

Hallo,

mal ein paar Fragen. Was macht für euch guten, sauberen, effektiven PHP Code aus? Was für Tricks gibt es um den Code zu verkürzen?

Und was sind so beliebte oft genutzt Kürzel für irgendwelche Vorgänge (zum Bleistift sowas wie $a++; statt $a = $a +1)? Was gibt es in dieser Richtung noch?

Schreibt einfach was euch dazu einfällt

Grüsse

Marc

[Michael Keller]

Lies mal hier:
http://www.dclp-faq.de/ch/ch-code.html

Gruss Michael

[Dieter Raber]

Hallo,

Wirf mal einen Blick in die FAQ http://www.dclp-faq.de der deutschen PHP Newsgroup, da gibt es ein eigenes Kapitel darueber.

Dieter

[Thomas Luethi]

Hallo Marc,

mal ein paar Fragen. Was macht für euch guten, sauberen, effektiven PHP Code aus? Was für Tricks gibt es um den Code zu verkürzen?

Das Ziel sollte nicht unbedingt sein, dass der Code moeglichst kurz ist, sondern, dass Du ihn auch in 2 Jahren noch verstehst, wenn Du das Script wieder mal aus der Schublade ziehst.
Kommentare sind sicher schon mal nuetzlich.

Und was sind so beliebte oft genutzt Kürzel für irgendwelche Vorgänge (zum Bleistift sowas wie $a++; statt $a = $a +1)? Was gibt es in dieser Richtung noch?

Den Ausdruck
  $bedingung ? $ja : $nein ;
anstatt if / else finde ich ganz nett und platzsparend.

Beispiel:
$meldung=($eingabe==$passwort) ? "richtig" : "falsch";
print("Das Passwort war $meldung")

Schreibt einfach was euch dazu einfällt

dclp-FAQ: "Guter Code"
http://www.dclp-faq.de/ch/ch-code.html

mfg
Thomas

[Alexander Foken]

Moin Moin !

Guten Code schreibt man nach einer guten Planung. Wenn man richtig sauber Software entwickelt, ist das Coden nur noch das Abtippen eines extrem detailierten Ablaufplans. In der Praxis sieht das natürlich leicht anders aus.

So lange Du das gesamte Problem nicht bis ins letzte Details verstanden hast, kannst Du kein Programm schreiben. Wenn Du das Problem wirklich zu 100% begriffen hast, kannst Du auch mal auf eine Planung auf Papier verzichten und gleich zum Editor greifen. Das ist meine bevorzugte Methode für Kleinkram. Für große Projekte sollte man das Problem auf Papier in ausreichend kleine Teile zerlegen, so daß man nur noch einen Haufen Kleinkram zu lösen hat.

Tips für die Praxis:

* Sauber einrücken. Ob mit Spaces oder Tabs ist Geschmackssache, ich bevorzuge Tabs und einen Editor, bei dem man die Tab-Breite einstellen kann. Das kann mittlerweise jeder bessere Editor.
* Sprechende Variablen- und Funktionsnamen benutzen. Spaces gehen auch, Tabs + Spaces sind IMHO nur grausam.
* Modular programmieren, jede bessere Sprache kann Code auslagern (je nach Sprache nennt man das Module, Libraries, includes, units).
* Wenn Du einen Codeblock von mehr als drei Zeilen mehr als einmal kopierst, solltest Du daraus eine Funktion machen.
* Rückgabewerte von Systemfunktionen prüfen
* Genug Speicher bereithalten und Pufferüberläufe vermeiden.
* Benutzereingaben prüfen

Diese Liste läßt sich beliebig fortsetzen.

Wie Du siehst, steht das Kürzel PHP nur in diesem Absatz. Denn guter Code hat (nahezu) nichts mit der Sprache zu tun. Ich habe noch nie PHP programmiert, ich bevorzuge Perl, schreibe auch C, Pascal, bash, Javascript, HTML, und einiges andere, was gerade so anfällt. Und in allen Sprachen rücke ich fast identisch ein.

Alexander

[Tom2]

Hallihallo

* Modular programmieren, jede bessere Sprache kann Code auslagern (je nach Sprache nennt man das Module, Libraries, includes, units).
* Rückgabewerte von Systemfunktionen prüfen
* Benutzereingaben prüfen

Zu diesen drei Punkten habe ich eine kleine Frage, die mich in letzter Zeit ein wenig beschäftigt hat.

Für den Zugriff auf die Datenbank habe ich eine kleine API zusammengestellt. Vorsichtshalber überprüfe ich in den Funktionen alle Parameter auf ihre Gülltigkeit. Zuerst werden ja die Benutzereingaben geprüft. Damit wird die API gefüttert, wo die Daten nochmals geprüft werden. In der API werden die Rückgabewerte der Systemfunktionen geprüft und das DBS schaut auch noch nach, ob die Werte denn in die Felder passen. Ist das zuviel des Guten? Oder reicht zum Beispiel die Erkennung eines Fehlers beim DBS, wenn ein Wert nicht Null sein darf?

Besten Dank und Peace

Tom2

PS: Für Links zu ähnlich guten Artikeln, wie dem Feature-Artikel von Achim Schrepfer (http://aktuell.de.selfhtml.org/artikel/programmiertechnik/wiederverwendung/index.htm), rund um das Thema Programmiertechnik wäre ich sehr dankbar.

[Alexander Foken]

Moin Moin !

Ist das zuviel des Guten? Oder reicht zum Beispiel die Erkennung eines Fehlers beim DBS, wenn ein Wert nicht Null sein darf?

Das sieht zwar aus wie eine Ja/Nein-Frage, ist aber keine.

Wenn es vor allem auf Sicherheit ankommt, kann man kaum paranoid genug sein. Eine Library-Funktion, die Werte ungeprüft übernimmt, würde ich schon als Sabotage ansehen -- es sei denn, in der Beschreibung der Library-Funktion steht exakt drin, daß man vorher selbst überprüfen muß, was man an Werten übergibt.

Wenn es vor allem auf Geschwindigkeit ankommt: Grob überprüfen, ob die Eingaben ungefährlich sind, dann rein ins System und abwarten, ob es knallt. Wenn es knallt, Fehler ausgeben.

Es gibt zum Verhältnis Hauptprogramm und Library in der Perl-Doku (perlmodlib) zwei sehr schöne Absätze, besonders der zweite trifft auf Dein Problem zu:

Perl does not enforce private and public parts of its modules as you may have been used to in other languages like C++, Ada, or Modula-17. Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun.

The module and its user have a contract, part of which is common law, and part of which is "written". Part of the common law contract is that a module doesn't pollute any namespace it wasn't asked to. The written contract for the module (A.K.A. documentation) may make other provisions. But then you know when you use RedefineTheWorld that you're redefining the world and willing to take the consequences.

Alexander

[Danny]

Hi,

was guten, sauberen und effektiven Code ausmacht, ist teilweise Geschmackssache.

Wenn es hauptsächlich auf Performance ankommt, z.B. wg. hoher Serverbelastung oder bei Spielen, dann ist man natürlich bemüht, kurzen, extrem optimierten Code zu schreiben.

Allgem. sollte das Ziel jedoch nicht unbedingt _kurzer_ sondern möglichst leicht verständlicher, anpassbarer Code sein. Generell würde ich sagen:

• Aufgabe in kleine Einzelprobleme, bzw. Klassen/Funktionen aufteilen
• allgem. Modular programmieren, d.h. mehrfach benötigte Codefragmente in Funktionen auslagern
• wichtige und komplexe Stellen mit Kommentaren versehen, möglichst aussagekräftig
• evtl. im späteren Verlauf variable Stellen nicht hardverdrahten, sondern über Argumente an Funktionen übergeben.
• Code durchgängig einrücken

Gruß,
Danny

[Cheatah]

Hi,

Was macht für euch guten, sauberen, effektiven PHP Code aus?

dass er in Python geschrieben ist.

Cheatah, SCNR ;-)