Globale Variablen und OOP

[Christian Seehase]

Moin Sirius,

Zitat:

Zitat von sirius

Heute, wo man sogar schon in Delphi mit dem Button "Neu" gleich die erste Klasse (TForm1) hingeklatscht bekommt,

sowie die globale Variable Form1... ;-)

[IngoD7]

Zitat:

Zitat von sirius

Zitat:

Zitat von Der_Unwissende

Zitat:

Zitat von IngoD7

Ich möchte den sehen, der angefangen ist zu programmieren, ohne globale Variablen benutzt zu haben. :cyclops:

Äh, mir fallen da gleich einige ein. Deswegen hier mal die Frage, ob Du dich auf Delphi oder Programmieren allgemein beziehst?

Tja, Ingo, wie du siehst: Die Zeit schreitet voran und du bist auch nicht mehr der Jüngste :lol:

Ich weiß zwar nicht, was mir das sagen soll - aber insoweit stimmt das: Ich bin schon mit (den Anfängen von Home-) Computern umgegangen, da warst du noch flüssig. :twisted: :twisted: :zwinker:

Ich meine natürlich die Anfänger, die (noch) wissen, was globale Variablen sind, und die in Sprachen unterwegs sind, die globale Variablen zulassen. Das ist doch wohl klar.

Jemand, der frisch aus den Windeln gefallen ist und der auf Sprachen ohne globale Variablen stößt, der wird natürlich auch nicht angefangen sein, mit solchen zu programmieren. Im Gegenteil: Dem wird die OOP und die lupenreine Umsetzung derselben als der heilige Gral verkauft. Und als ein solcher wundert der sich höchstens, dass Delphi die globalen Variablen überhaupt zulässt. Er wird aber nicht danach fragen (müssen), wie man sie verhindert.

Danach fragen nur die älteren Leute :mrgreen: oder aber die, die noch aus einer anderen Richtung als der OOP kommen. Und denen kann man ruhig sagen, dass sie sich anfangs keinen Zacken wegen der globalen Variablen aus der Krone zu brechen brauchen.

Aber natürlich ist das dennoch immer auch vom Anwendungsfall abhängig. Wenn ein solcher Newbie an einem 200 Units starken Projekt mitarbeitet, sollte er sich natürlich die globalen Variablen möglichst schnell abgewöhnen.

[sirius]

Zitat:

Zitat von Christian Seehase

Moin Sirius,

Zitat:

Zitat von sirius

Heute, wo man sogar schon in Delphi mit dem Button "Neu" gleich die erste Klasse (TForm1) hingeklatscht bekommt,

sowie die globale Variable Form1... ;-)

Die man ja auch ständig verwendet... :snowball:

[Hansa]

Zitat:

Zitat von Der_Unwissende

Zitat:

Zitat von Hansa

Da wird aber nichts verändert. Beim Programmstart lesen und das wars. Wer bei so einer trivialen Geschichte noch immer was verkehrt macht, der soll besser nicht anfangen zu programmieren. :???: Oder er soll sein Programm mit überflüssigem DAP-SchnickSchnack zumüllen.

Ok, so eine pauschale Aussage ist natürlich ein gutes Argument, aber egal.
Natürlich, gibt es eine globale Variable die nur gelesen werden soll, dann wird das ja auch jeder tun...

Inwiefern pauschal ? :shock: Ich habe ein Beispiel genannt, wo ausnahmsweise eine globale Variable effektiver ist, als was anderes, ohne sich selber unnötig zu strangulieren. Ich betone nochmals : ausnahmsweise. Die Variable wird nicht umsonst aus einer INI-Datei gelesen. Ich brauche sie projekweit. Wenn es irgendwie geht, dann gilt immer : die Sichtbarkeit niedrig zu halten. Auch schon gesagt. Und wenn sich einer nicht an die Vorgaben hält, wie in meinem Beispiel zwar möglich, eine nicht zu verändernde Variable eben doch zu verändern, dann ist er selber Schuld und auch für die Konsequenzen verantwortlich. Muß ein Programm erst Programmierer-sicher gemacht werden, tja dann siehts in der Tat schlecht aus. :mrgreen:

[Der_Unwissende]

Zitat:

Zitat von Hansa

Inwiefern pauschal ? :shock:

Ich bezog mich auf:

Zitat:

Zitat von Hansa

Wer bei so einer trivialen Geschichte noch immer was verkehrt macht, der soll besser nicht anfangen zu programmieren. :???: Oder er soll sein Programm mit überflüssigem DAP-SchnickSchnack zumüllen.

Zitat:

Zitat von Hansa

Ich habe ein Beispiel genannt, wo ausnahmsweise eine globale Variable effektiver ist, als was anderes, ohne sich selber unnötig zu strangulieren. Ich betone nochmals : ausnahmsweise.

