lokale Variablen mit globaler Lebensdauer?

[sniper_w]

Zitat:

Und schon gates los... Rolling Eyes

Also .Tut mir leid für mein Posting (weil es OT ist), aber das war einfach lustig. MrGreen ist verdient.

[Robert_G]

Zitat von sniper_w:

Zitat:

Und schon gates los... Rolling Eyes

Also .Tut mir leid für mein Posting (weil es OT ist), aber das war einfach lustig. MrGreen ist verdient.

Normalerweise wäre da ein -> <- gewesen.
Aber diese Milchmädchenrechungen und Rumpiekereien oder hach so tolerante, komplett jedem sinnvollen Inhalts, beraubte Aussagen wie wenigstens 2 der letzten paar Beiträgen, finde ich einfach zu nervig um darüber lachen zu können...

[DGL-luke]

gleich mal vorweg: ich will hier keinen flame anfangen...

Zitat von Robert_G:

Warum sollte ich erklären, was ich meine. Du scheinst einfach nur nicht alles verstanden zu haben.
Und was ich mit dieser letzten Frage meinte, war eher dass Hagens (gewöhnlich) langer Beitrag IMHO fehl am Platz war, da das Thema gar nicht wirklich aufkam...

Was gibt es an einem einzigen Satz denn nicht zu verstehen, abgesehen davon, dass er zu wenig Information liefert? Oder meinst du, ich habe Hagens Text nicht verstanden? Das hat aber dann nichts mit dem, was du zitierst, zu tun.

Zitat:

Zitat:

ich würde hagen hier zustimmen: auch prozedurale programmierung kann sauber sein.

Was ist denn das für ein Argument?
a) Ging es hier überhaupt nicht darum und b) ist ein "X kann doch auch OK sein" in etwa so aussagekräftig wie auf alles mit 42 zu antworten.

Das ist kein Argument, ich wiederhole nur Hagens These, bevor ich weiter darauf bezug nehme.

Zitat:

Zitat von DGL-luke:

und vor allem macht OOP sehr viel mehr arbeit als prozedurale programmierung.

Wieder so ein Ding, das hier absolut OT ist und schnell in einem Krieg angepupter Nicht-OOP'ler ausartet...

"angepupt" bist hier wohl eher du, nach deiner Reaktion zu schließen. Ich bin "Nicht OOP-ler", wenn man das so sagen kann.
Und zu OT: geht es hier nicht um saubere Programmierung bzw. das was man selbst dafür hält? Deine These "hier In diesem Thread geht es nicht um OOP" lässt mich vermuten, dass DU hagens Beitrag nicht wirklich verstanden hast.

Auch kann ich gerne nochmal ein paar Argumente liefern:

- mehr Tipparbeit (soltle unstrittig sein...)
- Mehr Denkarbeit (Erzeugen/Freigeben von Objekten die innerhalb der Klasse benutzt werden, Verpacken in eine Klassenstruktur, ...)

Zitat:

Zitat von DGL-luke:

zumindest meines Ermessens(kann auch daran liegen, dass bei mir OOP bis jetzt mit "Komponentenprogrammierung" äquivalent ist und ich da noch nicht ganz durchsteig).

Was sagst du, wenn ich dir nun vorwerfe, dass du für fast keine deiner Aussagen eine Begründung geliefert hast?

wenn ich nur zwei aussagen mache, und davon eine begründe(wobei ich die begründung für die zweite ja oben nachreiche), muss ich wohl akzeptieren, dass du das für "fast keine" hältst.

Zitat:

Ehrlich gesagt interessiert es mich nicht wirklich. Es ging mir nur darum, dass du mir erst etwas vorwirfst, was du im selben Beitrag selbst machst...

Mich interessiert es auch nicht - worüber reden wir gleich noch mal?

Zitat:

btw: @Nico
Jupp, ich glaube das tun wir wohl alle...

full ack.

Abschließend zu den inzwischen neuen Postings:

Zitat:

Und schon gates los... Rolling Eyes

wie bereits gesagt, ich will hier keinen flame anfangen.

Zitat:

Das spielt doch gar keine Rolle, ob du 'ne Standard/Personal, Professional, CS/Enterprise oder 'ne Architect hast.

Doch, mit einer Personal bist du echt am Darmausgang bei allem, was über Klickibunti(sprich implementierung von standardevents) hinausgeht.

PS: tut mir leid, ich muss jetzt senden, gleich ist meine internetzeit aus. vergebt mir also evtl. fehlendes debugging

[TeronG]

