Es gab bei Foxite eine wesentlich emotionalere Diskussion darüber. Sachlich tut sich da aber nix. Und auch wenn viele hoch und heilig schwören immer nur mit mdots zu arbeiten sehe ich kaum Code, der das durchzieht.
Das Feldnamen Vorrang vor Variablen gleichen Namens haben hat ja seine Brisanz, das ist vielen an der Diskussion darüber das wesentlichere. Das Problem damit auf m. zu verzichten ist, daß Dir eines Tages irgendwann ein Seiteneffekt zwicken
kann, weil eben gerade ein Alias selektiert ist, der ein gleichnamiges Feld hat. Vielleicht sogar bewußt, weil SCATTER mit MEMVAR Option genutzt wird. Das ist für mich obsolet und mache ich nie. Kann einem natürlich trotzdem passieren, auch
z.B. durch Einsatz Codes dritter.
Wenn es allein um die Geschwindigkeit geht, müßte man auch STORE xTO var statt var = x schreiben, in einer Schleife sehe ich da 7% Laufzeitunterschied:
x=0
t1= Seconds()
For I = 1 to 10000000
Store 1 to x && vs x=1
EndFor
Ich finde x=1 wesentlich besser lesbar.
Die Nutzung von m. ist sicherer gegenüber Seiteneffekteinflussen, außerdem hat es den Vorteil von Intelllisense im Befehlsfenster inkl. Wertinspektion. In einem Editor nur mit Erweiterung, ich nutze aber lieber ZLOC und das schreibt Variablennamen
dann ohne m. Präfix in den Code. Könnte man ändern, Ich finde es dennoch unlesbarer und inkonsequent. Man könnte sich angewöhnen SELECT 0 vor Schleifen zu nutzen, die in Variablen und nicht Feldern arbeiten, oftmals hat man aber eh
einen Alias selektiert, ist leider keine Allgemeingültige Lösung.
Unsere Bugtracking Software sagt aus, daß ich etwa 0,00..% auf solche Fehler Zeit verwandt habe, ich sehe es ungefähr so sinnvoll an, wie einen Teebeutel beim Müllrecycling in seine Bio, Metall, Papier und Stoffbestandteile aufzutrennen.
Auch als Sicherheitslücke, wo man Fehler induzieren könnte, indem man Code einen bestimmten Alias unterschiebt, sehe ich als weitaus komplizierter und kaum ausnutzbare Sicherheitslücke, da habe ich mehr Ärger mit Powerusern, die DBFs unbedingt
mit Access oder gar Excel öffnen wollen und evtl. kaputtspielen.
Der Aspekt des Geschwindigkeitsvorteils kommt selten zum Tragen. Es müssen schon enge große Schleifen sein, wo also der Variablenzugriff einen entscheidenden Anteil am Scheifenkörper hat. Dazu gehört, wie im Wiki u.a. erwähnt neben
Schleifenstrukturen im Code auch SQL, richtig, denn auch SQL ist eine Schleife über mehrere Tabelleninhalte. Optimierungspotenzial ist da meist aber mit Indizes schon wesentlicher als per mdots.
Mir ist schon ständig bewußt, daß gleichnamige Felder Vorrang vor Variablennamen haben. Solange ich definierte Schnittstellen zu Daten oder eigene Datenbanken nutze, und ich habe nichts anderes an Daten zu pflegen, solange habe ich die Vermeidung
von Überlappungen davon im Griff. Wenn Feldnamen wie heutzutage typisch ohne Prä- oder Suffix sind und auch Variable, dann muß man da mehr aufpassen. Wenn jeder Feldname aber keine Variablenname einen Unterstrich hat, hat man das Problem schon
sehr weit aus dem Bereich des wahrscheinlichen geschoben. Und das ist etwas, was tatsächlich schon so war, bevor ich von dem Überlapp wußte.
Aktuell arbeite ich auch mit Datenbanken mit der Namenskonvention sehr wenier Suffixe und im allgemeinen normale englische Wörter für Felder zu nutzen, um die Codelesbarkeit zu verbessern. Bei Variablen halte ich mich an die VFP Namenskonventionen.
Die efahr ist damit immer noch relativ gering.
Es gibt wesentlich wichtigere Grundsätze, an die man sich halten sollte, wie z.B. nie ZAP ohne IN Aliasname, immer mit Aliasnamen Arbeiten und nicht mit Arbeitsbereichsnummern. Nie Einbuchstabige Variablennamen oder aliase innerhalb SQL, um nur zwei
Dinge zu nennen, die ich als wertvollere Grundsätze erachte.
Tschüß, Olaf.
