Listboxen vergleichen

[Captnemo]

Zitat von sx2008:

Zitat von Captnemo:

Und was ist jetzt daran einfacher?

Man braucht nur eine Prozedur (getestet und wiederverwendbar) aufrufen anstatt unschönen Code einzubauen.
Mit "unschön" meine ich jetzt z.B. das fehlende BeginUpdate/EndUpdate.
Unschön ist natürlich auch keine Unter-Funktion/Prozedure zu verwenden.

Das kommt jetzt mal ein bischen darauf an, in welcher Form man das verwenden will.

Wenn ich tatsächlich nur aus einer Liste alle in einer zweiten Liste vorhanden Elemente löschen will,
dann reicht mir ja im Grund ein Zweizeiler.

Delphi-Quellcode:

  for i:=listbox1.items.count-1 downto 0 do
    if listbox2.items.indexof(listbox1.Items[i])>-1 then
       Listbox1.items.delete(i);

Gut, jetzt sind's 3 Zeilen

Diese jetzt doch relativ simple Aktion extra noch in eine Funktion zu packen, die dann wiederum
eine weitere StringListe benötigt, um dann am Ende das gleich zu erhalten, was hinterher in Listbox2 stehen sollte,
halte ich für unsinnig.
Zum einen wird der Code dadurch nicht unbedingt überichtlicher, und zum zweite muß ich hinterher dann auch noch die
Listbox2 neu aufbauen.
Außerdem kann ich so die auszuführenden Aktionen auch gleich mit in die Schliefe packen.

Die einzigen Gründe, die mir dazu einfallen würden, wären:

1. Ich will die Listboxen erst verändern, wenn ich alle Aktionen, die das Ergebnis betreffen, ausgeführt wurden
2. Ich will die Differenz noch mehrmals verwenden.
3. Ich will dem Benutzer erst eine Liste aller betroffenen Elemente als Vorschau anzeigen.

Aus deiner ursprünglichen Frage schließe ich aber, dass du lediglich die Differenzelemente aus der Liste löschen und die backups löschen willst. Dafür würde ich mir nicht erst eine Funktion anlegen, weil ich die ja nur einmal benötige, und ich dadurch an dieser Stelle noch nicht einmal Code gespart habe.
Denn: Ich muß mir extra noch ein StringList anlegen, ich muß natürlich die Funktion aufrufen, ich muß hinterher meine neue Stringlist (wieder mit einer Schliefe) verarbeiten, und ich muß die Listbox1 trotzdem aktualisieren. Und den zusätzlich code für
die Funktion brauch ich auch noch.

also habe ich durch die Funktion min. 10-15 Zeilen mehr Code.

Bei aufwendigeren Funktionen macht das aber durchaus sinn, oder wenn es der Übersichtlichkeit dient.

[sx2008]

@Captnemo: irgendwie fällt es dir schwer die Listboxen loszulassen und nur in Listen zu denken.
Man kann Liste B von A abziehen indem man das Ergebnis in C schreibt oder man macht es so wie du quasi in-place:

Delphi-Quellcode:

// Berechne A=A-B
procedure SubstractStringsInplace(A,B:TStrings);
var 
  i:Integer;
begin
  for i:=A.Count-1 downto 0 do
    if B.IndexOf(A[i])>=0 then
       A.delete(i);
end;
...
SubstractStringsInplace(Listbox1.Items, Listbox2.Items);

Und selbst wenn diese Procedure nur ein Einziges mal benützt wird, ist das Ergebnis doch besser lesbar und sogar schneller.
Schneller deswegen weil man nicht ständig auf die Listboxen zugreift, sondern mit den Items, also den TStrings-Objekten arbeitet.
Noch schneller würde es wenn man zusätzlich A.BeginUpdate & A.EndUpdate verwendet.

Auch kleine Funktionen/Proceduren sind wichtig und wertvoll!!

[Captnemo]

Zitat von sx2008:

@Captnemo: irgendwie fällt es dir schwer die Listboxen loszulassen und nur in Listen zu denken.
Man kann Liste B von A abziehen indem man das Ergebnis in C schreibt oder man macht es so wie du quasi in-place:

Delphi-Quellcode:

// Berechne A=A-B
procedure SubstractStringsInplace(A,B:TStrings);
var 
  i:Integer;
begin
  for i:=A.Count-1 downto 0 do
    if B.IndexOf(A[i])>=0 then
       A.delete(i);
