4. Juli 2009 

Alles, was ich in 4D anfassen will, muß ich benennen. Fast stets schlägt 4D einen Namen vor: Eingabe und Ausgabe für Formulare, Methode123 oder Tabelle2 und Datenfeld1. Das könnte ich so lassen und 4D funktionierte prima. Nur zu bald weiß ich nicht mehr, was im Datenfeld10 der Tabelle Tabelle3 abgelegt wird. Also macht es Sinn, aussagekräftigere Namen als die vorgeschlagenen zu vergeben.

Namen vergeben

Ohne groß nachzudenken benenne ich meine Tabelle [Adressen] und die Felder Vorname, Name, Mann oder Frau bis alle Tabellen und Felder ihren Inhalt im Namen anzeigen. Das ist eine stimmige Namensvergabe.

So lange man mit der Benutzer-Umgebung auskommt und keine Methoden schreibt reicht das hin. Sobald jedoch Methoden geschrieben werden und die Anwendung in der Runtime-Umgebung laufen soll, wird es komplexer. Wer bereits programmiert hat, wird sein bewährtes Namensschema wiederverwenden und weiterentwickeln, alle anderen erfinden eines neu. Fast alle sind mit ihrer Namensvergabe ganz zufrieden, das ein oder andere vielleicht, sehen aber keine Möglichkeit wie oder haben sich an den Beispielen im Handbuch und den TechTips orientiert und … Die Diversität ist hoch. Inzwischen weiß ich: kein Namensschema ist ohne Nachteile noch erfüllt es alle Anforderungen. Ich nutze hier die Möglichkeit mein Namensschema zu formulieren, zu dokumentieren und zum Vergleich mit dem eigenen oder als Basis für ein zu entwickelndes anzubieten.

Nomenklatura