Ja, aber das Problem an Ausnahmen ist, dass man sie als solche kennen muss. Gibt es ein Regelwerk (z.B. für Codestil), dann wird es sicherlich auch schnell die eine oder andere Stelle geben, an der sich einer sagt XYZ ist aber effektiver, machen wir mal 'ne Ausnahme. Typisches Beispiel dafür wäre für mich die Qualifikation von Instanz-Variablen mit self oder eben das begin und end hinter jedem if .. then (auch bei nur einem Befehl in diesem Block). Natürlich wird nicht jeder das für seinen Codestil verlangen, aber da wo etwas zu den Regeln gehört, hat sich (hoffentlich) jmd. etwas dabei gedacht.
Natürlich kann ich jetzt hier für die INI-Datei eine Ausnahme machen, aber es bleibt nunmal eine Ausnahme und ist damit inkosequent. Mag auch sein, dass Du nie jmd. triffst, der an dieser Stelle aufschlagen wird. Das Problem ist aber, dass wenn jmd. (aus welchen Gründen auch immer!) hier etwas falsch macht, dies auch unerwünschte Konsequenzen haben dürfte. Nimm z.B. eine Funktion, die diese Variable als var-Parameter bekommt. Schaust Du dir nur die Argumente an, kannst Du leicht übersehen, dass der eine Parameter verändert wird. Vielleicht geht es auch 10 mal gut (der Wert wird eben nur bedingt verändert) und dann beim Kunden kracht's. Da wäre dann die Frage ob das ein nötiger Fehler ist. Hätte man (z.B.) eine Funktion, so würde hier der Compiler deutlich darauf hinweisen, dass diese nicht als var-Parameter verwendet werden kann.

Zitat:

Zitat von Hansa

Ich brauche sie projekweit. Wenn es irgendwie geht, dann gilt immer : die Sichtbarkeit niedrig zu halten. Auch schon gesagt. Und wenn sich einer nicht an die Vorgaben hält, wie in meinem Beispiel zwar möglich, eine nicht zu verändernde Variable eben doch zu verändern, dann ist er selber Schuld und auch für die Konsequenzen verantwortlich. Muß ein Programm erst Programmierer-sicher gemacht werden, tja dann siehts in der Tat schlecht aus. :mrgreen:

Na ja, das finde ich klingt doch etwas paradox. Immerhin sagst Du ja auch, wenn es irgendwie geht, dann Sichtbarkeit niedrig halten (hier sogar ohne große Verrenkung, wir reden von 5 Zeilen, Signatur * 2, begin und end sowie result := ...).
Natürlich ist jeder selbst schuld, der sich nicht an Vereinbarungen hält, aber dass dieser jmd. die Konsequenzen trägt, hm, sehe ich anders. Also bei meinem Arbeitgeber hätten die meisten das Glück, dass ihr Chef die Verantwortung für die Programme übernimmt. Natürlich ist es deshalb auch im Interesse dieser Verantwortlichen, dass dann solche Dinge vermieden werden. Und da wären wir dann (meiner Erfahrung nach zumindest) bei Konsequenz. Wenn ich jmd. bestimmte Dinge vorschreibe, dann möchte ich eine konsequente Umsetzung sehen. Die kann ich aber nur schwer einfordern/rechtfertigen wenn meine Programme, dort wo ich es für sinnvoll halte, Ausnahmen machen. Dann wird sich doch jeder dem ich da etwas vorschreibe etwas verar... vorkommen und ebenfalls selbstständig solche Entscheidungen treffen.

Ich kann hier wirklich nur aus eigener Erfahrung sprechen, dass man jedes Programm tunlichst Programmierer sicher machen sollte. Ich meine jeder kennt Fehler in irgendwelchen größeren Programmen, nehmen wir doch klassisch den Blue-Screen oder so. Wie kommen die denn wohl ins Programm? Ich denke da dürften doch die Programmierer für verantwortlich sein.
Natürlich kann man bestimmte Ausnahmen machen und dies auch klar als solche Kennzeichnen und dann halt sagen, wer das nicht berücksichtigt ist selber schuld, nur zweifel ich an ob das klug wäre. Ich habe zumindestens schon Leute erlebt, die es nicht geschafft haben erst zu lesen und dann zu programmieren. Da wurden dann z.B. null Byte aus einem Puffer gelesen und es wurde sich gewundert, dass dabei nichts in einer Variable geschrieben wurde (und die tatsächliche Anzahl von gelesenen Bytes auch null war). Das lag nicht an fehlender Dokumentation, sondern an der falschen Verwendung einer Variable (bzw. genauer eines Parameter).

Deswegen denke ich, man sollte nicht davon ausgehen, dass kein Programmierer Fehler macht, da kommt es genauso häufig vor (vielleicht sogar häufiger) wie auch an anderer Stelle. Gerade die Möglichkeit des Debuggers (wir laufen mal in den Fehler und schauen dann was falsch ist) haben einen gewissen Einfluss auf einige (ich behaupte mal unerfahrenere) Menschen. Und da es sicherlich immer ein paar Leute geben wird, die noch etwas unerfahren sind und ich diesen Personen keineswegs das Programmieren verbieten bzw. das Aufhören damit empfehlen möchte, denke ich ist es ein besserer Weg Programme so "programmierersicher" wie möglich zu machen (letztlich machen auch die Erfahrenen mal etwas falsch und merken es dann rechtzeitig!).
Fehler kosten einen einfach immer mehr als jede Verrenkung, so unschön Letztere auch sind (und einen schlechten Ruf bekommt man nicht all zu leicht weg, eine Verrenkung im Code schon).