Welche schreibweise ist besser , mit oder ohne Variablen

[rocksoft]

Hallo,

ich habe hier ein Bsp, a und b, mich würde interessieren ob b) nachteile bringt gegenüber von a)
oder ist es Jacke wie Hose, nur das a) schlecht lesbar ist?

a)

Code:

procedure Tform.BtnOkClick(Sender: TObject);
begin
functionmachdies(table1.FieldValues['Text1'],table1.FieldValues['Text2'],table1.FieldValues['Text2'])
end;

b)

Code:

procedure Tform.BtnOkClick(Sender: TObject);
var
a,b,c:Sting;
begin
a:=table1.FieldValues['Text1'];
b:=table1.FieldValues['Text2'];
c:=table1.FieldValues['Text3'];
functionmachdies(a,b,c)
end;

Danke für die Antwort

@Sharky :Done

[Sharky]

Hai rocksoft,

gebe deinem Thread doch bitte einen etwas aussagekräftigen Titel. Bei der Gelegenheit kannst Du auch gleich die Delphi-Tags verwenden um deinen Quellcode zu formatieren. Danke :-D

[MrKnogge]

theoretisch isses Jacke wie Hose, ich weis nur nicht, in wie weit der DelphiCompiler dies optimiert, variante b ist bestimmt, und vor allem für Anfänger, übersichtlicher gegenüber a.

Aber a müsste schneller/effektiver sein. (wenn der Compiler es nicht optimiert)

[rocksoft]

Hallo MrKnogge,

danke für deine meinung, wenn es dann Jacke wie Hose ist, werde ich dann eher die version B benutzen, da nach mehreren table1.FieldValues.. ist es nicht mehr schön zu lesen, ich habe aber noch eine frage, was pasiert dann mit den Variablen? Die sind dann noch im speicher? wenn ja verbrauchen die ja resourcen, oder werden die dann frei gegeben?

[nieurig]

Da die Variablen lokal definiert sind werden sie verworfen sobald die Methode beendet ist also kein Ressourcenverbrauch aber RessourcenGEbrauch. Wenn das Programm sowieso schon viel Speicher benötigt, würde dies noch ein klein wenig mehr sein während die Methode abgearbeitet wird. Meist ist dies aber egal.

Niels

[Pseudemys Nelsoni]

wenn der text sowieso von anfang an klar ist (siehe beispiel a) dann solltest du bei beispiel B lieber Konstanten statt Variablen benutzen...

[nailor]

aber ich glaube, dass der compiler da eh nochmal dran rumoptimiert. müsste man mal benchmarken, indem man es 100.000 aufruft.

[MrKnogge]

Zitat:

Zitat von nailor

aber ich glaube, dass der compiler da eh nochmal dran rumoptimiert.

Genau das würd mich mal interessieren, mich würde fast wundern wenn er dies nicht tun würde, er wandelt soweit möglich j auch beispielsweise "for to"-Schleifen in "for downto"-Schleifn um.

[Chewie]

Zitat:

Zitat von nailor

aber ich glaube, dass der compiler da eh nochmal dran rumoptimiert. müsste man mal benchmarken, indem man es 100.000 aufruft.

Nun ja, in dem Fall wäre ein Blick in den erzeugten Assembler-Code sinnvoller ;)
Es dürfte, wenn überhaupt, nicht viel ausmachen. Es muss zunächst eine Funktion aufgerufen werden, die etwas zurückliefert, und das 3 mal. Erstens dürfte das Bereitstellen der Übergabeparameter für die eigene Funktion im Vergleich zur Funktionsausführung (FieldValues) kaum Zeit in Anspruch nehmen, zweitens gibt es sowieso nicht genügend freie Register, um alles darin zu speichern und drittens wird für den String sowieso nur ein Zeiger übergeben. Die Funktion liest dann die Daten über diesen Zeiger aus dem Speicher.

[negaH]

Besser ist es die Feld Komponenten zur Laufzeit zur Table anzulegen. Die bringt mehr Performance, ist stimmiger zum OOP Konzept, Tpysicherer und für Anfäger besser zu verstehen. Der Source sähe dann so aus:

Delphi-Quellcode:

begin 
  MachDies(Table1Text1.AsString, Table1Text2.AsString, Table1Text2.AsString);
end;

Gruß Hagen

[nailor]

Zitat:

