Guter Programmier Stil

[Monty Burns]

hi
mal ne allgemeine frage
kennt jemand ein paar tutorials oder so, in denen ein guter programmierstil vermittelt wird, am besten für php

danke für die antworten

Monty Burns

[Christoph Schnauß]

hallo ;-)

kennt jemand ein paar tutorials oder so, in denen ein guter programmierstil vermittelt wird, am besten für php

am besten liest du dir alle Threads hier im Forum und im Forums-Archiv durch, in denen es um "Design" und "Seitenbeurteilung" geht. Da kriegst du es nicht apodiktisch als: "so muß es sein", sondern diskursiv als: "vielleicht wirkts so besser" mit.
Meines Erachtens ist "Stil" nichts, wofür man extra-Tutorials braucht, es sei denn, du verwechselst "Stil" mit "sauberer Programmierung". Wenn du wissen möchtest, ob du ordentlich programmiert hast, gibts den Validator; aber eine valide Seite kann durchaus stillos sein.

Grüße aus Berlin

Christoph S.

[Sven Rautenberg]

MoiN!

kennt jemand ein paar tutorials oder so, in denen ein guter programmierstil vermittelt wird, am besten für php

Kennen tu ich keine, aber Google kennt wohl welche: "programming style" oder "programmieren mit stil" brachten Suchergebnisse.

Das Problem wird sein, daß die besten Texte nur in englisch verfügbar sind. Aber wenngleich du nicht unbedingt ein Tutorial für PHP findest, ist eine Richtlinie für Java, C++ oder Perl genauso hilfreich, weil es in erster Linie um Grundprinzipien geht, wie man Code lesbar und möglicherweise selbstdokumentierend gestaltet.

Wo ich gerade dabeibin:

Das Mini-Tutorial des guten Programmierstils, Version 0.1

Prinzip Nummer 1: Einrücken!
Nur wenn auf den ersten Blick sichtbar wird, welche Anweisungen alle z.B. in Schleifen und IF-Abfragen enthalten sind, behält man die Übersicht. Und es hilft ganz entschieden, Fehler zu vermeiden und gemachte Fehler schneller zu finden.

Prinzip Nummer 2: "Sprechende" Variablen- und Funktionsnamen benutzen.
Niemandem ist damit gedient, wenn eine Variable "blabla" oder eine Funktion "mach_es" heißt. Üblicherweise ist es sehr sinnvoll, den Variablennamen so zu wählen, daß die Bedeutung des enthaltenen Wertes klar wird, auch wenn das Tipparbeit bedeutet. Schlau ist es z.B., das Ergebnis einer Datenbankabfrage im Array "abfrageergebnis" abzulegen, und die Variable für den Dateinamen des Newstickertextes "tickerfilename" zu nennen. Ganz lokal begrenzte Allerweltsvariablen wie die für eine unbedeutende Schleife dürfen gerne auch kurz "i" und "j" heißen, das sind übliche Bezeichnungen für irgendeine Laufvariable. Deutsche oder englische Namen? Geschmackssache. Englisch paßt meist besser zu den englischen Befehlen, aber deutsch ist möglicherweise erklärender für den Programmierer. Aber Vorsicht: Keine Umlaute!

Prinzip Nummer 3: Kommentare!
Guter Code erklärt sich zwar selbst, aber es hat noch niemals geschadet, am Anfang einer Funktionsdefinition die Bedeutung der zu übergebenden Parameter zu erklären oder bei wichtigen Vorgängen kurz zu erläutern, was das geniale an der verwendeten Programmierung ist, bzw. was für Gedankengänge dabei gegangen wurden. So muß derjenige, der später den Code liest, nicht mühsam nachvollziehen, was da gemacht wurde, sondern kriegt gleich am Anfang die Informationen und kann so leichter verstehen, was da los ist. Bloß nicht jede Zeile kommentieren, das verdoppelt unnötig die Arbeit, sondern an den wichtigen Stellen.

Soweit das Mini-Tutorial des guten Programmierstils.

PS: Das gilt sowohl für PHP, als auch für Javascript und HTML! Wobei HTML natürlich keine Funktionen und Variablen kennt, aber es gehört eingerückt und durchaus auch kommentiert!

- Sven Rautenberg

[Klaus Mock]

Hallo,

Ich erlaube mir etwas zu ergänzen.

Das Mini-Tutorial des guten Programmierstils, Version 0.1

Prinzip Nummer 1: Einrücken!
Prinzip Nummer 2: "Sprechende" Variablen- und Funktionsnamen
Prinzip Nummer 3: Kommentare!

