lokale Variablen mit globaler Lebensdauer?

[dizzy]

Zitat von Robert_G:

@Dizzy
Nur wann braucht man mal einen einzelnen primitiven Wert?
Um mehrere, zusammengehörige Werte zu einem Paket zu verschnüren, das nur einmal existieren darf, wäre das klassische Singleton wohl die gebräuchliste Lösung.

Aus Gründen der Gleichbehandlung (Geschwindigkeit) von Konstanten und Variablen in meinem Parser (die selbst definierten) war das sinnvoll. Ich habe es dort im Übrigen nicht nur mit primitiven Werten, sonder auch mit Records () so gemacht . Und es durfte nicht nur ein mal existieren. Ein Singleton wäre nicht nur nicht angebracht gewesen, sondern mit einem Overhead verbunden der nicht gerechtfertig wäre.

[negaH]

Argumente wie:

- das wird es nicht mehr geben
- Borland wird es in seinem Compiler nicht mehr unterstützen
- es ist ein schlechter Stil
- schau dir mal andere Sprachen an
- in Sprache X ist das aber möglich
- mit Objekten sollte man Singeltons benutzen

zählen rein garnichts. Im Delphi gibt es initialisierte Konstanten die wie statische Variablen auch lokal zu einer Funktion benutzt werden können. Das ist der Stand der Dinge über den wir reden.

Aber aus solchen Argumenten eine Begründung zu konstruieren warum die Benutzung solch einer Funktionaltiät ein schlechter Programmierstil darstellt ist unlogisch und irrwitzig.

Schau mal, ich meine das ein guter Programmierstil reingarnichts damit zutun hat ob man bestehende Funktionalität einer Programmiersprache nun so oder so benutzt. Ich habe in meinen 20 Jahren die ich als Programmierer garbeitet habe viel Software gesehen. Interessant sind natürlich nur die Projekte die auch ihr gestecktes Ziel erreicht haben. Und dabei musste ich feststellen das guter Programmierstil in Assembler, Basic, Pascal, C und sogar VBA möglich ist, ohne oder mit OOP, ohne oder mit Interfaces, rein procedural oder eben nicht. Das dieser gute Stil Programme sein konnten die Spaghetti Code waren, oder fast schon kryptische C Sourcen oder eben OOP in Pascal.
Ich habe aber auch schon Software gesehen die den vergeblichen Versuch unternommen haben wirklich alles OOP konform in Klassen zu kapseln, und?, dadurch ist der ReportBuilder auch nicht besser geworden als andere viel einfachere Lösungen. Wer den RB gekauft hat sollte sich wirklichmal in dessen Source einarbeiten.

Ehrlich gesagt, ich bewundere Sources bei denen jede einzelne Sourcezeile wirklich zum Gesamtwerk beiträgt, alles ist durchdacht, angefangen beim benutzten Algorithmus der auf handfesten mathematischen Berechnungen beruht, über die richtige Wahl der effizientesten Datenstrukturen (was auch einfache Records sein könnten) über diereale Umsetzung als Source bis hin zur fertigen Software. Dabei war es im Grunde egal mit welcher Sprache programmiert wurde und/oder welchen Stil der Programmier sich angeeignet hatte (hauptsache dieser Stil war sauber strukturiert).
Wichtig ist dann nur eine Aussage: "Wow das hat der Programmierer ja genial gelösst!"

Das heist also das ein Programmierer der einen guten Programmierstil besitzt mit JEGLICHEM Werkzeug immer einen guten Stil haben wird, egal welche Programmiertechnologien ihm zur Verfügung stand. Das wichtigste Indiz für einen guten Stil ist nicht die Beschränkung auf eine geringe Menge aller Möglichkeiten einer Sprache, sondern das wichtigste Indiz ist die effiziente und an das Problem angepasste Verwendung ALLER Möglichkeiten einer Programmiersprache.