end;
...
SubstractStringsInplace(Listbox1.Items, Listbox2.Items);

Und selbst wenn diese Procedure nur ein Einziges mal benützt wird, ist das Ergebnis doch besser lesbar und sogar schneller.
Schneller deswegen weil man nicht ständig auf die Listboxen zugreift, sondern mit den Items, also den TStrings-Objekten arbeitet.
Noch schneller würde es wenn man zusätzlich A.BeginUpdate & A.EndUpdate verwendet.

Auch kleine Funktionen/Proceduren sind wichtig und wertvoll!!

Hat mit loslassen nix zu tun.

Mal ehrlich, wenn ich von 10 Backups nur 3 Behalten will, wieviele Millisekunden willst du da durch irgendwelche Funktionen sparen?

Besser lesbar.....sehe ich anders. Wenn überhaupt, dann genauso lesbar. Wir reden hier von 3-5 zeilen code. Was bitte soll denn da unübersichtlich sein?

Und was ist Listbox1.Items....TString-Objekte. Ergo wird der Zugriff auf diese nicht schneller oder langsamer sein, als selbst erzeugte.
Hilfeauszug:

Zitat:

Enthält die Strings, die im Listenfeld angezeigt werden.

Mit Items können Sie Einträge anhängen, einfügen, löschen und verschieben. Standardmäßig sind alle Einträge eines Listenfeldes TStrings-Objekte. Mit den Methoden und Eigenschaften dieser Klasse können Sie die Einträge der Liste bearbeiten.

Wie ich bereits sagte, "In-Place" spare ich mir Code und zusätzliche TSTrings. Meine Meinung.

Wegen mir kann jeder seine kleinen Schliefen in Funktionen auslagern, wenn er das toll findet. Aber mit Übersichtlichkeit hat das in diesem Fall nun wirklich nichts zu tun. Eher im Gegenteil. Wenn ich jede Kleinigkeit in Funktionen auslagere, dann hab ne Unit mit hundeten Funktionen, die alle nur 3-5 Zeilen lang sind. Da steigt ja dann keiner mehr durch.
Damit meine ich jetzt nicht, Spagetti-code zu programmieren. Funktionen ja, aber nur wenn's sinn macht. Besser ist es, vernüftige Kommentare zu setzen.

[Sir Rufo]

@Captnemo
Ich würde dir mal einen Blick auf die Pattern empfehlen, da kann man eine Menge lernen wie und warum
Facade

[Captnemo]

Zitat von Sir Rufo:

@Captnemo
Ich würde dir mal einen Blick auf die Pattern empfehlen, da kann man eine Menge lernen wie und warum
Facade

Okay, und nun? Klär mich auf

Genau das sag ich ja. Wenn man einen bestimmten Ablauf an verschieden Stellen benötigt mach es ja sinn, das ganze in eine Funktion zu packen. Mach ich auch nciht anders. Und wenn möglicherweise aufwendige Abläufe nötig sind, versuche ich das auch in ein Funktion zu packen, damit die Übersichtlichkeit gegeben bleibt.

Aber weder das eine, noch das andere ist hier ja gegeben.

Natürlich kann mal letztlich alles vereinheitlichen und in Funktionen realisieren. Nur war das nicht die Frage des Threads.
Er wollte wissen, wie er bei zwei Listboxen zu seinem Ergebnis kommt, und das habe ich ihm gesagt.

Ob er dieses Wissen nun nimmt, um damit das gleiche über TStrings in einer Funktion zu machen, ist ja ihm überlassen. Die prinzipielle Vorgehenweise ist dabei ja letztlich das gleiche.

[sx2008]

Zitat von Captnemo:

Wie ich bereits sagte, "In-Place" spare ich mir Code und zusätzliche TSTrings. Meine Meinung.

Wegen mir kann jeder seine kleinen Schliefen in Funktionen auslagern, wenn er das toll findet. Aber mit Übersichtlichkeit hat das in diesem Fall nun wirklich nichts zu tun. Eher im Gegenteil. Wenn ich jede Kleinigkeit in Funktionen auslagere, dann hab ne Unit mit hundeten Funktionen, die alle nur 3-5 Zeilen lang sind. Da steigt ja dann keiner mehr durch.
Damit meine ich jetzt nicht, Spagetti-code zu programmieren. Funktionen ja, aber nur wenn's sinn macht. Besser ist es, vernüftige Kommentare zu setzen.