Prinzip Nummer 4: Keine Monsterfunktionen

Vermeide das Schreiben von Funktionen, die elendslang sind. Besser ist es, solche Funktionen so zu zerlegen, daß mehrere kleinere, überschaubare Funktionen rauskommen. In 'Zusammenarbeit' mit Prinzip 2, ergibt das dann auch sehr gut lesbaren Code. Auch wenn ein Programmteil nur einmal ausgeführt wird, ist es sinnvoll, diesen in eine Funktion zu verpacken, um den Code verständlicher zu machen.

Grüße
  Klaus

[Achim Schrepfer]

Hi,

ich hab auch noch einen:

Prinzip Nummer 1: Einrücken!
Prinzip Nummer 2: "Sprechende" Variablen- und Funktionsnamen
Prinzip Nummer 3: Kommentare!
Prinzip Nummer 4: Keine Monsterfunktionen

Prinzip Nummer 5: Sei faul!
Es lohnt sich fast immer, seinen Code modular zu schreiben. D.h. Funktionen in Gruppen zusammengefasst in Module (oder wie das halt bei der jeweiligen Sprache heisst) zu packen. Häufig hat ein Programmierer ein bestimmtes Aufgabengebiet (z.B. der Webprogrammierung) als Schwerpunkt. Wenn alle wiederkehrenden Funktionen und Funktionsgruppen sauber in Modulen ausgelagert werden, hat er die Möglichkeit, diesen Code ständig zu verbessern und kann ggf. sogar ältere Projekte damit updaten (z.B. wg. Sicherheit). Das bedeutet zwar am Anfang (beim Entwurf des Codes) etwas mehr Aufwang, weil abstrakter gedacht werden muss, unterm Strich lohnt es sich aber sowohl zeitlich als auch qualitativ.

Prinzip Nummer 6: Sei konsequent (nur für Berufsprogger)!
Wenn Du einen Funktionsentwurf gemacht hast, dann ziehe ihn auch durch. Häufig verfällt man beim programmieren der Versuchung, dieser und jener Funktion "noch den letzten Schliff" zu verpassen und entwickelt mehr Features, als es der Projektplan je vorgesehen hat. Das kann sowohl zu Inkonsistenzen im Projekt, als auch zu wesentlich höheren Kosten führen. Bei privaten Projekte, ist das natürlich genau anders rum, weil man sich da ja austoben will und (fast) alles einbaut, wass einem so einfällt ;-)

Viele Grüsse
Achim

[Andrea]

Hey,

und auch ich möchte noch ein kleines und bescheidenes Prinzip zufügen:

Prinzip 7:

Gewöhn Dir eine gewisse Konsequenz in Deiner Einrückung (Prinzip 1) an, d.h. wenn Du eine Funktion optisch nach einen bestimmten Prinzip eingerückt hast (Anzahl der Leezeichen, Umbrüche, Klammerungen etc.), behalte dieses Prinzip zumindest im selben Script bei, einfacher für Dich, halte das Prinzip generell bei.

Ciao
Andrea

[Achim Schrepfer]

Hi,

und nochwas *g*:

Prinzip 7:

Prinzip 7.1:
diese Konsequentheit (heisst das so?) solltest Du generell beibehalten. Also auch bei der Vergabe von Variablennamen (z.B. fooBar und foo_bar nicht mischen), Vergabe von Funktionsnamen etc.

Viele Grüsse
Achim

[Christian Kruse]

Hoi,

diese Konsequentheit (heisst das so?)

Nein! Konsequenz, bitte! ;-)

Gruesse,
 CK

[lulu]

Huhu Monty

ich persönlich fand den Artikel (Linux Kernel Coding Style) sehr gut und prägnant.
Eine von zahlreichen Quellen

http://www.csa.iisc.ernet.in/Documentation/Tutorials/c-style-guide.html

Dann hätte ich vielleicht auch noch ein Prinzip (Nummer 8 oder 9?)

Alle Funktionen in eine externe Datei auslagern. Im eigentlichen Programm sollte so wenig wie möglich stehen. Wenn man dann "sprechende" Funktionsnamen gewählt hat kann man das auch ohne Programmierkenntnisse lesen.

Ein kleines z.B.

<?php
/*
* Example: Das Programm tut dieses und jenes
*/

// INCLUDES
include('./my_example.ini.php'); # initial values
include('./my_example.lib.php'); # functions

// VARIABLES
$template_to_use='example.tpl';

// MAIN
$values=get_values_from_db();
$page=insert_values_in_template($values,$template_to_use);
print_page($page);
?>

Viele Grüße
lulu