Standard bei der Scriptprogrammierung

[eknori]

@all

wenn ich mich so in der Notes Community umschaue, fällt mir immer wieder auf, das alle Woche ums neue das Rad neu erfunden wird. Wieder eine neue ReplaceSubstring Routine in LS, der 150. @Word Ersatz und, und und...

Mein Vorschlag:

Lasst uns unser Wissen konsolidieren und generische Routinen in einer ( oder mehreren ) Script Bibliotheken zusammenfassen.
Die Routinen sollten vor der freigabe unter allen möglichen Situationen und Konstellationen getestet werden. Erst nach diesen test werden die Funktionen freigegeben. Könnte so ein OpenSource Project werden.

Dann hätten wir einen Pool von Funktionen, auf den man zurückgreifen kann.

Was mir so vorschwebt ist eine Lib, in der die Variablen standardisiert sind um eine einheitliche Codestruktur zu erhalten. Die Funktionen können zu Klassen zusammengefasst werden.

Was sagt ihr dazu ??

euer eknori

[cpo]

Hi Eknori,

eine prima Idee!
Frage ist nur, wo? und wer?...

Ich habe in unserer Firma grad' angefangen, die überall verstreuten Funktionen zu sammeln, zu testen und zu kategorisieren - eine Mordsarbeit  

Außerdem müßte man sich vorher auf eine einheitliche Variablendeklaration einigen. Wir haben jetzt nach zähem Ringen endlich eine, die sogar irgendeinem standard folgt...

Das war aber echte Überzeugungsarbeit, alle Entwickler dazu zu kriegen, "workspace" und nicht "w" zu dimen, ein Adressdokument mit docPers statt mit Persdoc zu benennen und alle Variablen mit StrLastname oder Intcounter...
Wenn das interessiert oder nützlich ist, kann ich's aber gerne zur Verfügung bzw. Diskussion ( ) stellen.
CPO

[eknori]

Das sind ja schon gute Ansätze; wenn du da schon etwas formuleirt hast, würde mich eine Kopie interessieren.  

[Axel]

Hi Ulrich,

eine super Idee  

Ich bin gerne bereit hier Unterstützung zu leisten. Ich hab einiges aus Internet-Foren gesammelt, unter anderem auch einige Script-Routinen.

In unserer Firma bin ich Einzelkämpfer, was die Programmierung angeht. Ich hab mit sowas wie einen Quasi-Standard angeeignet, den ich versuche durch alle Neuentwicklungen zu halten.

In der Woche nach Ostern bin ich im Urlaub, aber danach kann ich helfen.

Ein schönes Osterfest.
Axel

[grosses.manitu]

Abend,

bevor ihr alle das Rad neu erfindet. Guckt doch einmal folgenden Vorschlag an:
http://www.eview.com/eview/viewr5.nsf/e640f630a3361f84852568f600070fd3/c441fbabe59d2de285256a55007c9555?OpenDocument&Highlight=2,standard

Die haben da einen Vorschlag der noch recht empfehlenswert ist. Wird bei uns eingesetzt und ist nicht das schlechteste. Ist zum Teil vielleicht gar etwas tief.

[Axel]

bevor ihr alle das Rad neu erfindet. Guckt doch einmal folgenden Vorschlag an:
http://www.eview.com/eview/viewr5.nsf/e640f630a3361f84852568f600070fd3/c 441fbabe59d2de285256a55007c9555?OpenDocument&Highlight=2,standard

Hi,

ich habe mir die, hinter dem Link liegendes DB angeschaut. Hier geht es nur um die Benennung von Variablen. Das ist natürlich hier auch ein Thema. Es geht aber auch darum, immer wieder gebrauchte Funktionen, Klassen etc. zusammenzutragen und zur Verfügung zustellen.

Axel

[M_Messer]

hi an alle.

also ich muß sagen, dass das eine sehr gute idee ist.  das kann uns wirklich nur weiterhelfen. ich wäre dafür und würde euch auch so gut wie möglich unterstützen.
gruß
messer

[DominoAndy]

Hi,

absolut prima Idee !!!  

Zwar bin auch ich bei mir in der Firma ein Einzelkämpfer bei der Domino-Entwicklung, trotzdem versuche ich natürlich gewisse Standards einzuhalten - leider gibt es die ja nicht gerade üppig.

Dieses Forum scheint mir daher genau richtig, solche Dinge in einer Gruppe festzulegen.

Bin deshalb gerne Bereit mit dazubeizutragen.

Viele Grüße
Andy

[eknori]

Hallo zusammen,

dann sollten wir mal anfangen. Ich hatte mir überlegt, daß wir mit Routinen zur Stringmanipulation anfangen sollten. Also

ReplaceSubstring
@Word
@Left, Right etc

Ich denke, dafür sollte der Mai ausreichen.
Würde mich freuen, wenn ihr mir geeignete Routinen ( entweder selbst gestrickte, oder aus dem Web ) zuschickt.

@cpo: du hatte gepostet, daß du da bereits einen Standard bei den Deklarationen hast. Kannst du den mal posten, bitte ??

Auch könnten wir noch Idden gebrauchen, WAS eigentlich so gebraucht wird.


eknori

[DominoAndy]

Hallo,

Anfangen...klingt gut !!!

Also meiner Ansicht nach sollten wir tatsächlich erst mit einer gemeinsamen Namenskonvention zur Variablendeklaration beginnen, da dies ja quasi die Basis für alles weitere wäre. Im zweiten Stepp fände ich noch gut, die Benennung für Ansichten, Masken, Feldern etc. zu definieren.

Zu den benötigten Routingen kann ich Dir erstmal nur zustimmen, mit den Stringoperationen zu beginnen.

Andy

[eknori]

OK,

wie wollen wir denn die Variablen deklarieren. Sollen wir uns auch hier erst einmal auf eine Reihe von "reservierten Wörtern" verständigen. Ich meine, daß die Buchstaben i, k,l etc bei integer var verwendet werden ist ja eigentlich schon klar.

Dachtest du evtl auch daran, der Variablen den Typ voranzustellen ?

String str_VarName
integer int_VarName
double dbl_VarName
Variant var_VarName

dennächst (r6) auch
Byte byt_VarName

Konstanten grundsätzlich in GROSSSCHRIFT

auch die Art der Konstante:

MSG_DIES_IST_EIN_HINWEIS
ERR_DIES_IST_EIN_FEHLER

USR_DIENT _DER_CONFIG_DURCH_DEN_USER
(z.b. dem User bleibt es überlassen, welches TMP_DIR er verwendet)

wobei auch hier durch einen Prefix ( STR, INT, DBL ) impliziert werden kann, was in der CONST steht

bei Ansichten , Masken, Subforms etc schlage ich vor, einen Prefix zu verwenden, der es ermöglicht, diese Designelement in jede Datenbank ohne Konflikt mit schon bestehenden Elementen einzufügen.

eknori

[DominoAndy]

Hallo Eknori,

bist wohl auch ein WE-Arbeiter ?! ;-)

Was meinst Du jetzt mit "reservierten Wörter", bzw. mit den Buchstaben "i, k, l" ? "i" für Integer würde ich ja verstehen aber die anderen beiden ?

Hier erstmal meine Vorschläge...

Variablen

Ich würde auf alle Fälle den Typ voranstellen, da man ja für eine Sache in einem Skript durchaus Variablen mit unterschiedlichen Typen verwenden kann.
Bei der Fehlersuche würde dies zur Erleichterung beitragen.

Würde somit Deinen Beispielen wie "str_VarName" zustimmen, wobei ich jetzt
auf die Unterstriche verzichtet hätte. Aber das ist natürlich zweitrangig.

Konstanten

Hier stimme ich Dir 100%ig zu. Durch die GROSSE_SCHRIFT sind hier auch die Unterstriche sehr hilfreich.

Ansichten/Masken/Subforms

Derzeit verwende ich folgende Prefixe:
Masken - frm
Teilmasken - sfrm
Ansichten - zugegebener Maßen noch keines
Seiten - pa


Andy

[eknori]

Öh, eigentlich bin ich ein rudU- arbeiter ( rund um  die Uhr)

die underscores bei den Variablen waren nur zur Verdeutlichung aber auf den Wechsel von GrossUndKleinSchreibung ( Wechsel bei Wortwechsel )innrehalb des VariablenNamen möchte ich nicht verzichten.

Underscore und GROSSSCHREIBUNG_BEI_VAR sollte sein.( underscore bei Wortwechsel )

Prefix für View könnte v sein; embedded view "ve"
Odrner "f" und privater Ordner "fp"; Ordner bei erster Nutzung privat : "ffp"

eknori

[M_Messer]

hi

also ich muß sagen, dass ich eure vorschläge sehr gut finde.

variablen:

da ich noch ein azubi bin, kann ich euch sagen, dass wir in der schule gelernt haben, die variablen so zu deklarieren, wie ihr es vorgeschlagen habt.

str_VarName

mit den anderen deklarationen bin ich auch voll mit einverstanden.

bekommen wir dann unsere eigene rubrik unter entwicklung oder wo werden wir unser wissen posten

gruß messer

[Axel]

Hi,

eure Vorschläge finde ich soweit ganz gut. Hier noch ein paar Vorschläge.

Bei der Benennung von Masken verwende ich im Aliasnamen immer 'frm...', bei den Teilmasken stelle ich 'tm' voran. Bei Masken, die nur als Dialog aufgerufen werden stelle ich 'dlg' davor.

Bei Ansichten hatte ich bisher immer 'vw' verwendet.

Bei der Benennung von Variablen habe ich bisher keinen Unterstrich benutzt. Der Unterstrich ist mir irgendwie unsympathisch (ist aber eine persönliche Meinung). Sonst habe ich damit begonnen meine Variablen, wie oben beschrieben, zu bezeichnen.

Wie sieht das Ganze bei der Bezeichnung von Feldern aus ?
Hier habe ich bisher auf die Typangabe im Feldnamen verzichtet (wegen Angabe des Feldnamens bei Volltextsuche). Lediglich bei Feldern, die ich zur Steuerung brauche und die versteckt sind habe der Bezeichnung ein 'x' vorangestellt. Bei Feldern aus einem Konfigurationsdokument könnte man mit 'cfg' beginnen lassen.

Als Idee:
Wie wärs noch mit ein paar Klassen, z.B. ProgressBar. Ich hab noch eine für Word und eine für Excel. Da bin ich gerade dabei diese zu überarbeiten.

Axel

[M_Messer]

ich deklariere felder wie folgt:

zwei buchstaben für die maske_feldname

beispiel:

RB_ErstDatum

RB = Rufbereitschaft
ErstDatum = Erstellungsdatum

[DominoAndy]

Hi,

also ich hab mich auch schon mit Richtlinien zur Feld-Deklaration rumgeschlagen. Allerdings konnte ich hierfür nichts praktikables herausfinden.

Ein Prefix für die Maske halte ich für etwas ungeschickt, da es sich bei "ähnlichen" Masken als umständlich erweist, z. B. Firma  + Person. Deshalb verwende ich für Felder einfach sprechende Namen und trenne druch GroßKleinSchreibung die einzelnen Wörter. Natürlich habe ich für häufig verwendete Felder feste Namen definiert wie "CreatedBy" , "CreatedDate" , usw...

Andy

[M_Messer]

ja, da hast du zwar recht, aber da ich in erster linie workflow´s programmiere und das nicht alleine, habe ich mir das so mit meiner kollegin geklärt, damit jeder gleich weiß, zu welcher maske welches feld gehört. das würde jetzt ein bißchen zu lange dauern, um das zu erklären.

hier ist diese deklarationsweise sehr ungeschickt. ich wollte nur mal ne info geben, wie das bei uns in der firma gemacht wird.

[eknori]

Kriegst auch ein Problem, wenn du gemeinsame Felder definierst, die dann in unterschiedlichen Masken verwendet werden.

Aber das mit den Deklarationen von Designelementen ist eigentlich eine andere Baustelle.
Hier geht es in erster Linie um die Zusammenstellung von Routinen, die eigentlich immer wieder gebraucht werden, jedesmal aber aufs Neue von jedem individuell erstellt werden.

@messer:

was die Veröffentlichung angeht, so sollten wir die Diskussion ruhig hier unter R5 Entwicklung führen.
Die Ergebnisse können wir dann in der Art einer Best Practice Datenbank als LN DB zum Download bereitstellen.

eine weitere Möglichkeit wäre Webspace auf freedominoserver.de. ( mit 10 MB ) sollten wir wohl auskommen. Da könnte man auch direkt replizieren ( glaube ich, habs noch nicht probiert )

eknori

[Axel]

Hi,

ich finde es auch etwas ungeschickt den Masennamen, oder eine Abkürzung davon, in den Feldnamen mit aufzunehmen.

Ich bezeichne die normalen Felder mit dem gleichen Namen, wie die Bezeichnung, die der User in der Maske angezeigt bekommt. Damit weiss der User, welches Feld er wählen muß, wenn er eine entsprechende Suche durchführt. Ich denke, dass werde ich auch beibehalten


Axel