Was soll ich sagen: hoffnungslos.


Ich zitiere mal aus dem Buch Clean Code: A Handbook of Agile Software Craftsmanship von Robert C. Martin et al.

Zitat:

The first rule of functions is that they should be small.
The second rule of functions is that they should be smaller than that.

FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL.
THEY SHOULD DO IT ONLY.

In order to make sure our functions are doing “one thing,” we need to make sure that the
statements within our function are all at the same level of abstraction.

Ich kann dir nur empfehlen, das Buch mal zu lesen, falls du wirklich Interesse am Programieren hast.

[Captnemo]

Zitat von sx2008:

Ich kann dir nur empfehlen, das Buch mal zu lesen, falls du wirklich Interesse am Programieren hast.

Alles klar

[Furtbichler]

Zitat von Captnemo:

Wegen mir kann jeder seine kleinen Schliefen in Funktionen auslagern, wenn er das toll findet. Aber mit Übersichtlichkeit hat das in diesem Fall nun wirklich nichts zu tun. Eher im Gegenteil. Wenn ich jede Kleinigkeit in Funktionen auslagere, dann hab ne Unit mit hundeten Funktionen, die alle nur 3-5 Zeilen lang sind. Da steigt ja dann keiner mehr durch.

Du liest nicht die hundert Funktionen, sondern den Code, der sie verwendet. Das die Funktionsnamen selbsterklärend sind, weißt Du, was sie macht und musst nicht die 3-5 Zeiler (oh doch, manchmal auch 7) verstehen. Das spart pro Funktion ein paar Sekunden.

Zitat:

Besser ist es, vernüftige Kommentare zu setzen.

Falsch. Kommentare sind Stil der 80er Jahre. Guter Code benötigt keine Kommentare (Ausnahme: Rechtliche Hinweise und Quellenangaben). Guter Code ist selbsterklärend und liest sich wie ein Buch.

Man muss diese Empfehlungen natürlich aus der Sicht eines professionellen Softwareentwicklers sehen. Der Hobbyprogrammierer versteht nicht, weshalb es besser ist, hunderte kleine Funktionen zu haben, als kommentierten Code, der ohne sie auskommt: Es geht um Lesbarkeit. Ist ein Code lesbar (und kann ich ihn meinem Kollegen vorlesen bzw. er den Code selber lesen), dann ist er verständlich. Und zwar ohne Rücksprache oder das im Code Kommentare verstreut sind. Lesbarer Code ist einfach (KISS). Einfacher Code ist robust und erweiterbar.

[Captnemo]

Auch ich arbeite mit Funktion.

Die Frage des Threaderstellers war es, wie er zwei Listbox so vergleichen kann, dass er sein gewünschtes Ergibnis erhält.

Ich habe ihm eine Antwort gegeben, die ihm bei der Lösung seines Problems hilft. Punkt.

Ich halte nichts davon, jemandem dann eine Unit rein zu kopieren, die ihm Funktionen für ein so simples Problem zur Verfügung stellt, die dann ohne eigenes Zutun das gewünschte Resultat bring, ohne verstehen zu müssen, was da eigentlich passiert. Einfach reinkopieren und fertig.

Das das keiner Verstehen will....okay. Deswegen lass ich mich hier nicht als "hoffnungslos" betiteln.
Jedenfalls hab ich jetzt keine Bock mehr hier jemandem einen Lösungsvorschlg zu posten. Damit ist dieser Thread für mich erledigt.

[himitsu]

PS: Die Konstante -1 ergibt meistens soeinen unschönen Assemblercode und der Vergleich darauf ist auch nicht so schön.

Wenn man anstatt mit dem "Fehler" zu vergleichen, auf die korrekten Werte prüft, sieht es gleich viel hübscher aus.

z.B. bezüglich if IndexOf(...) = -1 then oder if not (IndexOf(...) = -1) then :
if IndexOf(...) < 0 then für "ist nicht drin" (OK, es sei denn man hat eine "sprechende" Konstante für den Fehlercode)
und if IndexOf(...) >= 0 then für "ist drin".

Eine positive Logik klingt auch meistens freundlicher und wenn man sich durchgehend vorwiegend auf eine Logik bezieht, ist der Code IMHO oftmals auch schneller verständlicher, da man weniger überlegen muß.