Nicht tun, bitte: Nummer 1) Nicht kommentieren

Man sollte es nicht glauben, aber das ist noch immer die häufigste und schlimmste Sünde. Schon bei der Eigenentwicklung von Komponenten, noch schlimmer bei der Anpassung von Standardkomponenten. Da könnte Lagnese glatt ein achtes Todsündeneis erfinden.

Grundsätzlich gilt bei der Anpassung von Standardkomponenten: Es wird kein Code gelöscht, sondern nur auskommentiert. Jedes eingefügte Codesegment wird als solches gekennzeichnet.

Oben im Kopf des Programmskriptes wird unterhalb der Standardkommentare angegeben, dass man eine Änderung vorgenommen hat, wann das war, was man gemacht hat, und warum. Für diese Änderung wird ein bestimmtes Kürzel angeben, mit dem die Änderungen im Programmskript gekennzeichnet sind. Für die nächste Änderung (sei es, aufgrund neuer Anforderungen, oder weil man zwei Tage später noch einen Fehler gefunden hat, wird ein neuer Kommentar im Kopf eröffnet und ein neues Kürzel vergeben.

Wie diese Kürzel auszusehen haben, dafür hat sich leider noch keine Konvention durchgesetzt. Infor nutzt hier Solution- oder Businessrequestnummern. Hat die eigene EDV ein ähnliches Prinzip, dass jede Softwareänderung in Bezug auf einen Eintrag in einem Change-Managementsystem stehen muss, kann man es ähnlich halten. Vorausgesetzt, man kann da tatsächlich mehrere Nummern generieren, wenn man mehrfach wegen einer Anforderung eine Source ändert. Ich persönlich bevorzuge es, für diesen Zweck meine Initialen und eine dreistellige Zählnummer zu nutzen (also: UF001, UF002, UF003 etc.) Nicht sehr praktikabel dagegen finde ich die Methode, mit Initialien und Datum zu arbeiten (UF080813), das wird zu lang, und bei zwei Änderungen an einem Tag hat man ein Problem.

Wofür es aber eine Konvention gibt, ist die Art, wie man dieses Kürzel zum Markieren seiner Änderungen im Skript benutzt. Diese Konvention wurde seinerzeit unter Baan eingeführt, wird bis heute zur Markierung von Änderungen aufgrund Solutions genutzt und sollte eigentlich allgemeiner Standard sein. Leider halten sich nicht alle dran, darum hier mal in aller Ausführlichkeit: Gesetzt den Fall, wir haben für unsere Änderung das Kürzel UF001 definiert. Dann kennzeichnet:

• UF001.o eine herausgelöschte, (das heißt auskommentierte!) Proogrammzeile. Das o steht für "out".
• UF001.n eine neue Programmzeile. Ein n für "new" also
• UF001.so den Beginn einer größeren Anzahl von Zeilen, die man herausgenommen hat (so für "start out")
• UF001.eo das Ende eines solchen Blocks (end out)
• UF001.sn den Beginn einer größeren Anzahl von Zeilen, die man eingefügt hat (sn für "start new")
• UF001.en das Ende eines solchen Blocks (end out)

Als Faustregel gilt, dass mehr als zwei eingefügte oder gelöschte Zeilen mit so/eo und sn/en markiert werden. Unlesbar werden Programme, wenn jede einzelne neue Codezeile mit einem solchen Marker versehen wird.

Möchte man also in folgendem Code...

|*
|* This would be the last part of the Infor standard comment
|* section on top of the script
|*
|*************************************************************

...
   select  tcibd001.*
   from    tcibd001
   where   tcibd001._index1 inrange {:item.f} and {:item.t}
   and     tcibd001.csel >= {:csel.f}
   and     tcibd001.csel <= {:csel.t}
   and     tcibd001.citg >= {:citg.f}
   and     tcibd001.citg <= {:citg.t}
   order   by tcibd001._index1
   selectdo
           call.a.funny.method (tcibd001.item)
   endselect

die Selektion ändern und den Funktionaufruf durch einen andere Funktion ersetzen, so modifiziert man das bestehende Programm wie folgt:

|*
|* This would be the last part of the Infor standard comment
|* section on top of the script
|*

|*************************************************************
|*
|* UF001 - 2008-08-13,
|* Ulrich Fuchs, Büro für Informationsarchitekturen, mail@ulrich-fuchs.de
|*             * Zusätzliche Artikelselektion statt über Selektionscode
|*               und Artikelgruppe über Signalcode
|*             * eine andere Lustige Funktion gerufen
|*
|*************************************************************

...
    select  tcibd001.*
    from    tcibd001
    where   tcibd001._index1 inrange {:item.f} and {:item.t}
|UF001.so
|      and     tcibd001.csel >= {:csel.f}
|      and     tcibd001.csel <= {:csel.t}
|      and     tcibd001.citg >= {:citg.f}
|      and     tcibd001.citg <= {:citg.t}
|UF001.so
|UF001.sn
       and     tcibd001.csig >= {:csig.f}
    and     tcibd001.csig <= {:csig.t}
|UF001.en
       order   by tcibd001._index1
    selectdo
|                call.a.funny.method (tcibd001.item)                  | UF001.o
                 call.another.funny.method (tcibd001.item)            | UF001.n
        endselect

Keinesfalls aber sollte man also geänderte Zeilen finden, bei denen weder klar ist, was vorher da stand, noch was geändert wurde. Mancher Programmierer und dito manche -in greift in obiger Situation schon mal zu

...
    selectdo
              call.another.funny.method (tcibd001.item)  | UF001
       endselect

Das ist böse, gemein, unwartbar. Nicht tun, bitte.