Set Object = Nothing am Ende einer Sub/Func nötig?

Hallo Forum,
mal eine allgemeine Frage zum Thema Objekte wieder löschen am Ende einer Sub/Funktion.
In der MS-Online Hilfe steht, das Objecte die mit
DIM objInstanz AS Object
SET objInstanz = Irgendwas
erstellt wurden automatisch wieder gelöscht werden, wenn die Function/Sub beendet.
Gleichzeitig sehe ich auch immer wieder in allen Beispielen am Ende den Code:
SET objInstanz = Nothing zum Zerstören/Löschen der Objekt-Instanz
Was ist nun wirklich nötig?

Bei Recordsets ist zumindest objInstanz.Close nicht nötig weil Nothing das automatisch erledigt.

Abgesehen von Guten / Schlechten Programmierstil möchte ich hier nur mal Klarheit haben um nicht unnötig Code zu erzeugen, wenn intern beim beenden einer Sub/Func sowieso schon sowas behandelt wird.

hallo

ein set objectvar = nothing am ende des codes ist definitiv unnötig. es macht genau das selbe, was unmittelbar danach ohnehin passieren würde - nämlich den destruktor ausführen und den speicher freigeben.

insofern ist das „set nothing“ am ende eher schlechter programmierstil - so nach dem motto „ich muss unbedingt ein set nothing machen, also mache ich es halt“. es suggeriert guten programmierstil und täuscht damit darüber hinweg, dass sich der programmierer eigentlich nichts dabei gedacht hat.

bevor ich also am ende eines codes alibihalber ein set nothing einbaue, lasse ich es lieber gleich weg - ist ehrlicher.

prinzipiell ist es in vb halt genauso wie unter C: speicher, den ich nicht mehr brauche, sollte ich so bald wie möglich freigeben. ansonsten riskiere ich einen memoryleak, der meine anwendung instabil macht. die meisten programmierer sind aber dafür zu faul - v.a. weil man mit einem unbedachten set nothing natürlich auch ganz schon probleme bekommen kann.

in der heutigen zeit, in der man sich einfach „zur sicherheit“ ein gigabyte ram mehr in den rechner steckt, ist die diskussion eh etwas hinfällig, weil man schon wirklich schlecht programmieren muss, um noch probleme mit memoryleaks zu bekommen.

lg
erwin

hallo

Hallo,

insofern ist das „set nothing“ am ende eher schlechter
programmierstil - so nach dem motto „ich muss unbedingt ein
set nothing machen, also mache ich es halt“. es suggeriert
guten programmierstil und täuscht damit darüber hinweg, dass
sich der programmierer eigentlich nichts dabei gedacht hat.

Da gehen unsere Meinungen auseinander.
Ich selbst schreibe es immer hin!

Was passiert wenn du eine Variable auf ein Object setzt innerhalb einer Procedure und da man wie es halt sehr oft bei vielen vorkommt kein PAP vorhanden ist, man im nachgang noch einfaellt ach dies und das muss noch gemacht werden. Und UUps dazu brauche ich ja das Object XYZ … ergo man durchsucht das Project und löscht alle Declarationen auf das Object XYZ und declariert es Public ?
Es ist ein schlechter Programmierstil, aber leider kommt dieser sehr oft vor! Von daher lieber die eine Zeile schreiben und gut ist :smile:

bevor ich also am ende eines codes alibihalber ein set nothing
einbaue, lasse ich es lieber gleich weg - ist ehrlicher.

Und kann frueher oder später evtl. zu problemen führen, bei einigen

prinzipiell ist es in vb halt genauso wie unter C: speicher,
den ich nicht mehr brauche, sollte ich so bald wie möglich
freigeben. ansonsten riskiere ich einen memoryleak, der meine
anwendung instabil macht. die meisten programmierer sind aber
dafür zu faul - v.a. weil man mit einem unbedachten set
nothing natürlich auch ganz schon probleme bekommen kann.