Die Aussagen das OOP, .NET etc. pp. DEN besten Stil in der Programmierung darstellen sind also meiner Meinung nach eine sehr kurzsichtige und aufdoktrierte Sichtweise der Dinge. Eine solche Sicht muß zwangsläufig in eine Idiotie führen, denn man versperrt sich die unvoreingenommene Sicht auf all die anderen möglichen Wege eine Software zu programmieren. Mann was haben wir nicht alles in den letzten Jahren an Trends kommen und wieder sterben sehen. Was ist eigentlich aus Kylix geworden, was aus Corba, was aus dem Extreme Programming. Alles ist gescheitert weil mehr die Marketingexperten das sagen hatten, weil die Mode in die Programmierung Einzug gehalten hat, und mit der Mode kamen die überflüssigen Mode-Schöpfer in unsere Branche. Wir streben nach immer neueren Sprachfeatures weil man glaubt dadurch dann ein besserer Programmierer zu werden. Ich erinnere mich an ein simples Problem hier in der Delphi Praxis: bau die Lottoziehungen im Fernsehen als Program nach. Es hat mich viele Postings gekostet um auf das eigentliche Problem aller Lösungsvorschläge hinzudeuten, es verständlich zu machen. Nämlich das Erkennen des eigentlichen Problemes um die korrekte Lösung zu finden, und nicht der beste Weg zu irgendeiner halbrichtigen Lösung.

Schau mal: ich programmiere in ganz verschiedenen Sprachen auf ganz verschiedenen Plattformen. Zb. Delphi auf PC's, C/C++/Pascal auf Handhelds, C/Asm auf Mikrokontrollern und VHDL/ABEL auf FPGA's/CPLD's. Alles hat mit Programmierung zu tun, keine der unterschiedlichen Sprachen oder Plattformen lässt einen direkten Vergleich untereinander zu, sie sind zu verschieden. Und denoch behaupte ich das wenn ich dir einen Source in Delphi für PC's und einen Source in C/Assembler für zb. einen Atmel Mikrokontroller zuschicke du denoch einen Stil EINER Person in der Art der Programmierung erkennen wirst. Wie bitte schön passt da OOP als Methode der Programmierung hinein ?
Ich behaupte mal das man den ausgeprägten Stil eines Programmieres auch "durch die Sprache hindurch" wiedererkennen kann. Die Sprache, ja selbst die unterschiedlichen Methoden des Programmierens, ist zur Bewertung eines Programmier-Stils absolut irrelevant. Es geht viel mehr um Kreativität, wie ein Mensch ein Problem erfassen konnte, wie dieser Mensch seine Aufgaben organisiert, welches Wissen er dafür verwendet und ihm zur Verfügung steht, und ob er zeilstrebig diszipliniert und sauber arbeiten kann. Erst danach kommt die Technologie in Form seiner Werkzeuge zum tragen, sprich die Programmiersprache.

Ihr verwechselt den Programmierstil mit äußeren Umweltbegingungen, irgendwelchen Gegebenheiten irgendwelcher Sprachen oder bestimmter Technologien, irgendwelchen vorgekauten Meinungen von Mode-Schöpfern. Wie zb. Microsoft pusht .NET also muß es gut sein, Borland forciert OOP also ist es guter Stil. Shit sage ich dazu nur, den der Programmierstil ist allerhöchsten vergleichbar mit dem schriftstellerischen Schreibstil eines Buchautors oder mit der Pinselführung und Farbauswahl eines Malers.

Gruß Hagen

[Robert_G]

Kann es sein, dass du mal wieder genau das herausgelesen hast, was du herauslesen wolltest?

[NicoDE]

Zitat von Robert_G:

Kann es sein, dass du mal wieder genau das herausgelesen hast, was du herauslesen wolltest?

Tun wir das nicht alle ?-)