Zitat von negaH

Besser ist es die Feld Komponenten zur Laufzeit zur Table anzulegen. Die bringt mehr Performance, ist stimmiger zum OOP Konzept, Tpysicherer und für Anfäger besser zu verstehen. Der Source sähe dann so aus:[...]

*möööp*

[rocksoft]

Vielen Dank für die ganzen antworten, aus den 2 möglichkeiten sind es jetzt 5 geworden.

- a)
- b)
- c) mit konstanten
- d) MachDies(Table1Text1.AsString, Table1Text2.AsString, Table1Text2.AsString);
- e) *möööp*

meine meinung die beste (für mich) ist die variante c), b) und d) ist gleich nur die schreibweise ein wenig anderes, und bei e) die muss echt gut sein nur leider bekomme ich nur errors :)

also Danke für die Hilfe

[StefanDP]

Von deinem ersten post kannst du ja auch schreiben: (reine optik sache)

Delphi-Quellcode:

procedure Tform.BtnOkClick(Sender: TObject); 
begin 
functionmachdies(table1.FieldValues['Text1'],
                 table1.FieldValues['Text2'],
                 table1.FieldValues['Text2']) 
end;

und schon ist es so übersichtlich wie b) von deinem ersten post

[rocksoft]

Hallo StefanDP,

mensch was ein paar Tabs ausmachen:), ja so ist es wirklich schön zu lesen.

Danke

[negaH]

Zitat:

b) und d) ist gleich nur die schreibweise ein wenig anderes

Nein eben nicht. Alle Methoden sind gleich bis auf d.)
Während alle Methoden langsam, dynamisch und fehlerträchtig sind ist die methode d.) über zur Designzeit angelegte Field-Komponenten übersichtlich, wesentlich schneller, typsicher und universeller.

Angenommen wir möchten ein DBGrid nutzen und ein Fließkomma Datenbankfeld extra formatieren und eine extra Konvertierung der Eingaben durchführen. Man legt dann zum DateSet alle Feldkomponenten an. Innerhalb dieser Feldkomponenten besteht nun die Möglichkeit über .DisplayFormat den Inhalt den Datenbankfeldes im DBGrid zu formatieren. Nun möchte man noch zusätzliche Konvertierungen berücksichtgen was ganz einfach über die Ereignisse der Fieldkomponente möglich ist. Dies geht ALLES nicht wenn man wie oben dynamisch auf die Felder einer DB zugreift, bzw. es ist sinnlos dynamisch auf die Felder zuzugreifen wenn man schon Field Komponenten angelegt hat.
Zb. eine Tabelle enthält 50 Datenbankfelder. Wenn man wie oben dynamisch darauf zugreift so muß die DB-VCL per Stringvergleiche im Durchschnitt 25 Strings vergleichen -> nämlich die Feldnamen des gesuchten Feldes mit den Feldnamen in der DB. Im obigen Falle wären also ca. 75 Stringsvergleiche bei 50 Datenfeldern nötig. Legt man aber zur Designzeit Feldkomponenten an und greift über .AsString zur Laufzeit auf deren Inhalte zu so stellt dies ein DIREKT Zugriff dar, also ohne Feldnamen's -Vergleichen.

Somit unterscheidet sich mein Vorschlag von allen anderen gravierend. Er ist NICHT die beste Lösung für dein Problem mit einer besseren Source-Formatierung, sondern er stellt DIE beste Lösung im gesammten dar, wenn man mit DataSets + Fields arbeiten will.


Gruß Hagen

[choose]

Ich stimme Hagen zu, sofern der Code wiederholt und die Entwicklung durch die IDE (zum durch den Formulardesigner) unterstützt wird. Sollten die Referenzen selbstständig angelegt werden müssen (zB weil die Feldbezeichnungen erst zur Laufzeit bekannt sind) und sollte der Code nur einmal ausgeführt werden, ist der zusätzliche Aufwand für die Verarbeitung wohl ungerechtfertigt.

Für diesen Fall schlage ich eine Variante der von StefanDP gezeigten Lösung vor

Delphi-Quellcode:

procedure Tform.BtnOkClick(Sender: TObject);
begin
  with Table1 do
    FunctionMachDies(FieldValues[Field0], FieldValues[Field1], FieldValues[Field2]);
end;

wobei Field0, Field1, Field2 Variablen oder Konstanten sind.