Richtlinien beim Setzen von flags in LS?

[Demian]

so, ich mal wieder  

Nachdem ich es jetzt bei neuen DB's endlich schaffe (mir grauts vor den Anpassungen der bereits aktiven Datenbanken ), meine Felder, Variablen usw. komplett in Englisch und mehr oder weniger einheitlich zu benennen will ich mir langsam auch eine einheitliche Linie bei den Flag-Benennungen für Dokumente angewöhnen um diese zum Beispiel in den Dokumenteigenschaften auf den ersten Blick von echten Feldern unterscheiden zu können.

Hatte überlegt alle flags mit flag_ zu beginnen (z.B.: flag_deleted) ist aber irgendwie zu lang und auch von der Sortierung in den Dok-Eigenschaften her blöd. Mit einem Unterstrich, also (_deleted) kann ich mich auch nicht so wirklich anfreunden. Einerseits ist es kurz und die Sortierung in den Dok-Eigenschaften würde passen. Andererseits vergisst/übersieht man so ein _ auch mal schnell was das Texten angeht.  

Deswegen wollt ich mal so in die Runde fragen, ob bei irgendwem evtl. Vorgaben/Richtlinien diesbezüglich existieren? Gerne mit Beispiel

[Axel]

Richtlinien existieren bei uns nicht. Aber ich habe mir angewöhnt, alle Felder die ich in Datenbanken zum Steuern von Funktionen, Sichtbarkeit von Feldern, Flagfelder etc. benötige, mit x.... (z.B. xHide) zu benennen. Berechnete Felder die ich nur zur Anzeige benötige, benenne ich mit dsp....

Ansonsten versuche ich die Felder so zu benennen, dass durch den Namen zu erkennen ist welchen Inhalt sie haben. Bsp. Vorname für eine Feld welches Vornamen enthält. Das erleichtert den Usern die Suche nach bestimmten Feldinhalten über den Volltextindex.

Axel
 

[koehlerbv]

Hallo Demian,

die Frage kann man auch so stellen: Was ist eigentlich ein "Flag"? Flag" als Signal für "tu das / tue es nicht" kann ja auch auf Items basieren, die auch noch weitere Aufgaben erfüllen.

Ich schliesse mich Axel an - das Entscheidende ist der "sprechende Name" ist für die meisten (Programmierer und Administratoren) erheblich entscheidender als irgendwelche Konventionen wie "txt_xxx" für textfelder oder gar "fldXXX" (was für ein Blödsinn - ich sehe doch, dass das ein Feld bzw. im Backend ein Item ist! Und wenn ich schlechte Laune hätte, für ich dann fix eben mal bei ein paar Dokumenten einen Datums-/Zeitwert reinpumpen  ).

Auf User nehme ich allerdings bei der Benennung von Items keinerlei Rücksicht - die bekommen ihre eigene Suchroutine, und in der wird ihnen sowieso alles speziell aufbereitet geboten wird (Label in Maske gleich angeblicher Itemname, und das auch entsprechend konfigurierbar).

Bernhard

[Demian]

Berechnete Felder die ich nur zur Anzeige benötige, benenne ich mit dsp....

das mit dem dsp hab ich irgendwo schonmal gesehen. An sich auch ne schöne Lösung. Sollte ich mir dann auch mal angewöhnen.

Ansonsten versuche ich die Felder so zu benennen, dass durch den Namen zu erkennen ist welchen Inhalt sie haben

das mach ich grundsätzlich genauso, jetzt allerdings in Englisch. Wobei mir dann jetzt oft der Platz net reicht und dann gehts los...wie kürz ich das so ab, dass man immer noch weiß, was gemeint ist usw.

die Frage kann man auch so stellen: Was ist eigentlich ein "Flag"? Flag" als Signal für "tu das / tue es nicht" kann ja auch auf Items basieren, die auch noch weitere Aufgaben erfüllen.

So gesehen ja. Meine Interpretation für ein flag ist eigentlich genauso. Also quasi ein Statusfeld, allerdings für meine Begriffe "unsichtbar" für den Anwender, was ja bei den Items nicht gegeben ist.
 

erheblich entscheidender als irgendwelche Konventionen wie "txt_xxx" für textfelder oder gar "fldXXX"

Das kommt auch auf die Entwicklungsumgebung an. Unter Visual Studio 2005 mach ich das auch so. also modMain für das Modul Main. frmMenu für die Form Menu. Allerdings nur aus dem Grund, damit die im Designer schön nach Elementen sortiert sind. 

Auf User nehme ich allerdings bei der Benennung von Items keinerlei Rücksicht

durch die Umstellung auf Englisch habe ich da jetzt Probleme mit. Sprich beim Prüfen, ob ein Pflichtfeld ausgefüllt ist konnte ich vorher ne kleine Validierungs-Formel nehmen, die mir den Feldnamen zurück gegeben hat um diesen in einem Prompt zu verwenden.
Ja, jetzt kann ich für jedes Feld LS nehmen und ne Msgbox mit der deutschen Feldbezeichnung basteln Hatte da auch schon an Konfigurationsdocs gedacht, in denen der englische Feldname und die deutsche Feldbezeichnung festgehalten wird und per document.getbykey gezogen wird, das würde das Ganze scriptseitig erheblich verkürzen. Aber das wäre dann doch sehr pflegeintensiv und fehleranfällig meines Erachtens.

[koehlerbv]

Hallo Demian,

Also quasi ein Statusfeld, allerdings für meine Begriffe "unsichtbar" für den Anwender, was ja bei den Items nicht gegeben ist.

Items sieht der Anwender aus durch Nachraben im Backend, wenn er denn weiss, wie es geht, gerade nicht. Ein Feld wird im Frontend repräsentiert (und nur dort), das Item ist der Datencontainer (wiederum im Container namens Document) im Backend.

Das kommt auch auf die Entwicklungsumgebung an. Unter Visual Studio 2005 mach ich das auch so. also modMain für das Modul Main. frmMenu für die Form Menu. Allerdings nur aus dem Grund, damit die im Designer schön nach Elementen sortiert sind. 

Eben - es kommt auf die IDE an. Im Notes-Designer ist das eh schön sortiert (wenigstens eine Bequemlichkeit  )

durch die Umstellung auf Englisch habe ich da jetzt Probleme mit. Sprich beim Prüfen, ob ein Pflichtfeld ausgefüllt ist konnte ich vorher ne kleine Validierungs-Formel nehmen, die mir den Feldnamen zurück gegeben hat um diesen in einem Prompt zu verwenden.
Ja, jetzt kann ich für jedes Feld LS nehmen und ne Msgbox mit der deutschen Feldbezeichnung basteln Hatte da auch schon an Konfigurationsdocs gedacht, in denen der englische Feldname und die deutsche Feldbezeichnung festgehalten wird und per document.getbykey gezogen wird, das würde das Ganze scriptseitig erheblich verkürzen. Aber das wäre dann doch sehr pflegeintensiv und fehleranfällig meines Erachtens.

Auch das ist eine Betrachtungssache. Die einfachste Validierungs-Fehlermeldung wäre ein "Dieses Feld müssen Sie ausfüllen!". Da der Cursor eh ins das betreffende Feld hüpft, braucht man keinen Feldnamen mehr.
Aber: Auch der sprechendste Feldname muss nicht unbedingt eine passende Fehlermeldung abgeben. Häufig ist es ja auch so, dass spezifische Meldungen erforderlich sind: "Das Startdatum darf nicht nach dem Enddatum liegen!" oder "Sie können für die Bewertung keinen Wert grösser 100% angeben!".

Und den Pflegeaufwand für derartige Meldungen kann man schon ordentlich in den Griff bekommen, wenn dahinter ein sauberes Konzept steht.

Was den "Platz" für Feldnamen angeht: Mit 32 Zeichen kommt man eigentlich wirklich locker hin. Man muss ja nicht gleich die ganze Doku darin unterbingen 

Bernhard

[Demian]

das Item ist der Datencontainer (wiederum im Container namens Document) im Backend.

Ok, bei Item denk ich immer automatisch an sichtbare Felder in einer Maske.

wenn dahinter ein sauberes Konzept steht.

Ein weiteres Problem. Mir schwirrt immer viel durch den Kopf auch schon für Sachen, die erst viel später eine Rolle spiele, aber das auf Papier zu bringen klappt noch nicht so.

Was den "Platz" für Feldnamen angeht: Mit 32 Zeichen kommt man eigentlich wirklich locker hin. Man muss ja nicht gleich die ganze Doku darin unterbingen 

Nuja, in der Regel langt das schon bei mir aber ich habe auch Feldnamen die recht lang sind (siehe Screenshot - Luftlinien Mittelwert). Gut da wären noch ein paar Zeichen frei, aber es ist schon an der Grenze.

Gruß
Demian