Dieser Artikel ist keine Sammlung von Vorschriften, sondern eine Zusammenstellung von Informationen und Empfehlungen für die Anwendungsentwicklung mit PHP. Insbesondere bei der Arbeit im Team sollte die Berücksichtigung der Regeln nicht zum Schaden des Programmierers sein.
Selbst im Zeitalter der Hochsprachen und der ausgeklügelten Analyseverfahren folgt immer noch eine Vielzahl von Entwicklern dem Motto: „Man hat immer die Zeit, alles zweimal zu machen, aber es fehlt immer die Zeit, es von Anfang an richtig zu machen“. Allerdings führt das Prinzip allzu oft in die Sackgasse. Wesentlich sinnvoller und effizienter ist folgendes Motto: „Erst analysieren und strukturieren, anschließend coden und abschließend testen“.
Coderegeln – Sinn und Zweck
Zunächst ein paar Worte zum Sinn und Zweck von Coderegeln: Die Einhaltung von Coderegeln beziehungsweise Konventionen stellt einen wesentlichen Bestandteil umfangreicher Projektarbeiten dar. Darüber hinaus existieren jedoch auch andere nicht ganz unwesentliche Faktoren wie zum Beispiel:
- übersichtlicher Code
- funktionierender Code
- Komponenten und Komponententests
- einfache Wartung des Codes
- Code, der leicht zu erweitern ist
- Wiederverwendbarkeit des Codes
- Unterstützung von Refactoring
Sämtliche Coderegeln, die im Folgenden vorgestellt werden, sollen dabei behilflich sein, die aufgeführten Punkte zu erfüllen. Durch die Einhaltung der Regeln wird es Teammitgliedern oder Urlaubsvertretungen ermöglicht, den Code zu begreifen und zum Beispiel Bug-Fixes vorzunehmen oder Komponenten eines anderen zu verwenden, ohne zeitaufwendig eigene Lösungen erarbeiten zu müssen.
Um diese Ziele zu erreichen, sollte der Code einer Anwendung:
- leicht zu lesen
- leicht verständlich
- gut dokumentiert
- frei von typischen Fehlern
- durch verschiedene Entwickler wartbar sein. Im Idealfall wäre ein Kunde in der Lage, die Komponenten der Anwendung zu verstehen und weiterzuverwenden.
Das Ziel von leicht verständlichem Quellcode ist erreicht, wenn jedes Teammitglied jede Komponente erklären kann. Nicht zuletzt soll jede Arbeit am Projekt, dem Code und der Dokumentation motivieren. Je höher der Frustfaktor ist, je unübersichtlicher Strukturen und Code sind, desto größer ist die Wahrscheinlichkeit, dass die Arbeit keinen motiviert. Solch eine Situation gilt es auf jeden Fall zu verhindern.
RSS-Feed
Twitter