Ich finde GloKale Variabeln (da/wenn sie zur übersicht beitragen) garnet mal so schlecht ... nur leider versteh ich den ersten Post (code) nicht wirklich ganz

was ich nur schade finde ist, daß solche Threats immer (oft) zu einer grundsatzdiskusion ausarten .. und das bei einem Thema wo es sowas garnicht geben sollte ... man muss doch immer seine Werkzeuge nach der Anforderung wählen und nicht nach Philosophie (Schraubendreher?? nix da! bin Hammer-fan!) ... naja egal ...

[edit's]bugfixing ... (ja alle edit's )

[malo]

Zitat von Sprint:

Zitat von malo:

Auch, wenn es manchmal ach so leicht ist, eine Klasse zu erstellen und alles was dazu passt in dieser Klasse auszulagern, macht so etwas manchmal einfach zu viel Arbeit (besonders für Leute wie mich, die keine Pro-Versionen besitze/nutze

Das spielt doch gar keine Rolle, ob du 'ne Standard/Personal, Professional, CS/Enterprise oder 'ne Architect hast.

Doch, wenn es um OOP-Programmierung geht. Methoden deklarieren etc, funktioniert in Pro/Ent/Arc-Versionen bedeutend einfacher und schneller, Stichwort: Code-Completion mit Strg+Shift+C. Dieses Feature wird in PE-versionen nicht unterstützt und erleichtert in Pro/Ent/Arc-Versionen die OOP-Programmierung bedeutend.

Zitat von Luckie:

Faulheit oder Bequemlichkeit ist für mich keine Ausrede nicht sauber zu programmieren, sei es jetzt OOP oder nicht.

Das ist es auch nicht. Allerdings wollte ich damit ausdrücken, dass manches, was man mit der OOP macht, einfach overkill ist (besonders wenn man PE-Versionen benutzt), da man da einige Zeit an Tipparbeit verliert, die genausogut für wichtigere Dinge genutzt werden kann. Das ist imho einer der Nachteile an OOP."Sauber" Programmieren ist natürlich immer wichtig, aber der Weg dorthin spielt auch eine wichtige Rolle. Man kann sich stundenlang hinsetzen und ein ausgeklügeltes OOP-Konzept entwickeln, man kann aber auch procedural arbeiten und nur das in Klassen schreiben, was dort wirklich besser aufgehoben ist (zum Beispiel, wenn dabei Vererbung einem hilfreich zur Seite stehen könnte). Und solange man nachher noch durch das ganze durchsteigt, kann man imho arbeiten wie mal will/kann/es für richtig hält

//edit: Sorry, wenn das hier auch OT ist... da hab ich beim posten nicht drauf geachtet

[Sprint]

Zitat von malo:

Code-Completion mit Strg+Shift+C. Dieses Feature wird in PE-versionen nicht unterstützt und erleichtert in Pro/Ent/Arc-Versionen die OOP-Programmierung bedeutend.

Wenn du diese Funktion unbedingt brauchst, dann wäre jetzt vielleicht der Zeitpunkt dich mit der OpenTools API zu beschäftigen.

[nailor]

Zitat von Sprint:

Zitat von malo:

Code-Completion mit Strg+Shift+C. Dieses Feature wird in PE-versionen nicht unterstützt und erleichtert in Pro/Ent/Arc-Versionen die OOP-Programmierung bedeutend.

Wenn du diese Funktion unbedingt brauchst, dann wäre jetzt vielleicht der Zeitpunkt dich mit der OpenTools API zu beschäftigen.

oder sich eine Pro-Version zu kaufen.

[Hansa]

Zitat von Dax:

Ums direkt zu sagen: Lokale Variablen mit Globaler Lebensdauer sind größtmöglicher Schwachsinn. Da kannst du auch gleich globale Variablen nehmen, was genauso schwachsinnig ist

Das von dir Gesagte ist wirklich Schwachsinn ! Da gebe ich Dir Recht. Was ist aber jetzt mit der Hauptfrage ? Ich halte die Sichtbarkeit von Variablen möglichst gering. Es gibt allerdings auch welche, die global sind, weil sie sich nicht ändern.

[negaH]

Geht es hier nun um die Frage was ein guter Programmierstil ist oder nicht ?

In meinen Postings wollte ich ganz klar ausdrücken das die Vermischung von Programmier-stil mit spezifischen Funktionalitäten diverser Programmiersprachen, sprich also OOP, rein garnichts zur Fragestellung beitragen kann.

Fängt man also an zu behaupten das die Anwendung von OOP ein guter Programmierstil sei, so vermischt man zwei komplett unterschiedliche Argumentationswelten. Das im Endeffekt die sprachliche Funktionalität der OOP in Delphi ein Indiz für einen guten Stil darstellt ist nur eine der vielen Konsequenzen eines guten Stiles an sich. Also nicht die Anwendung von OOP oder anderen Methoden definiert einen guten Stil sondern exakt umgekehrt. Zuerst war der Mensch mit seinen charakterlichen Zügen, dann kam die Machnine Computer (erfunden von Menschen) und erst dann die verschiedenen Programmiersprachen (erfunden von Menschen) die erst dann mit der Zeit unterschiedliche Methoden der Programmierungen einführten (also zb. OOP, erfunden von Menschen). Und erst nach diesen vielen zeitlichen Schritten konnte es Programmierer geben die nun behaupten das OOP der beste Stil überhaupt wäre (die sich über Erfindungen von Menschen streiten). Somit ist aus Sicht dieser Programmierer das Ei vor der Henne da gewesen.
Der einzigste Fixpunkt zur Beurteilung eines Programmierstils ist der Mensch an sich.

Nun was ich ausdrücken wollte ist das ein guter Programmierstil eher die Frage nach den Fähigkeiten eines Menschen ist als die Frage mit welchen Werkzeugen oder Methoden dieser Mensch seine Programme programmiert. Denn aus Sicht des Programmierstils sind die Werkzeuge und Methoden ohne zeitliche Dauer und Relevanz, denn sie werden sich mit der Zeit immer drastischer verändern. In 100 Jahren müsste man die OOP also als schlechten Stil betrachten da es dann ganz andere Werkzeuge geben wird. Aber, der Mensch der diese Werkzeuge benutzt wird sich denoch von anderen Menschen in seinen Fähigkeiten und Fertigkeiten unterscheiden. Und exakt diese Untrschiede zwischen den einzelnen Menschen in ihrer Art&Weise zu programmieren definiert dann einen unterschiedlichen Stil !

Programmieren ist also als Denkvorgang eines Menschens zu vestehen. Und je nachdem wie dieser Mensch ein Problem gedanklich anpackt, es zielstrebig zerdröselt und in Teilprobleme zerlegen kann, wie er dann die richtigen Werkzeuge auswählt, sich also entweder für oder gegen die Methode der OOP entscheidet, abhängig vom Problem, bestimmt den Stil !

Es wird niemals eine dauerhafte und unveränderliche Technologie existieren die uns die Grundlage für Behauptungen wie "OOP ist guter Stil" sachlich gegründbar darlegen kann.

Technologie = Werkzeug = Programmiersprache, Sprachfeatures, Programmiermethoden wie OOP, procedural etc. pp. Diese Technologie verändert sich ständig und wird durch Menschen weiter verändert.

Programmieren = das Denken eines Menschens

Programmier-Stil = die einmalige und individuelle Signatur des Denkens eines Menschens, also wie programmiert, bzw. denkt ein Mensch.

Betrachtet man das mal aus dieser Sichtweise so erscheinen viele Aussagen in diesem Thread einfach lächerlich. Eben weil man die heutige Technologie nicht als Indiz zur Beweisführung eines guten Programmierstils heranziehen darf.

Gruß Hagen

[negaH]

Und nun konkret zur Eingangsfrage:

Ja, wenn es eine sinnvolle Verwendung für stark lokal begrenzt sichtbare aber global wirkende Variablen gibt dann sollte man mit solchen Restriktionen unbedingter Weise auch arbeiten.

Es ist also nicht egal ob man eine solche Variable ganz global definiert wenn es nicht unbedingt sein müsste. Einen durchdachten Programmierstil würde man nun daran erkennen das der Programmierer die Sichtbarkeit dieser Variable auf das notwendigste Maß beschänkt. Und wie in der Eingangsfrage als Beipspiel aufgezeigt kann man so die Sichtbarkeit dieser Variablen auf eine einzigste lokale Funktion beschränken, weil die Variable eben nur dort nötig ist. Das ist in fact ein guter Stil, ganz unabhängig von OOP, proceduraler Programmierung oder das dieses Feature durch Borland in Zukunft wegretionalisiert wird. Wer sagt denn das die Borländer die Superschlauberger sind und die Entfernung dieses Features in Zukunft wirklich ein sinnvoller Schritt darstellt ? Ich persönlich habe mich bei der Umstellung von D5 auf D7 ziemlich gewundert das Borland diesen Schritt vollzogen hat.

Gruß Hagen