nach Regeln, die ich mir merken kann.

  1. Grundlegende Regeln

    • Keine Leerzeichen in Namen
      • so kann ein Doppelklick den Namen auswählen. Kein Shift-Klick, kein Doppelklick-Ziehen oder andere Umständlichkeiten behindern den Arbeitsfluß. Statt des Leerzeichens verwende auch ich den Underscore _. In zusammengesetzten Namen trennen Großbuchstaben mitten im Wort die Bestandteile, wie in MwSt.
    • Groß-und Kleinschreibung
      • für 4D macht das keinen Unterschied, mir jedoch hilft es beim Lesen.
    • Moden folgen, aus Fremdem lernen
      • sobald ich eine gute Idee entdecke, baue ich mein Namensschema aus
    • Ausnahmen
      • ich bin viel zu faul, nachträglich alte Benennungen an das aktuelle Schema anzupassen. Das mache ich nur, wenn ich einen Vorteil daraus ziehen kann
    • Kauderwelsch
      • In meinen Namen mische ich deutsch und english und rede rückwärts. Wie in den Menüs: Ablage öffnen, erst das Substantiv danach das Verb bzw. erst das Objekt dann die Aktion. Da ich selten laut vorlese, stört das Verdrehte nicht.
    • Eindeutigkeit
      • nie ein großes I oder ein kleines l. Kein großes O, denn die 0 läßt sich nicht umgehen.
    • Datentypen
      • Integer und String habe ich komplett eliminiert. Es gibt nur noch Longint und Text. Alpha ist nicht gleich String!
    • keine Umlaute
      • Ich sollte keine Umlaute verwenden. Wenn es drauf ankommt (SQL ist ein Kandidat) mache ich das auch. Ohne Umlaute liest sich bescheiden, warum sollte ich prophylaktisch darauf verzichten?

  2. Namen bestehen aus 3 Teilen

    • Objektart
      • Das ist der erste Teil des Namens, das Präfix. Für Felder ist das Präfix das Kürzel der Tabelle wie in ADR_Name fürs Namensfeld der Tabelle Adressen. Für Variablen verwende ich als Präfix die Art der Variable in 1-3 Buchstaben verkürzt wie in hl_ für hierarchische Liste.
    • Name
      • ich versuche einen möglichst sprechenden und eindeutigen Namen zu finden. Mein Beispiel oben Mann_oder_Frau ist sprechend aber nicht eindeutig. Besser ist ist_Frau weil es ein boolsches Feld benennt. Boolsche Werte nenne ich so, daß sie den Wahrwert beschreiben. Den Vergleich istFrau=True verstehe ich auch nach Jahren sofort.
    • Datentyp
      • den Datentyp kürze ich in einem Buchstaben ab und setze ihn ans Ende, das Postfix. Also: _b für Bool wie in istFrau_b, _L für Longint, _R für Real, _T für Text, _A21 für Alpha 21, _D für Datum, _P für Bild, _X für Blob … Dann merke ich gleich, das $mwSt_Satz_L:="0,19" Nonsens ist.

    Präfix und Postfix sind dann optional, wenn ich mit Gewalt eines erfinden müßte oder wenn es die Information aus dem Namen wiederholt.

  3. Anwendung

    • Tabellennamen immer in Großbuchstaben
      • ADRESSEN ist eine Tabelle und KORRESPONDENZ eine weitere. ADRESS_KORR ist die Tabelle, die Adressen und Korrespondenzen verknüpft.
    • Feldnamen bekommen als Präfix ein Kürzel des Tabellennamens
      • Alle Felder in ADRESSEN beginnen mit ADR_ wie in ADR_istFrau_b. Die Felder in KORRESPONDENZ mit KORR_ und die in ADRESS_KORR mit ADKORR_.
      In einer Datenbank wird es viele Felder geben, die Namen aufnehmen. Deshalb gibt es bei mir ADR_Name_A80 und ORG_Name_A80 neben ORG_BriefName_T und ORT_Name_A80 und LAND_Name_dtsch_A80, LAND_Name_engl_A80, LAND_Name_frz_A80 …
      Warum – der Tabellenname steht sowieso davor? Ja heute, in den aktuellen 4D Versionen. Außerdem gilt die Regel vom Präfix :-)
    • Methoden
      • Methoden beginnen mit einem Großbuchstaben und Funktionen mit einem Kleinbuchstaben, wie Print_Manager und mwst_Betrag. Dadurch fällt mir sofort auf, wenn mwst_Betrag nicht hinter einer Zuordnung := kommt. Dann stimmt was nicht. Ich habe schon überlegt, Funktionen müßten sinnigerweise mwst_Betrag_R heißen. Dann sähe ich sofort, daß aus $mwstBetrag_L:=mwst_Betrag_R nichts werden kann.
    • Variablen
      • Durch 4D vorgegeben sind die beiden Sonderzeichen $ für lokale Variablen und ◊ für Interprozeßvariablen. Nach $ und ◊ folgt die Benennung nach meiner Regel: Objektart_Name_Datentyp.
    • Formular-Objekte
      • Ich verwende mnemonische Abkürzungen für die Objektart. b_ für Button, cb_ für Checkbox, rb_ für Radiobutton, hl_ für hierarchische Liste, rk_ für Registerkarte, pm_ für Popupmenü und hpm_ für hierarchisches Popupmenü, …

  4. Sonderfälle

    • alte Lieben bleiben
      • $i und $N um die For($i;1;$N)-Schleife zu steuern. $i ist schon lange eine Longint und in verschachtelten Zählschleifen folgen $j, $k und $l, wie $M und … dann ist doch Schluß mit den alten Lieben. Aus $i wird $counter_ErsteEbene und $N wird zu $N_ersteEbene, eingeschachtelt werden $counter_ZweiteEbene und $N_zweiteEbene.
    • hierarchische Listen
      • schwierig zu meistern aber dann nicht mehr verzichtbar. Naheliegend wäre, diese Variablen durchgehend mit hl_ zu codieren. Verwende ich die hierarchische Liste als Popupmenü, kürze ich hpm_ ab und als Registerkarte mit rk_. So sehe ich auf einen Blick: hl_ viele Unterebenen, hpm_ nur eine Unterebene und rk_ keine Unterebene.
    • Formularnamen
      • inzwischen ist mir wichtig, daß jedes Formular einen eindeutigen Namen hat. Jedes Eingabe-Formular Eingabe zu nennen verhindert, es über einen Tastatur-Befehl öffnen zu können. Grundsätzlich über den Explorer ist mir unnötig umständlich.

  5. Objektnamen

    6. alle Objekte in einem Formular haben zusätzlich zum Variablen- oder Feldnamen noch einen Objektnamen. 4D vergibt die Objektnamen automatisch und sorgt für Eindeutigkeit im Formular. Um Listboxen anzusprechen sind Objektnamen das Mittel der Wahl. Alle anderen Objektnamen vereinfachen Manipulationen auf eine Gruppe wie mit dem Befehl SET VISIBLE(*;"NichtSichtbar_@";True).

    Auch hier wieder soweit es geht die Benennung in rückwärts-deutsch: zuerst das Umfassendere, danach das näher beschreibende und schließlich ein Anhängsel das eindeutig identifiziert. Als Beispiel "Person_Sichtbar_Text1" und "Person_Sichtbar_HierListe", dann klappt SET VISIBLE(*;"Person_@";False) und SET VISIBLE(*;"Person_Sichtbar_@";True).

    Ab V12/V13 sind Objektnamen ein Muß!

  6. Schriftbild

    7. Programmieren in schwarz/weiß kann ich mir gar nicht mehr vorstellen. Ohne fett und kursiv fehlt eine zusätzliche Unterscheidung. Deshalb verwende ich ungerne nicht-proportionale Schriften, weil die fett und kursiv nicht harmonisch rendern – proportionale können das viel besser.

    Für Parameter $1, $2, $0 habe ich als Farbe cyan, also himmelblau, eingestellt. Denn es soll sie nur im Kopf der Methode geben. Dort werden sie sofort sinnvoller benannten $Variablen übergeben. $wasTun:=$1, $P_Object:=$2, $record_L:=$3, …
    Parameter will ich weiter unten in der Methode nicht mehr sehen. Ausnahme: $0:=$return_L ganz am Ende, in der letzten Zeile.

    Hier auf DDDD.mettre.de verwende ich meine Farben, um 4D Programmcode darzustellen. Sie sind mir harmonischer als die Default-Farben.

  7. Beispiele

    • GET LISTBOX CELL POSITION (*;$lb_Obj_Name;$column_L;$row_L;$P_column)
      • $lb_ weil das Objekt auf dem Formular eine Listbox ist und ich deren Objektnamen in eine $Variable im Kopf der Methode übertragen habe. $column_L und $row_L ohne Präfix, weil sie keine Repräsentation in einem Formular-Objekt haben. $P_column bekommt einen Präfix, weil es die Objektart Pointer ist und das ist wichtig nicht zu übersehen. Aber kein Typ im Postfix, denn es ist ein Pointer und der kann auf jeden Datentyp zeigen.
    • GET LIST ITEM ($hl_list; $itemPos_L;$itemRef_L;$itemText;$sublist_L;$expanded_b)
      • $itemText kommt ohne _t aus, ich muß ja nicht päpstlicher sein und man kann es auch übertreiben.
    • WR GET STYLESHEET INFO ($wr_Area_L;$stilVorlage_L;$stilName;$anwendenAuf_L; $geschützt_L;$tastaturKürzel)
      • $wr_ ist eine 4D Write-Area, das ist wichtig zu wissen. Weil es $geschützt_L heißt, brauche ich nicht im Handbuch nachzusehen, ob das eine boolsche Variable ist.

  8. Brauche ich nicht oder nicht mehr

    • Modul-Präfixe
      • Meine Variablen leben nur in einer großen Methode, die Zusammengehörendes modulartig bündelt. Deshalb brauche ich Modul-Präfixe gar nicht.
    • Interprozeß-Variablen
      • sterben in meinen Anwendungen aus. Einer der Gründe ist das Organisieren in Schichten. Ein anderer, daß die eine große Methode intern regelt, wozu ich sonst Interprozeß-Variablen brauchte.
    • eigene Compiler_Methoden
      • sind unnötig, weil die Modularisierung in der einen großen Methode stattfindet. Das ist gut, denn so kann ich das Typisieren 4D überlassen und 4D macht das viel flotter als ich mit meiner Tipperei.

4D Themen: Berichte in Arbeit