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