Ist Ansichtssache. Wenn du eine Variable hast, die du sehr oft benötigst. Declarierst du sie dann in jedem Modul oder lieber gleich einmal Public ?
Oder

Du verwendest du die Function Split, in einer Sub.
Führst du gleich ein set … oder erase … aus, wenn du die Daten nicht mehr brauchst und die sub noch etwas zu erledigen hat?

in der heutigen zeit, in der man sich einfach „zur sicherheit“
ein gigabyte ram mehr in den rechner steckt, ist die
diskussion eh etwas hinfällig, weil man schon wirklich
schlecht programmieren muss, um noch probleme mit memoryleaks
zu bekommen.

Richtig

lg
erwin

MfG Alex

hallo nochmal

Ich selbst schreibe es immer hin!

ist ok - kostet dich praktisch nichts und schadet nicht.

Was passiert wenn du eine Variable auf ein Object setzt
innerhalb einer Procedure und da man wie es halt sehr oft bei
vielen vorkommt kein PAP vorhanden ist, man im nachgang noch
einfaellt ach dies und das muss noch gemacht werden. Und UUps
dazu brauche ich ja das Object XYZ … ergo man durchsucht das
Project und löscht alle Declarationen auf das Object XYZ und
declariert es Public ?
Es ist ein schlechter Programmierstil, aber leider kommt
dieser sehr oft vor! Von daher lieber die eine Zeile schreiben
und gut ist :smile:

ich gewöhne mir also „schlechten“ programmierstil an, damit ich im fall eines quick&dirty-hacks einen code zusammenpfriemeln kann, der zwar kompiliert, aber nicht vorhersehbare ergebnisse liefern kann? ok, das war jetzt stark übertrieben. ich bin nun mal kein fan davon, jede variable, die ich irgendwie noch brauchen kann, einfach so als public zu definieren. dann vergesse ich irgendwo eine lokale variable - oder noch schlimmer, habe option explizit nicht definiert, und schon kenne ich mich nicht mehr aus, was eigentlich passiert.

Und kann frueher oder später evtl. zu problemen führen, bei
einigen

alles kann früher oder später ev. zu problemen führen. absolut sauberen code zu schreiben ist nahezu unmöglich.

Ist Ansichtssache. Wenn du eine Variable hast, die du sehr oft
benötigst. Declarierst du sie dann in jedem Modul oder lieber
gleich einmal Public ?
Oder

Du verwendest du die Function Split, in einer Sub.
Führst du gleich ein set … oder erase … aus, wenn du die
Daten nicht mehr brauchst und die sub noch etwas zu erledigen
hat?

normalerweise versuche ich schon, variablen brav per argumente an die ganzen subs und functions weiterzugeben. hin und wieder kommt es vor, dass sich plötzlich die vorgaben für das programm ändern und eine variable, die vorher lokal und unwichtig war, plötzlich viel später sehr relevant wird. da trickse ich dann auch mit public, weil sonst der änderungsaufwand sehr hoch wird - mit nicht absehbaren folgen für die stabilität der software. aber in diesen fällen passe ich dann halt extrem darauf auf, wann ich die variable freigebe.

meiner meinung nach ist es generell so: es gibt zwei arten von programmierern: jene, die verstehen, was sie da eigentlich treiben, wenn sie objektvariablen verwenden, und jene, die froh sind, dass das ding halbwegs das tut, was sie wollen und damit zufrieden sind.

die erste gruppe wird sowieso instinktiv das set nothing richtig platzieren, die zweite gruppe wird solange mit set nothing herumprobieren, bis das zeugs nicht mehr ständig mit speicherproblemen abstürzt und dann wieder weiterwurschteln, wie bisher.

zu den zeiten, in denen die meisten computer maximal 64 KB speicher hatten, war die menge an leuten aus der zweiten gruppe, die sich länger als einen monat als programmierer behaupten konnten, doch eher gering. inzwischen schockt es keinen mehr, dass programme, die eigentlich nicht viel können, 10 MB speicherplatz auf der platte und 200 MB hauptspeicher verbrauchen.

