|
Globale Variablen und OOP
Hallo zusammen,
meine Kenntnisse was OOP angeht sind ziemlich eingeschrenkt, daher meine Frage, wie geht man richtig vor um Globale Variablen zu vermeiden? z.B. Über einem Button wird einer Variablen ein Wert zugewießen und später wird der Wert abgefragt. Hat da jemand ein kurzes, Beispiel? Oder ein Tutorial? Möglichkeiten wo man da gerne Globale Variablen einsetzen würde, gibt es ja bestimmt tausende. Zudem suche ich ein gutes Buch (sollte auch leicht verständlich sein) über OOP am besten im Zusammenhang mit Delphi, falls möglich in Deutsch. Auserdem bin ich auf der Suche nach Bücher, Tutorials, Scripte, Webseiten,... über Datenbanken mit Delphi 7 und Firebird. Vielleicht hat ja jemand einen Tipp Ich danke schon mal im Voraus Gruß Tankwart |
Re: Globale Variablen und OOP
Im Prinzip ist das Vorgehen recht einfach:
Du machst Dir vorher genaue Gedanken darüber, WO Du diesen Wert überall brauchst. Und dann wirst Du ziemlich schnell sehen, dass das meist nur an zwei, drei Stellen ist, die alle irgendwie zusammenhängen. Dann suchst Du Dir das Objekt aus, zu welchem dieser Wert am ehesten passt und deklarierst den Wert als Property dieses Objektes. That's it. |
Re: Globale Variablen und OOP
Im allgemeinen gehören (nicht lokale) Variablen zu irgendeiner Klasse. Und genau da solltest du sie auch definieren.
Für dein Beispeil wahrscheinlich:
Delphi-Quellcode:
Damit hast du gesichert, dass bei jeder neuen Instanz von TForm1 eine neue Variable (meine_variable1) existiert.
type
TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); procedure FormCreate(Sender: TObject); private { Private-Deklarationen } meine_variable1:integer; meine_variable2:string; public { Public-Deklarationen } function get_meine_variable1:integer; end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.FormCreate(Sender: TObject); begin meine_variable1:=0; end; procedure TForm1.Button1Click(Sender: TObject); begin inc(meine_variable1); end; function TForm1.get_meine_variable1:integer; begin result:=meine_variable1; end; |
Re: Globale Variablen und OOP
Danke für die schnellen Antworten,
das hat mir schon mal weiter geholfen. Habt ihr noch einen Tipp für ein Buch über OOP mit Delphi, oder ein Buch das allgemein das Thema OOP beschreibt. Wo auch beschrieben ist, wie Vernünftig programmiert wird wenn Sourcecode auch in anderen Programmen wieder verwendet werden soll. Irgendwie habe ich in solchen Sachen nicht so recht den Plan, wie ich da vorgehen soll, das der Quellcode nicht jedes mal mortz umgeschrieben werden muss. Tutorials, Scirpte und alles andere sind naklar auch erwünscht. Gruß Tankwart |
Re: Globale Variablen und OOP
Hi!
Ich war mir früher auch unsicher, wo ich am sinnvollsten meine eigentlich Objekt-unabhängigen Variablen (oder globalen Objekte) zuordnen soll. Du kannst z.B. dafür ein schlankes Objekt (oder nur eine Klasse) kreieren, über die du auf diese Variablen zugreifst. Beim Initialisieren kannst du so vorab gültige Werte einstellen. Dieses Objekte würde ich dann in einer allgemeinen Unit zugänglich machen. So trennst du - zumindest ein wenig - die Controls und die Daten-Klassen. Beim Initialisieren kannst du dann Deine Objekte darin erstellen lassen und auch später wieder ordentlich zerstören. Wenn Du - wie du schreibst - eine Variable global ablegen willst, würde ich dafür vielleicht sogar ein Extra-Objekt kreieren, dass für die Verwaltung und Weiterverarbeitung dieses Wertes zuständig ist. So hast du alles rund um diese Sache übersichtlich in einem Objekt. Also z.B. so:
Delphi-Quellcode:
Hier sind als Beispiel Datei-Funktionen vorhanden...
TDataContainer = class
private fValue: integer; procedure SetValue(aValue: integer); public property Value: integer read fValue write SetValue; function WriteToFile(aFilename: string): Boolean; function ReadFromFile(aFilename: string): Boolean; end; Ich empfehle dir unbedingt, dich mehr mit dem Thema "Patterns", also "Muster" zu beschäftigen. Wenn du schon dabei bist, OOP zu lernen, dann ist das gleich ein sinnvoller Weg, zukünftige Aufgaben etwas flexibler und eleganter zu lösen. Im Internet gibt es einige Artikel auf im Bezug auf Delphi, aber viel mehr mit Hilfe von Java und C++/C#. Genauso sieht's bei den Büchern aus. z.B. hier habe ich einiges gefunden:  www.Delphi3000.com (Patterns)Hier als Tipp das Command-, Singleton- und Observer-Pattern Das eigentliche Prinzip der OOP ist jedoch in jeder Programmiersprache gleich. Gruß Pfoto |
Re: Globale Variablen und OOP
Zitat:
Dann hat man keine globalen Variablen mehr, aber ein globales Objekt mit globalen Eigenschaften. :cyclops: Wenn's denn hilft ... Ich verstehe nach wie vor die angeblich vorhandene Notwendigkeit zur Vermeidung von globalen Variablen nicht. |
Re: Globale Variablen und OOP
[quote="IngoD7
Ich verstehe nach wie vor die angeblich vorhandene Notwendigkeit zur Vermeidung von globalen Variablen nicht.[/quote] 1. Durch globale Variablen kann man sich in einem ansonsten objekt-belasteten Programm sehr schnell Fehlerquellen bauen. Deswegen ist immer zuerst zu prüfen, ob die Variable nicht zu einer Klasse zugehörig ist. 2. Ein Datencontainer ist günstig, da du dadurch mehrere Instanzen dieses Containers initialisieren kannst, und dadurch mehrere "globale" Variablen gleichen Namens hast, die du dann auch brauchst. Aber eben nicht immer. 3. Für den Fall der Fälle, dass du ein und dieselbe Variable über mehrere Instanzen deiner Klasse haben willst gibt es Klassenvariablen 4. Wenn das alles nicht hilft, nimm eine gloabel Variable. |
Re: Globale Variablen und OOP
Zitat:
Du musst dir überlegen wann und wo du welche Werte brauchst. Und ob bzw. wie sich diese Werte intuitiv in Klassen modellieren lassen. Nach dem du jetzt weißt wo du sie brauchst musst du dir nur einen oder mehrere Instanzen wählen, die für die eine Referenz darauf halten, und denen man zum Bleistift im Konstruktor diesen Wert übergeben kann. (Muss nicht sein, read/write Properties sind auch OK ;) ) Zitat:
Globale Variablen sind so ziemlich das übelste was dir passieren kann. Denn sie sind
Du verzwirbelst deinen Code so sehr untereinander, dass du einzelne Teile nicht für etwas anderes benutzen kannst. Außer durch Copy'n Waste mit anschließendem Ändern. (wodurch Bug fixes an dem einen nicht zu Bug fixes am anderen werden -> D'oh! :wall: ) |
Re: Globale Variablen und OOP
Vorab:
Der Fragesteller fängt - wie es aussieht - doch gerade erst an mit Delphi und OOP; und da würde ich ihm niemals anraten wollen, krampfhaft auf globale Variablen zu verzichten. Für einen Anfänger ist das nämlich ein Krampf (Datenmodule, eigene Klassen, etc.). Deshalb schrieb ich ja auch von meinem fehlenden Verständnis für eine Notwendigkeit, auf globale Variablen zu verzichten. Es gibt diese absolute Notwendigkeit nicht. Zitat:
Zitat:
Zitat:
Wieso ist ständig von mehreren Instanzen die Rede??? Dass das alles fein geht, bestreitet doch niemand. Aber wer von mehreren Instanzen spricht, denkt eh nicht mehr an globale Variablen, oder? Zitat:
Ich möchte den sehen, der angefangen ist zu programmieren, ohne globale Variablen benutzt zu haben. :cyclops: Es ist m.E. unnötig (gerade am Anfang auch nahezu unmöglich), krampfhaft auf sie zu verzichten. Man kann es natürlich gerne versuchen, und das Begehren, gleich am Anfang der Karriere das "alles richtig" zu machen, ist ja auch lobenswert, aber es ist nicht zwingend notwendig. Mehr wollte ich nicht ausdrücken. Früher oder später wird sowieso jeder den Verzicht auf globale Variablen zu schätzen wissen und sie nach Möglichkeit vermeiden ... aber meistens nicht um jeden Preis. :???: |
Re: Globale Variablen und OOP
Hallo Leute,
globale Variablen sind nicht böse per se. Um genau zu sein sollte man auch eher vom scope (Sichtbarkeitsbereich) einer Variable sprechen. Das Thema wird in der DP sehr oft angeschnitten und ich lese immer wieder bekannte pauschale Ratschläge - deshalb: Als Informatiker wird man auf das Programmieren-im-Großen vorbereitet, die Mehrheit der DP-Mitglieder kommt aber über das Programmieren-im-Kleinen und dass (nicht nur dort) Variablen sehr schnell mal mit maximalem Scope deklariert werden, ist nachvollziehbar - eine Form von Bequemlichkeit. Das Problem sind die später häufig auftretenden Seiteneffekte, wenn ein Wert benutzt wird, der zwischenzeitlich von einer anderen Prozedur verändert wurde. Formale Vorbildung und praktische Erfahrung führen früher oder später zur einer Disziplin: Eine Variable wird anhand der eigenen Erfahrung mit der minimalen Sichtbarkeit ausgestattet, die den aktuellen Anforderungen genügt. Ändern sich diese Anforderungen, dann ist der Scope der Variablen anzupassen. Es ist ein langer Weg hin zur Programmierung nach den Regeln der Kunst und der Weg hat Schleifen und Sackgassen, aber der erste Schritt ist unzweifelbar: Informiert euch gewissenhaft über die sprachlichen Möglichkeiten (scope rules) der Programmiersprache. Wer die verstanden hat, der ahnt auch schon wie er diese Möglichkeiten zu seinem Vorteil nutzen kann. Danach gilt "Übung macht den Meister". Freundliche Grüße |
Re: Globale Variablen und OOP
danke für die vielen Antworten,
es hat mir auf alle Fälle weiter geholfen. Vielleicht kennt ja noch einer ein gutes Buch zum Thema OOP, vorzugsweise in Delphi, wo auch beschrieben ist, wie man richtig vorgeht um Wiederverendbaren Quellcode zu schreiben. Über Webseiten, Scripte, Tutorials,.. freue ich mich auch mfg Tankwart |
Re: Globale Variablen und OOP
Tutorial:
http://delphitutorials.michael-puff.de |
Re: Globale Variablen und OOP
@marabu
Das ist sehr schön beschrieben! :thumb: |
Re: Globale Variablen und OOP
Ingo hat schon Recht ! Wahrscheinlich hat der Fragesteller des öfteren gesehen, dass von globalen Variablen abgeraten wird. Unter anderem von mir auch. :mrgreen: Aber das darf man doch nicht dogmatisch sehen. Manchmal fliegen aber tatsächlich die Kanonenkugeln auf Spatzen und es werden, wie angesprochen Properties, Setter usw. verwendet. Auch das ist Anfängerstil, genauso wie an allen Ecken und Kanten globale Variablen zu benutzen.
Was ist denn nun genau zu tun ? Die Faustregel lautet : Sichtbarkeit möglichst klein halten. Also : Variable zumindest mal in der Form halten. Wenns geht in den private Teil. Da gehören sie hin, es sei denn etwas wird vererbt. Variablen auch lokal innerhalb der jeweiligen Prozeduren deklarieren. Ist das gelungen, dann ist schon viel gewonnen. Es ist eben hauptsächlich genau zu überlegen, wo und wann eine Variable gebraucht wird. Gegenbeispiele für globale Variablen gibts nämlich auch. Beispiel : brauche einen konstanten Wert überall im Programm. Ganz klar : ist eine Konstante. Den Wert kann ich aber trotzdem nicht als CONST deklarieren, weil er vom Einsatzort abhängt und auch geändert werden kann. Der kommt eben aus INI-Datei. Er wird beim Programmstart einmalig gelesen und während der Ausführung des Programmes verwendet. Ich wäre schön blöd, den für jede Form an eine private-Variable zu übergeben oder mich mit Properties oder sonstwie zu verrenken. :zwinker: wg. roter Kasten : Marabu hat auch Recht. Rest : siehe oben. |
Re: Globale Variablen und OOP
Zitat:
Und der krampfhafte Teil kann für den Anfänger eine ganz gute Lehrstunde sein wann es sich denn wirklich lohnt den Weg zu gehen und wann nicht. Wieviel Aufwand es anfangs, einmalig, macht, und wie viel man sich später beim Arbeiten am Projekt spart. Er kann dann einfach besser einschätzen. ob es sich lohnt einen Notepad-clone hinzuschludern, oder es "richtig" zumachen. Zitat:
Zitat:
Zitat:
Wichtig ist halt immer, dass Code nur das sieht was er muss und auch nur abhängig ist von Dingen, von denen er abhängig sein muss. Code, der globale variablen oder Singletons[1] nutzt kann man nicht mal eben erweitern um gewissen Aufgaben parallel (read: multithreaded) zu erledigen. Das war der Teil zu Skalierbarkeit. Die Frage der Wiederverwendbarkeit stellt sich bei Singletons/globalen variablen wahrscheinlich gar nicht erst. Zitat:
Nur IMHO muss man sich mit Hansa'schen "passt schon"-Tipps gerade bei Anfängern etwas vorsehen. ;) [1]die können thread safe gemacht werden, aber die nötigen Sperren fressen dir irgendwann die CPU weg. |
Re: Globale Variablen und OOP
Hi,
erstmal möchte ich hier dem marabu völlig zustimmen. In kleinen Projekten werden sich die Konsequenzen der Implementierungs-Entscheidungen doch stark in Grenzen halten. Hier arbeiten häufig nur einzelne Personen dran (die den vollen Überblick über alles haben) und Erweitern/Warten wird auch eher selten der Fall sein (insbesondere würde es die selbe Person übernehmen und das wohl eher in kurzem Abstand zur Veröffentlichung). Zitat:
Vorallem lässt sich das ganze (imho) schlecht modellieren. Der eigentlich Sinn der OOP ist es doch letztlich nicht Objekte zu erstellen oder über Klassen zu sprechen. Ich denke eines der wichtigsten Konzepte der OOP steckt in der Abstraktion. Man kann hier sehr schön abstrakt modellieren und die eigentliche Implementierung bleibt von außen völlig verborgen. Man kennt ebend nur die öffentlichen Schnittstellen und hat aut. austauschbare und wiederverwendbare Teile. Das Wort Teile ist natürlich sehr schwammig, korrekter könnte man hier schon von Komponenten sprechen. Doch dazu möchte ich dann auch gleich sagen, dass eine Komponente (in der Informatik) nichts mit einer bestimmten Vorfahrklasse (z.B. TComponent), nicht mal direkt etwas mit OOP zu tun hat. Man kann aber OOP-Sprachen als Komponenten-Modell auffassen, die Klassen als Komponenten und die Objekte als Komponentenexemplar. Die Vorteile solcher Komponenten sollten dann auch klar sein, man kennt nur ihre Schnittstellen nach außen und kann eine weitere Komponente einfach aus mehreren anderen Komponenten (und etwas Glue-Code) zusammensetzen. Dieses "Lego-Prinzip" ist sehr mächtig, da man hier jede Komponente gegen eine mit gleicher Schnittstelle austauschen kann, ohne dass dies das restliche Programm verändert. So ist es dann leicht möglich fremde Komponenten (z.B. zugekauftes Know-How/Expertenwissen) einfach in ein Programm zu integrieren. Ist diese Komponente noch nicht verfügbar, steht aber die Schnittstelle fest, kann man z.B. mit einer Dummy-Komponente (gleiche Schnittstelle aber nur Dummy-Funktionalität) schon am restlichen Programm arbeiten und diesen Dummy später durch die echte Implementierung ersetzen. Ok, bin etwas vom eigentlichen Thema abgeschweift, was? Na ja, wie bereits gesagt, der marabu hat das eigentlich Wichtige (imho) schon sehr viel besser auf den Punkt gebracht. Gruß Der Unwissende |
Re: Globale Variablen und OOP
Zitat:
Nehmen wir zum Beispiel Leute die mit Haskell anfangen (z.B. die Studenten an der FU-Berlin, die noch nicht Programmiert haben und die sollte es dort immernoch geben). In Haskell (funktionale Programmiersprache) sind globale Variablen nur mit Monaden möglich. Monaden erfordern aber schon ein eher fundiertes Basiswissen, hier fangen also jedes Jahr noch Leute an zu programmieren ohne eine globale Variable zu verwenden. Aber auch Java-Programmierer haben das Problem, dass es keine globalen Variablen gibt. Hier können Variablen nur in Klassen deklariert werden. Diese Variablen können natürlich Klassenvariablen sein (sind dann statisch). Es dürfte noch sehr viele weitere Sprachen geben, wo es schon technisch nicht möglich ist. Für die Sprachen in denen es möglich ist (z.B. Delphi, denke Du beziehst dich darauf), würde ich nicht pauschal ausschließne, dass jmd. auch ganz ohne globale Variablen anfing. Immerhin kommt es hier doch eher auf die Lehre an. Wird Dir nur das Konzept der OOP erklärt... Allerdings halte ich es auch für eher unwahrscheinlich und äusserst selten, dass jmd. hier eine Einführung ganz ohne globale Variablen bekommt/diese nicht verwendet. |
Re: Globale Variablen und OOP
Zitat:
|
Re: Globale Variablen und OOP
Zitat:
Heute, wo man sogar schon in Delphi mit dem Button "Neu" gleich die erste Klasse (TForm1) hingeklatscht bekommt, kann man schon als Neuling komplett und einfach ohne globale Variablen programmieren. Und von den mittlerweile zahlreichen reinen Objektsprachen brauchen wir ja gar nicht reden. Früher, unter Turbo Pascal, wo man sich zu Beginn seines Programmes erstmal einen globalen Variablenpool zurecht gelegt hat, wo OOP noch ein Vision (um nicht zu sagen eine TVision) war...... Heute kann man als Anfänger sich gleich mal prinzipiell daran gewöhnen, alle Variablen in die Formularinstanz zu legen. Schaden tut dies nicht. [OT] Edit: Wenn man es so sieht, erscheint ja TVision vor einem ganz anderen Hintergrund. :spin2: [/OT] |
Re: Globale Variablen und OOP
Zitat:
Natürlich, gibt es eine globale Variable die nur gelesen werden soll, dann wird das ja auch jeder tun. Wer das anders macht, der hört einfach mit dem Programmieren auf, bin mal gespannt wie gefragt dann Programmierer bald wieder sein werden. Die Idee der unterschiedlichen Sichtbarkeit verschiedener Methoden und Variablen erhielt doch nicht grundlos einzug in einige Sprachen. Also soweit ich das beurteilen kann, wird schnell alles falsch gemacht, was man falsch machen kann. Natürlich nicht alles, aber unter Zeitdruck schleichen sich dann doch schneller kleine Unsauberheiten ein und die führen dann zu Fehlern und die sorgen wiederum für Kosten. Kann mir nicht vorstellen, dass Du noch nicht die Erfahrung gemacht hast, dass Konsequenz immer Priorität haben sollte. Eine solche Ausnahme (für einen sehr konstruiert einfachen Fall) führt schnell zu einer Zweiten und Dritten und dann hat man wieder die Probleme, dass sich jmd. falsch merkt (nie nachliest) dass ein paar der Variablen nur gelesen werden sollen. Da dürfte das Finden eines solchen Fehlers doch deutlich den Aufwand einer sauberen Implementierung überwiegen. Natürlich bedarf es in einem solchen Fall noch lange nicht einem Objekt, aber eine "globale" Funktion, die einfach nur diesen Wert zurückgibt und eine nicht für jeden sichtbare Variable sollten doch um einiges sauberer und sicherer sein (und ganz ehrlich, ich sehe in Sicherheit vor so leicht vermeidbaren Fehlern nichts überflüssiges). [Add] Zitat:
[/Add] |
Re: Globale Variablen und OOP
Moin Sirius,
Zitat:
|
Re: Globale Variablen und OOP
Zitat:
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. |
Re: Globale Variablen und OOP
Zitat:
|
Re: Globale Variablen und OOP
Zitat:
|
Re: Globale Variablen und OOP
Zitat:
Zitat:
Zitat:
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:
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). |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 21:57 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz