Clean Code

Aus SAP-Wiki
Zur Navigation springenZur Suche springen

Siehe ABAP.

Siehe Kategorie:Clean Code.

Clean Code ist ein sehr wichtiger Begriff in der Programmierung.

Als professioneller Entwickler reicht es nicht nur funktional korrekten Code zu schreiben. Ein Programm, was produktiv bei einem Kunden läuft, wird meistens im Laufe der Zeit einige male überarbeitet. Je wartbarer ein Code ist, umso einfacher, kostengünstiger und schneller ist es dieses Programm zu ändern. Die maximale Wartbarkeit eines Codes streben die Richtlinien vom Clean Code an.

github: SAP Clean Code

Warum Clean Code?

  • Clean Code ist einfacher und scheller zu verstehen und zu warten für den Programmautor und auch andere Programmierer.
  • Der Code ist einfacher und schneller zu debuggen
  • Der Pflegeaufwand und somit die Kosten sinken fürs Bugfixing und Programmerweiterungen
  • Es gibt weniger Bugs im Programmcoding und neue Funktionen werden schneller implementiert
  • Die Motivation und Zufriedenheit der Entwickler steigt, da man mit Clean Code einfacher und schneller zu Ergebnissen kommt und das Feedback der Anwender, Kollegen und Vorgesetzten besser wird.
  • Die Zufriedenheit der Anwender steigt, da die Programme weniger Fehler haben und sie ihre tägliche Arbeit einfacher und schneller erledigen können
  • Die Modularisierung von Quellcode in Methoden etc. minimiert Fehler und macht auch die Wiederverwendung dieses Quellcodes in anderen Programmen sehr viel einfacher.

Was gehört zum Clean Code

Fehlerbehandlung

  • Fehlerbehandlung
  • Würde man alles Coding weglassen, was mögliche Fehler (und Erfolgsmeldungen) in einem Code behandelt, dann würde der Code deutlich schlanker. Aber eine saubere Fehlermeldung macht ein Programm deutlich robuster gegenüber Ausnahmen, beschleunigt die Findung und Korrektur von Codingfehlern und informiert die Benutzer im Produktivbetrieb über eine Fehlerkonstellation.
  • Für eine sauber Fehlerbehandlung in einem Programm kann durchaus 1/3 der Entwicklungszeit benötigt werden, aber lohnt sich in fast allen Fällen.

Kommentare

  • Kommentare
  • Kommentarkopf mit
    • Ansprechpartner: Programmautor
    • Ansprechpartner: Berater und Tester
    • Die wichtigsten Entwicklungsobjekte
    • Beschreibung Sinn/Funktion vom Programm
    • Beschreibung Sinn/Funktion von Unterroutinen vom Programm
    • Änderungshistorie (Änderungsnummer, Autor, Datum, Ticket, Änderungskurzbeschreibung)
  • Kommentare über Funktionsblöcke
  • In Deutschland können Kommentare normalerweise auch in Deutsch erstellt werden, da gewöhnlich alle Entwickler auch Deutsch sprechen. Bei internationen Projekten, wo die Geschäftssprache Englisch ist, sollten die Kommentare dann aber auch in Englisch erstellt werden, da so die nicht deutschsprachigen Kollegen die Kommentare verstehen. Bei den deutschen Entwicklern kann man gewöhnlich von guten Englischkenntnissen ausgehen.
  • Änderungen im Programmcode nach Produktivsetzung sollten mit Entwicklerkürzel, Datum, Änderungsnummer und Änderungskurzbeschreibung an das Zeilenende oder über einen Funktionsblock geschrieben werden. Die Ändeurngen werden dann
  • Leerzeilen entsprechend der Funktionsblöcke
  • Es ist auch sinnvoll das Dokumentationsfenster in einem Transportauftrag zu nutzen, sofern der Transportauftrag (früher oder später) ins Produktiv transportiert wird.
    • Ticketnummer und Kurztext
    • Ansprechpartner: Entwickler
    • Ansprechpartner: Berater und Tester
    • Die wichtigsten Entwicklungsobjekte
    • Kurzbeschreibung vom Ticket/Entwicklung

Bündigkeit Code

  • Bündigkeit des Codes, sodass Variablen, Schlüsselbefehle entsprechend der Codinghierarchie untereinander stehen
  • Die Bündigkeit vom Code erleichtert das Verständnis zusammengehöriger Befehle

Nomenklatura

  • Nomenklatur
  • Variablen werden aussagekräftig benannt. Das kann sprechend sein oder entsprechend der verwendeten Feldnamen, Tabellennamen etc.
  • Programmnamen, Funktionsbausteine, Klassen, Methoden werden sprechend benannt

Programmvorlagen

  • Für manche Zwecke bietet sich die Nutzung von Codingvorlagen an, wie z. B. für ALV-Reporte.
  • Man spart so Zeit und minimiert Fehler. Man muss nur noch die Programmteile ändern, die für den Einzelfall individuell sind, wie z. B. bei ALV-Programm die SQL-Leseroutinen und die Definiton der Fieldcat-Felder für die ALV-Ausgabe.
  • Z. B. ALV-Vorlage REUSE ALV GRID DISPLAY LVC

Kapselung Unterroutinen (Delegation)

  • Bei der Vergabe von Aufgabe an Unterroutinen im Code spricht man von "Delegation"
  • Programmeinheiten
    • Klassen und Methoden
    • Form-Routinen
    • Funktionsbausteine
  • Die Unterroutinen sollen möglichst nur eine Aufgabe übernehmen
  • Wenn ein Fehler in dieser Aufgabe auftritt, ist der Fehler schnell lokalisiert und behebbar

Abkürzungen

  • Nur Abkürzungen verwenden, die allgemein, bzw. dem Team geläufig sind
  • Spezielle Abkürzungen ganz vermeiden oder mindestens 1 x ausschreiben

Web-Links

Literatur

Abgerufen von „https://www.berater-wiki.de/w/index.php?title=Clean_Code&oldid=33863“