was ist guter programmierstil, was schlechter?
ein programm ist dann gut, wenn es die anforderungen des anwenders erfüllt.
für code wie aus dem lehrbuch bekomme ich keinen preis, wohl aber dafür, das ich mein produkt schneller als die konkrenz auf den markt bringe.
wenn mich software von programmieren der zweiten gruppe inkl. hardwareaufrüstung inkl. folgekosten bei anpassungsarbeiten weniger kostet als software der ersten gruppe - und die software meine erwartungen erfüllt - wenn kümmert dann der programmierstil?

nur so ein paar geistige auswürfe zum thema

ich bin eh schon wieder still

lg
erwin

Hallo,

ich bin eh schon wieder still

nein, kneifen gilt nicht! :smile:

Auch mal eine andere Meinung zu haben gehört doch zu einer Diskussion, so kommen wir alle weiter. Das ist schließlich kein Streit, Niemand ist persönlich geworden … Du kannst immer sagen, was Du zu dem Thema denkst, das gehört hier her. :smile:

Gruß, Rainer

hallo nochmal

Hi,

ist ok - kostet dich praktisch nichts und schadet nicht.

Gut dann sind wir uns ja einig :smile:

ich gewöhne mir also „schlechten“ programmierstil an, damit
ich im fall eines quick&dirty-hacks einen code
zusammenpfriemeln kann, der zwar kompiliert, aber nicht
vorhersehbare ergebnisse liefern kann? ok, das war jetzt stark
übertrieben.

Da hatte ich nicht geschrieben. Ich schrieb bei manch einem. Ich habe schon Sachen gesehen ( Du sicherlich auch) da wird einem Spy Uebel.

ich bin nun mal kein fan davon, jede variable,
die ich irgendwie noch brauchen kann, einfach so als public zu
definieren. dann vergesse ich irgendwo eine lokale variable -
oder noch schlimmer, habe option explizit nicht definiert, und
schon kenne ich mich nicht mehr aus, was eigentlich passiert.

Siehst und was passiert wenn du eine Variable öffentlich hast und diese auf ein Object zugreift. Nehmen wir Office zur Rechtschreibprüfung und du vergisst das Set …
Genau aus diesem Grunde, sollte man es machen, meiner Meinung nach :smile:
Und was die Declaration als öffentlich Variablen angeht.

Ich declariere nicht alles als Public! Nur wenn ich sie wirklich sehr oft brauche. Wie zum Bsp. ein Recordset, die Connection, ein Pfad auf ein Directory, was zur Laufzeit festgelegt wird etc.
Ansonsten kommen halt viele Enum’s oder Const zum Einsatz, damit man den Source später noch versteht. Was nuetzt es mir wenn ich irgendwo einen Aufruf habe mit einem Argument alla &H86.
Ist es da nicht besser an eine Konstante nennnen wir sie mal Max mit dem Wert von &H86 festzulegen?

Und kann frueher oder später evtl. zu problemen führen, bei
einigen

alles kann früher oder später ev. zu problemen führen. absolut
sauberen code zu schreiben ist nahezu unmöglich.

Das ist richtig. Nur kann man sich muehe geben oder?
Sicherlich spielt der Aufwand eine Rolle, welche wiederrum mit Zeit und demzufolge mit Kosten verbunden ist, was da wiederrum eine Rolle spielt wenn man berufl. programmiert.
Nur programmiert man Just For Fun, da kann man sich schon muehe geben?
Auch sind sehr viele her, die in Sachen Programmierung Noob’s sind und sich hier Info’s holen wie sie etwas realisieren koennen.
Ok, viele kopieren nur den Source und sind froh wenn es klappt. Aber dann fallen sie irgendwann auf die gusche :wink:

Nur trotz alledem finde ich, sollte man ihnen schon sagen / zeigen wie es sauber programmiert wird, sofern es geht .

normalerweise versuche ich schon, variablen brav per argumente
an die ganzen subs und functions weiterzugeben. hin und wieder
kommt es vor, dass sich plötzlich die vorgaben für das
programm ändern und eine variable, die vorher lokal und
unwichtig war, plötzlich viel später sehr relevant wird. da
trickse ich dann auch mit public, weil sonst der
änderungsaufwand sehr hoch wird - mit nicht absehbaren folgen
für die stabilität der software. aber in diesen fällen passe
ich dann halt extrem darauf auf, wann ich die variable
freigebe.

Und was ist wenn du auf Ereignisse agierst? Dort hast du meines Wissen, nicht die Möglichkeit Argumente zu uebergeben :s
Ohne Gross zu tricksen und „unsauber“ zu werden kommst du nicht auf gewisse public variablen drum herum!

Allein ein Bsp. Es geht eine Inputbox auf und es wird nach dem Pfad gefragt. Diesen brauchst du dann aber im ganzen Project. Bietet es sich nicht hier an, da eine Variable anzulegen und diese als Public zu declarieren?

Ich mein, ich weiss bei weiten noch nicht alles ueber VB. Dennoch habe ich schon Projecte hinbekommen die weitaus mehr als 100.000 Zeilen Source Code hatten und der Speicherbedarf unter MB war :wink:
Was zur heutigen Zeit nicht gerade viel ist.

meiner meinung nach ist es generell so: es gibt zwei arten von
programmierern: jene, die verstehen, was sie da eigentlich
treiben, wenn sie objektvariablen verwenden, und jene, die
froh sind, dass das ding halbwegs das tut, was sie wollen und
damit zufrieden sind.

Da bin ich mit Dir eins.

die erste gruppe wird sowieso instinktiv das set nothing
richtig platzieren, die zweite gruppe wird solange mit set
nothing herumprobieren, bis das zeugs nicht mehr ständig mit
speicherproblemen abstürzt und dann wieder weiterwurschteln,
wie bisher.

Auch richtig. Diese gibt es leider zu oft!
Denn irgendwann wollen sie mal ein Update machen und wissen nicht mehr was sie da geschrieben haben und lassen es gleich bleiben oder kommen mit unmöglichen Source hier an.
Wobei wir wieder bei einem anderen Punkt waeren, welches das Kommentieren des Sources ist, oder zumindest was welche Function macht etc.

zu den zeiten, in denen die meisten computer maximal 64 KB
speicher hatten, war die menge an leuten aus der zweiten
gruppe, die sich länger als einen monat als programmierer
behaupten konnten, doch eher gering. inzwischen schockt es
keinen mehr, dass programme, die eigentlich nicht viel können,
10 MB speicherplatz auf der platte und 200 MB hauptspeicher
verbrauchen.

Das ist wohl wahr!

was ist guter programmierstil, was schlechter?
ein programm ist dann gut, wenn es die anforderungen des
anwenders erfüllt.

Auch das stimmt. Der Anwender sieht letztendlich nicht was da zusammengetippelt wurde. Nur sollte man bedenken das es vielleicht auch einmal ein Nachfolger von Dir geben wird, der eines Tages dein Project erweiteren soll!

für code wie aus dem lehrbuch bekomme ich keinen preis, wohl
aber dafür, das ich mein produkt schneller als die konkrenz
auf den markt bringe.
wenn mich software von programmieren der zweiten gruppe inkl.
hardwareaufrüstung inkl. folgekosten bei anpassungsarbeiten
weniger kostet als software der ersten gruppe - und die
software meine erwartungen erfüllt - wenn kümmert dann der
programmierstil?

siehe oben!

nur so ein paar geistige auswürfe zum thema

Auch nur mal fix meine Meinung dazu!

ich bin eh schon wieder still

Ich auch :wink:

lg
erwin

MfG Alex