Domino 9 und frühere Versionen > ND6: Entwicklung

Konkatenation von Variablennamen

<< < (2/5) > >>

Gandhi:
Also Option Declare sollte meiner Meinung nach defaultmässig eingeschaltet sein - nicht mal wegen Stilfragen, sondern weil es mich vor unglaublich vielen Tippfehlern und endlosem Debuggen bewahrt.
Über die andere Sache lässt sich streiten. Ich setze das wie gesagt auch Situationsbezogen ein - und Konstanten für Feldnamen benutze ich sehr selten - da ich die irgendwie per se als fix betrachte.
Aber auch hier gilt, dass ich das tun werde, sobald es für mich Sinn macht.
Aber es gibt schon ganz schöne Unterschiede zum Stil:
Während viele inzwischen fast ausschliesslich objektorientiert Script schreiben - hat mein aktueller Vorgänger noch nicht mal (kaum) Funktionen oder gar Bibliotheken benutzt.
Dafür ist der Code dann wild über die DB verteilt - und ich wurde zum Suchenden...

Glombi:
Die Extended Class Syntax zu verwenden ist meiner Meinung nach kein schlechter Stil. Solche Aussagen sollten vorsichtiger formuliert werden, ansonsten schmeisst nachher der Auftraggeber dir den Code um die Ohren.

Die Extended Class Syntax hat aber auch Nachteile gegenüber ReplaceItemValue:
1. Die Performance ist wesentlich schlechter, da der Compiler erst nach der Property/Methode sucht und dann - nachdem er keine gefunden hat - das als Abkürzung für ReplaceItemValue erkennt.
2. Aus 1 ergibt sich dann sofort das Problem: Wenn es DOCH eine Property gibt, so führt das zu Fehlern. Das ist bspw. der Fall, wenn in einer neuen Notes-Version eine neue Property hinzukommt.
Akutelles Beispiel (wurde auch hier im Forum behandelt): Lock

ein doc.Lock = "1" funktioniert dann eben nicht mehr.
Und sowas kann mit ReplaceItemValue nicht passieren.

Andreas

flaite:

--- Zitat von: Glombi am 28.10.05 - 07:49:16 ---
Die Extended Class Syntax hat aber auch Nachteile gegenüber ReplaceItemValue:
1. Die Performance ist wesentlich schlechter, da der Compiler erst nach der Property/Methode sucht und dann - nachdem er keine gefunden hat - das als Abkürzung für ReplaceItemValue erkennt.

--- Ende Zitat ---
Das ist in vielen Kontexten eben auch egal. In vielen Fällen wird keiner die eingesparte Zeit merken.
In 7 haben wir ja eine Profiling Klasse. Damit bekommt man für einen konkreten Kontext konkrete Aussagen über die Zeit, die für die einzelnen Funktionen benötigt wird. Betrachtet man Performance vom Standpunkt der merkbaren Auswirkungen beim User (und alles andere macht keinen Sinn), dann sind solche Argumente eben mehr so metaphysisch.


--- Zitat ---2. Aus 1 ergibt sich dann sofort das Problem: Wenn es DOCH eine Property gibt, so führt das zu Fehlern. Das ist bspw. der Fall, wenn in einer neuen Notes-Version eine neue Property hinzukommt.
Akutelles Beispiel (wurde auch hier im Forum behandelt): Lock
ein doc.Lock = "1" funktioniert dann eben nicht mehr.
Und sowas kann mit ReplaceItemValue nicht passieren.

--- Ende Zitat ---
Das ist ein Argument. Mit einem vernünftigen Test-Prozess bei einem upgrade auf die neue Version, in der das implementiert ist, sind die Kosten möglicherweise nicht besonders hoch.

Was ich nur sagen will ist, dass man an einer Menge Stellen aus verschiedenen Gesichtspunkten (Latenz, Skallierbarkeit, Wartbarkeit, etc. ) optimaleren Code schreiben kann. Wir machen es nur nicht, weil man eben nicht alles berücksichtigen kann. Und zwar keiner. Man kann nun 5 einfache Gesetze für "optimalen Code" aufstellen und das als "perfekten code" deklarieren. Die Regeln lassen aber bestimmt 120 Aspekte ausser acht. Ich bin sicherlich nicht gegen gute Programmierpraktiken. Will nur sagen, dass dies oft sehr komplex ist. Und das Ergebnis hinsichtlich einer totalen Betrachtung nie optimal ist.
Eine Architektur-, Design- oder Programmierentscheidung ist letztlich das Ergebnis einer Kosten-Nutzen Rechnung von denen ex ante die wirklichen Kosten und Nutzen nicht kennt.

Ein bischen wie die Theory of the second best in Wipol. In einem Markt mit Störungen führt eine Maßnahme die eine von mehreren Störungen beseitigt zu besseren, genau gleichen oder schlechteren Ergebnissen  ;D
http://internationalecon.com/v1.0/ch100/100c030.html

Axel 

Tode:
Würde jetzt möglicherweise jemand auf die Ursprüngliche Frage eingehen ?

Der Arme Kerl hat noch keine Antwort erhalten.

In LS funktioniert das concat. so:

Dim x(9) as String
For i = 1 to 10
  feldName = "D" & Cstr( i )
  x(i-1) = doc.GetItemValue( feldName )(0)
next

Das concat funktioniert aber nur mit Dokument- Feldern, für Variablennamen gibt es sowas nicht, da würde man das aber auch nicht so lösen, sondern entweder mit einem Array (x im obigen Beispiel) oder aber mit einer Liste.

HTH
Tode

m3:
Tode: Die erste Antwort (meine) auf sein Posting enthielt bereits diese Antwort.  >:(

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete