Programmierrichtlinien

Allgemeine Arbeitsweise:

1. Zu jeder Prozedur, Funktion, Objekt und Klasse sind Header, die die Funktionalität beschreiben, anzufertigen.

Bsp.:
/*Programm: final-end.net
*Description: in diesem Objekt werden alle Daten zum User zugreifbar und änderbar gemacht, jede Eigenschaft
*(Useralter) ist somit im Programm verfügbar.
*Author: Max Mustermann
*Datum: 01.01.2013
*E-Mail: M.Mustermann@final-end.de
*/

Die Dokumentation des Quellcodes sollte kurz und prägnant gehalten sein.

Bsp.: if ($User->getAlter() > 18 ) $Status = „erwachsen“ //Useralter prüfen und Status festlegen

2. Bei jeder Änderung an Prozeduren oder Funktionen eine Beschreibung am Header hinzufügen

Bsp.:

// änderung: Max Mustermann – Objekt um Variable x erweitert

3.Grundsätzlich werden keine Umlaute verwendet. ö => oe , ä => ae, ü => ue

schreibt einfach in der Englischen Sprache euren Programmcode und ihr werdet feststellen das ich keinerlei Probleme mit umlauten haben werdet 🙂

4. Namensgebung:

Bsp.:

  • Variablenname: UserVorname (Höckerschreibweise)
  • Konstanten: KONSTANTEN_NAME
  • Formular: frm_Map_UserData (frm_Modul_Beschreibung) bei kleineren Projekt kann das Modul auch weggelassen werden aber Vorsicht! jedes Projekt fängt einmal klein an
  • DB-Tabelle: tbl_User
  • Steuerelement: tb_Map_UserData_SureName>
  • Funktionen: openFrmMapUserData() (Höckerschreibweise)

 

Hierbei ist die Höckerschreibweise genauso, wie der Aufbau der Bezeichnungen als Grundlage zu betrachten. Die Namensgebung ist so zu wählen, dass der Name eine Aussage zur Funktionalität und zum Einsatzort gibt.

Konstantennamen werden immer groß geschrieben und durch „_“ (Underline) getrennt.

 

Die Benennung von Funktionen erfolgt mittels Höckerschreibweise und muss beschreibende Attribute im Namen beinhalten.

Bsp.: calculateMapUnitPosition() // der Name der Funktion muss den sinn und den Zweck ihres selbst wieder geben. Ich habe in meiner mehrjährigen Tätigkeit als Entwickler schon sehr viel gesehen und kann aus Erfahrung sagen funktion a() – z() die nur einen Buchstaben haben sind ja gut und schön aber niemand wird nach einem halben Jahr noch wissen was diese Fkt. tun. Haltet euch an den Leitspruch „Keep It Simple“. Gerade bei diesem Thema komme ich nicht umhin die Autocomplet Funktion der Meisten IDE’s (Integrated development environment) anzusprechen
. wenn Ihr zum Beispiel ein Eclipse oder Visuallstudio benutzt versucht doch mal STRG + Leertaste. mit dem Richtigen Codingstyle und dieser Funktion werdet ihr die Programmierung im neuen Maße kennenlernen.

5 Datenbank:

Eine Sehr wichtige Konvention ist es die Datenbank sauber und übersichtlich zu halten. Viele werden jetzt bestimmt Abbnicken und sagen jetzt Übertreibt er es aber ganz schön, ich sage nein tut er nicht. Stellt euch eine Datenbank mit knapp 200 Tabellen vor, Dazu noch ein paar Hundert Views und las uns sagen noch ein paar hundert Trigger und Stored Procedures und schon seit ihr ohne Codingstyle am Rande der HÖLLE angekommen. Bitte immer im Hinterkopf behalten das die nachkommenden Konventionen dazu dienen die Datenbank aufzulockern und übersichtlicher zu gestalten. Ja mir ist bewusst das es mehr Arbeit ist kleine Buchstaben an die Datenbanken, Tabellen, und einzelnen Spalten zu schreiben, diese helfen aber nach im laufe des Projektes Zeit einzusparen.

Kommen wir dazu wie wir Ordnung in die Datenbank bekommen.

Datenbank

(db) db_FinalEnd // der Name der Datenbank
Solltest du später in deinem Projekt mehrere Datenbanken mit dem selben Namen brauchen nimm einfach

(db) db_FinalEnd1 // der Name der Datenbank
(db)db_FinalEnd2 // der Name der Datenbank

Tabellen

(tbl) tbl_Modul_Inhalt

Bsp.: tbl_Global_User // hier mit Angabe des Modules

tbl_User // dies wäre sich Tabelle für die User

tbl_UserAttribut // wäre Sozusagen die M zu N Beziehungtabelle

alternativ könnte man hier auch schreiben

tbl_AttributUser // das Äquivalent zu tbl_UserAttribut

Es ist kein muss den Modul Namen mit in den Tabellennamen mit aufzuführen. Stellt aber bitte sicher das wenn ihr einmal mit einer Richtlinie begonnen habt diese im Projekt auch konsequent Durchzieht.

View’s

(v) v_UserAttribut