Ich finde die ursprünglich geschriebe Lösung viel zu umständlich. Es ist, meiner Meinung nach, unnötig die Compiler-Flags zu aktivieren und deren ursprünglichen Zustand wieder herzustellen. Ein {$WRITABLECONST ON} in der Unit hätte ausgereicht um das Sprach-Feature zu ermöglichen (und dem lesenden/benutzenden Entwickler mitzuteilen, dass er darauf achten sollte). So muss man erst den gesamten Quelltext lesen um die Abhängigkeiten festzustellen (und sich daran erinnern, was verdammt noch mal der Compiler-Schalter J war ).
Eine Unit ist ebenso ein geschlossenes Gebilde wie eine Funktion, Objekt oder Procedure. Insofern kann man sich darüber streiten, ob die Compiler-Flags im jeweiligen Fall in der Funktion oder in der Unit stehen sollten (Geschmacksfrage...).

[DGL-luke]

Zitat von Robert_G:

Kann es sein, dass du mal wieder genau das herausgelesen hast, was du herauslesen wolltest?

Könnte es sein, dass du mal wieder keine begründungen lieferst für deine behauptungen?

ich würde hagen hier zustimmen: auch prozedurale programmierung kann sauber sein. OOP ist ein schönes modell, das sich mit seinen restriktionen gerade dafür eignet, dass nicht alle im team alles über die arbeit der anderen weiss.

wer aber eine schöne prozedurale unit schreibt und seine funktionen und records schön kommentiert, wird auch nicht mehr verwirrung stiften.

und vor allem macht OOP sehr viel mehr arbeit als prozedurale programmierung. zumindest meines Ermessens(kann auch daran liegen, dass bei mir OOP bis jetzt mit "Komponentenprogrammierung" äquivalent ist und ich da noch nicht ganz durchsteig).

[Robert_G]

Zitat von DGL-luke:

Zitat von Robert_G:

Kann es sein, dass du mal wieder genau das herausgelesen hast, was du herauslesen wolltest?

Könnte es sein, dass du mal wieder keine begründungen lieferst für deine behauptungen?

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...

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.

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...

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?
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...


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

[malo]

Zitat von DGL-luke:

ich würde hagen hier zustimmen: auch prozedurale programmierung kann sauber sein. OOP ist ein schönes modell, das sich mit seinen restriktionen gerade dafür eignet, dass nicht alle im team alles über die arbeit der anderen weiss.

wer aber eine schöne prozedurale unit schreibt und seine funktionen und records schön kommentiert, wird auch nicht mehr verwirrung stiften.

Da stimm ich dir auch vollkommen zu!

Und teilweise finde ich, geht die OOP-Programmierung sogar etwas zu weit. Wenn ich mal an Leute wie Robert denke, die jedes noch so kleine Array durch eine TList/TObjectList ersetzen wollen, und sich dabei nur unnötige Arbeit machen. Dabei find ich Arrays an sich gar nicht so schlimm, ganz im Gegenteil, finde ich sie sehr hilfreich, da sie schnell und einfach einsetzbar sind.

Zitat von DGL-luke:

und vor allem macht OOP sehr viel mehr arbeit als prozedurale programmierung. zumindest meines Ermessens(kann auch daran liegen, dass bei mir OOP bis jetzt mit "Komponentenprogrammierung" äquivalent ist und ich da noch nicht ganz durchsteig).

Ich muss dir auch zustimmen. OOP macht einiges mehr an (Tipp-)Arbeit, was auf Dauer sehr lästig sein kann. Und bei Komponentenprogrammierung hat man ohne OOP schon keine Chance mehr, weil Komponenten prinzipiell OOP aufgebaut sind. 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 (D5 Pro steht zwar im Profil, aber die ist nicht so 100% legal (keine eigene Lizenz bei Schülerversion), deshalb benutz ich sie ungern). Die müssen nämlich alles einzeln machen

[Robert_G]

Und schon gates los...

[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.

[Luckie]

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