Trigger und Stored Procedures

Ich fasse Diesen Punkt zusammen da ich der Meinung bin: „bitte benutzt Trigger und Stored Procedures“ nur wenn ihr und bedingt müsst“. Ein Grund Stored Procedures zu benutzen wäre der Performance Gewinn gegenüber normalen SQL bzw. einem ORM. Das es keinen Sinn macht Große Datenmengen aus der Datenbank zu laden diese zu verarbeiten und wieder in die Datenbank abzulegen. Also wenn ihr Zeitkritische Prozeduren unter großem Datenaufwand entwickeln müsst nehmt Stored Procedures es gibt keine besser lösung. Aber seit euch bewusst das ihr zwangsläufig Anwendungslogik innerhalb der Datenbank abbildet und ihr zum Schluss an 2 punkten im system Bugfixing betreiben müsst sollte es zu Fehlern im Programm kommen. So komme ich zu fragen wie Debuggt man einen Stored Procedures ^^. Falls Ihr unit Testing im Einsatz habt baut ihr euch noch ein Testsystem für die Datenbank? Noch ein Negativbeispiel für Übertriebenes Datenbank Funktionalität. Stellt euch ein System vor in dem fast 60% der Anwendungslogik in der Datenbank Liegt. so zum beispiel auch die Fkt. insertUser(Name,PassHash, …. Macht eine Solche Funktion Sinn. Zum einen kann man in einer solchen Datenbank fkt. die Prüfung der eingaben tätigen und im Fehlerfall eine exception werfen. Zum andern würde das ein Normales SQl insert Statement auch tun, Das Problem dabei ist, sollte sich etwas am user ändern, ändert man an 2 stellen in der DB + an der st elle im Programm selbst. Ich würde in einem Solchen fall raten benutz doch einen der Zahlreichen ORM’S z.b. Linq, oder Hibernate und fackelt die Komplette Fehlerbehandlung in der Applikation ab.

Sind Trigger Gut oder Böse, ich sage beides. In den Richtigen Händen sind Trigger eine sehr gute Erfindung. Falls jetzt irgend jemand auf die Idee kommt seine 50 Tabellen Datenbank mit 1000 Triggern so zu optimieren das sie alles von alleine macht tut es nicht. Trigger steigern die komplezität eurer Datenbankprojekte ins unermessliche. Stellt euch vor ihr fügt einen neuen User in die Datenbank und zusätzlich werden in 5 weiteren Tabellen Daten für den User voll automatisch vorbereitet. Sowas ist Voll cool da muss ich jedem rechtgeben bis auf wenn sich was ändert. Mir ist durchaus bewusst das man mit einer Guten Projektplanung die Datenbank so aufbauen kann das Änderung die Ausnahme sind. Ausnahmen bestätigen die Regel. Zu mal es ist garnicht so einfach ist nachzuvollziehen wann ein Trigger abgearbeitet wird und was er getan hat. So kommen wir wieder zu dem Problem eines Bug’s, ist der Fehler nun in der Datenbank aufgetretten oder im Programmcode. Ich würde empfehlen nutzt Trigger behutsam um die Datenbank sauber zu halten. bedenken lost könnt ihr trigger einsetzen um zum beispiel im Fall das ein User aus der Db entfernt wird zusätzliche Userdaten aus der DB zu entfernen.

Spalten

Datentyp_Beschreibung

Bsp.: s_Name // gibt an das in der Spalte Name ein string hinterlegt ist

Datentypen:

  • i Integer
  • s String (bis 50 Zeichen)
  • d DateTime
  • t Text (Feld in den XML eingefügt werden kann)
  • f Float, Double
  • b Boolean
  • dz Decimal (6,2)

so ergeben Sich z.B. folgende Konstrukte

db_FinalEnd

tbl_User

i_Id, s_Name, s_PassHash, d_Registerdate, d_Lastogin,t_Description,b_IsPremium ……

Der Vorteil habt ihr wenn ihr einen ORM im Programm benutzt im normalfalls erzeug ihr euer DB Objekt ich machen das jetzt kurz in PHP mit dem Kohana Orm

$User=ORM::factory(„User“, 1); // ich Lade mir den User mit der Id 1 aus der db

$User->s_name=“Matthias“; // es wird im Porgrammcode sofort ersichtlich es muss ein string sein

$User->d_Registerdate=time(); // es wird im Porgrammcode sofort ersichtlich hier muss ein datum rein in diesem beispiel ein timestamp

$User->save();

6 Steuerelemente

Steuerelement _Template_Beschreibung

RadioButton (rb) – rb _Praesentation_UserRank

Label (lbl) – lbl _UserData_SureName

Button (btn) – btn _Income_Calculate

CheckBox (cb) – cb _UserData_HasPremium

ListBox (lb) – lb _UserData_Id

TextBox (tb) – tb _UserData_Description

ComboBox (cob) – cob _UserData_Titel

GroupBox (gb) – gb _UserData_Example

DateTimePicker (dtp) – dtp _UserData_BirthDate

DataGridView (dgv) – dgv_UserData_Survey

 

7 Schleifen:

für Zählschleifen werden Grundsätzlich Zählvariablen genommen:

Zähler = i, 2. = j, 3. =k und 4. Zähler = m

8. Arbeitsweise:

  1. Header erstellen
  2. Einhalten der Namenskonvention (ordentliche Wahl des Namens)
  3. Einhalten der Ordnerstruktur
  4. Zerlegen der Funktion in kleinst mögliche Schritte

9. Ordnerstruktur:

Ein Programm kann wie Folgt aufgebaut.

Der Ordner „System „ stellt den Stammordner der Software dar.

In Ihm wird die Unterteilung nach vorgenommen.

    1. Class
      1. DatabaseObjects // classen des ORMs
      2. Objects // Praogramm spezifische klasse
      3. Controler oder Logic // die Controler schicht + Programm logic
      4. Database // der Datenbank Connector falls eine datenbank im system benutzt werden soll
    2. Cfg // der Platz für die Configurationsdatein
    3. Img // der Platz für deine Bild Ressourcen
    4. Js // eventuelle javascripts
    5. CSS // der platz für deine Css datein
    6. Plugins // falls es möglich ist für dein Programm plugins zu erstellen oder du plugins von 3 anbierten benutzt die kommen hier rein
    7. View // alle Templates die erstellt werden kommen in den View ordner unr nirgends wo anders

Das sind meine vorstellungen von einem Codingstyle.

Natürlich ist das nur vorlagen die man nicht zwingend benutzen muss aber jeder der wschon einmal in einem größeren Katastrophen Programm mitgearbeitet hat weis was es bedeuten einen Codingstyle zu haben.

Vielen Dank fürs lesen

 

3 thoughts on “Programmierrichtlinien

  1. KingCrunch sagt:

    Mir würde sicher noch mehr auffallen, aber echte Kritik gibts eigentlich nicht 😀

    Eine Sache bloß, weil es einfach verbreitet genug ist: Für die Schleifen (Punkt 7) werden in der Regel nicht „einfach nur“ irgendwelche Zählvariablen verwendet, sondern ursprünglich sind sie der Mathematik entliehen. Das heißt „i“ („j“, „k“) steht für „Index“ und stehen für die Index-Nummer in einem Feld (array). „n“ („m“, „l“) steht für „Nummer“ und steht das „wievielte Element“ (meist „Index+1“). „k“ (oder nochmal „l“) steht für „key“ und bezeichnet den Key in einer Map/einem Dictionary („assoziatives Array“).
    Von der Semantik her sind sie unterschiedlich und das hilft den Zweck besser zu erfassen

    – Mehr als 3 verschiedene sind nie notwendig, denn verschiedene werden nur gebraucht, wenn Schleifen geschachtelt werden. Wenn mehr als 3 Schleifen geschachtelt werden, sollte man refactoren 😉
    – Passt keiner der Begriffe so richtig, oder bleibt es trotzdem etwas ungenau (zB wenn man verschiedene Indeces meinen könnte) sollte man trotzdem die Variable wieder ausschreiben

    Was anderes zu Punkt 9: Offenbar liegen im selben Ordner, in dem auch Ordner mit Code-Dateien liegen die Ordner für CSS und JS. Da letztere von Aussen erreichbar sein müssen, müssen sie im Document-Root liegen, was dann aber auch für die Ordner mit den Code-Dateien gilt. Das ist immer etwas riskant 😉 Besser ist es ein „web“, „public“ oder „html“ einzusetzen, der dann als Document Root fungiert und in der sich bis auf die Bootstrap-Datei keine weitere Datei mit Code befindet.

  2. Michael sagt:

    Hi,

    Ich richte mich zu 90% nach PSR 1/2. Aber hier gibt es ja zog Meinungen. Einzige Kritik, die ich beim schnellen drüberscrollen habe: warum im Header erwähnen wer wann was geändert hat? Gibt es dafür nicht das VCS und für sich sprechende Committmessages? Außerdem sehr praktisch: annotate in PHPStorm, falls man einen Verantwortlichen sucht 😀

    1. ReMaker sagt:

      Hi Michael,

      es ist richtig das es CVS und SVN’s oder git und unzählige andere Tools gibt. Das Problem warum man Änderungen in den Header schreiben sollte ist eigentlich das man nicht immer in die Logdatei, des jeweiligen Programms, sieht. Stell dir doch einfach vor die arbeitest mit 10 anderen Programmierern an einer Software und musst eine Stelle „Provisorisch“ Bug-fixen, weil wieder mal sofort ein Update raus muss 😉 . Ich finde es immer eine gute Idee das der ursprüngliche Programmierer die Info im Quellcode bekommt das da genau an diesem Part ein anderer Programmierer gearbeitet hat. Vielleicht ist ja durch diesen Bugfix an anderer stelle was kaputt gegangen, durch fehlende Unit Test noch nicht entdeckt, oder der Bugfix ist absolut verbesserungswürdig. Das sind meine Intention warum ich für mich sage ich schreibe diese Information in den Header wenn ich größere Projekte angehe.

      Gruß Matthias

Comments are closed.