|
Programmierdogmata
Hallo Programmierfreunde!
Was ich jetzt erstelle, brennt mir schon seit Tagen unter den Nägeln, nun ist es wegen  dieses Beitrages soweit.Im Verlaufe meiner mehrjährigen Forumsaktivität stieß ich auf mehrere Grundsätze, die ich teilweise bis gar nicht nachvollziehen kann. Just fallen mir drei ein: 1. Die Verteufelung des GOTOs. Sog. Spaghetticode mag auch ich nicht, aber wenn er funktioniert, ist gegen ihn nur einzuwenden, daß er schwierig nachzuvollziehen ist. Wer es so gewohnt ist, wer so am besten denken kann und fehlerfreie Ergebnisse liefert, dem solle man das so machen lassen, vor allem, wenn er für sich selbst programmiert und die Quellcodes aus gutem Willen beilegt. Ein dosiertes Verwenden dieses Sprungbefehles kann Code kürzer, effizienter und schneller machen. Machen wir uns nichts vor: break und exit sind verkappte GOTOs, die all' die zufrieden- und ruhigstellen sollen, die das GOTO scheuen wie der Teufel das Weihwasser (ich nicht). 2. Die Ablehnung globaler Variablen. Auch, wenn man keine explizit formuliert, so gibt es diese jedoch in Form z.B. bei der VCL-Programmierung in Form der Formulare (hier zeigt sich übrigens, daß exakter Ausdruck notwendig ist, denn wie verständlich wäre wohl "in Form der Forms"?!). Wenn der Compiler globale Variablen akzeptiert und dabei nicht mal mit Hinweisen oder gar Warnungen daherkommt, was ist daran so verdammenswert? 3. Die Forderung, Oberfläche und Rechenteil zu trennen. Dauern Berechnungen länger, ist die Oberfläche bei nur einem VCL-Thread unbedienbar, dann kann ich diese Forderung nachvollziehen. Doch was ist mit der Speicherung? Warum z.B. soll man ein StringGrid neben der Darstellung nicht gleich auch noch für die Speicherung derselben Daten verwenden (mißbrauchen?), wenn es dafür doch grundsätzlich geeignet ist, insbesondere, wenn man nur mit Strings operiert (ansonsten kommen lästige Konvertierungen hinzu)? Speichert man die angezeigten Daten "extra", so erhöhen sich m.E. tendenziell Quellcode (Übersichtlichkeit!) und Compilatsgröße. Gerade bei meinen 1-Mann-Projekten und begrenzten Programmierfähigkeiten ist es wichtig, den/die Quellcode(s) möglichst kompakt zu halten. Vielleicht fallen Euch noch mehr solcher Grundsatzforderungen ein, die auf mich in ihrer reinen Form, ich nenne es ganz deutlich, die Tendenz zum Dogma erkennen lassen. Wie sind Eure Meinungen dazu? Gruß Delphi-Laie Ergänzung: 4. An der Strukturierung der Quelltexte (Einrückungen usw.) scheiden sich auch regelmäßig die Geister bis hin zu ideologischen Grabenkriegen. |
AW: Programmierdogmata
Hallo,
Ich denke, dass du ein paar Tage zu spät drin bist ! Der 1. April ist bereits vorbei. Heiko |
AW: Programmierdogmata
Nur kurz:
1. Übermäßiges benutzen von goto macht den Code schlechter lesbar. Das ist wie mit Asbest: Am Anfang klingt das nach ner tollen Idee, aber wenn man dann nach ein paar Jahren nochmal ran soll hat man den Salat. Als "dosiertes Verwenden" lasse ich hier vielleicht so ein goto auf 30000 Zeilen gelten. Und man tut sich selbst i.d.R. einen Bärendienst, weil das dann "Einwegcode" wird. Möchte man in nem Jahr nochmal etwas größeres dran ändern ist das Horror. 2. Im Grunde siehe oben. Macht den Code tendenziell schwerer nachzuvollziehen und geht somit in die Richtung "Heute spare ich 15min, kostet mich morgen 1h. Aber erst morgen!!" 3. Äh ja, sobald du was anderes als Strings hast? Gibt so Zahlen und so ;-) Auch wenn du lange Listen mit Daten hast und eine Art "Filterfunktion" anbringst: Du entfernst einfach alle Daten aus der Anzeige, die nicht mit dem Filter übereinstimmen. Aber ja, das ist auch wieder ne Frage wie komplex das Programm ist. Zudem wird das Testen und umwandeln einfacher: Die eine Funktionalität auch als Konsolenprogramm? Kein Problem: Funktion rüberkopieren und ein bisschen Eingabelogik in die Main-Function. Oh, ein Bug aufgetaucht? Einmal fixen, copy paste zurück. Ein Level weiter ist dann, dass sich beide Versionen Quelltextdateien teilen. und somit wirklich den gleichen Algorithmus benutzen. Allgemein hat das also eher mit der Komplexität zu tun: Bei einfachen Programmen kann man sich auch leicht wieder reindenken. Bei großen Programmen geht das nicht so einfach, da spielt dann die Wartbarkeit eine tragende Rolle. Zitat:
Hehe, ich habe mir gerade mal Codemetriken von VS generieren lassen, für mein aktuelles Projekt: Zitat:
Jetzt bräuchte ich da nur noch Vergleichswerte :stupid: |
AW: Programmierdogmata
Alle 4 genannten Punkte wurden in (nicht nur) diesem Forum schon bis zum bitten Ende durchdiskutiert.
|
AW: Programmierdogmata
Hallo,
da hat Daniel natürlich recht und die meisten Diskussionen verwandeln sich tatsächlich spätestens nach dem 5. Post in Glaubenskriege. Man muss sich darüber im klaren sein, dass man, sofern man in einem Team arbeitet, den Code nicht für sich selbst, sondern immer für den nächsten Entwickler schreibt, der sich damit auseinandersetzeen muss (diese Erkenntnis stammt nicht von mir, ich stimme ihr aber zu). Insofern geht es m. E. weniger darum, ob Goto, Exit usw. Teufelszeug sind oder nicht, sondern dass klare Regeln existieren, an die sich alle halten. Bei uns im Haus gibt es ein mehrseitiges Dokument, in dem möglichst genau (d. h. bis hin zu Einrückung und Groß/Kleinschreibung) festgelegt ist, wie Quelltext zu erstellen ist, welche Anweisungen zu verwenden sind (und welche nicht) und wie er auszusehen hat. Das Ergebnis ist von allen lesbarer und nachvollziehbarer Code. Jeder muss natürlich für sich selbst entscheiden, ob das für ihn Sinn macht oder nicht (und als Einzelentwickler ist es vielleicht nicht so wichtig), aber wenn man im Team arbeitet, ist meiner Erfahrung nach ein solches Dokument eine enorm große Hilfe. Gruß Frank |
AW: Programmierdogmata
Hi, mein Senf:
Grundsätzlich kannst Du so schlampig programmieren, wie Du willst. Aber wenn Du dich stetig verbessern willst, dann schreib die besten und saubersten Programme der Welt. 1. Die Verteufelung des GOTOs. GOTO wird nie benötigt. Du kannst ein 'break', 'exit' oder 'return (xy)' verwenden. Und wenn man Clean-Code verfolgt, ist selbst ein 'break' unnötig. 2. Die Ablehnung globaler Variablen. Globale Variablen bedeuten, das Du faul bist und dir keine Gedanken über dein Systemdesign gemacht hast. Ganz ohne globale Variablen kommt man aber manchmal nicht aus. Allerdings sollte dein Bestreben sein, sie wen Möglich zu vermeiden. Die Gründe kannst Du im Netz und im Forum nachlesen. In modernen Sprachen sind die globalen Variablen/Singletons hinter statischen Klassen versteckt, was (fast) aufs Gleiche rauskommt, aber nicht so auffällt ;-) 3. Die Forderung, Oberfläche und Rechenteil zu trennen. Hiermit ist gemeint, das die Logik nicht hinter einem 'Button1_Click' ausprogrammiert werden sollte ("Trenne Funktion und Design"). 4. Strukturierung der Quelltexte (Einrückungen usw.) Tu es einfach. Wenn mir das nicht gefällt, jage ich es durch meinen eigenen Formatierer und wir müssen uns darüber nicht streiten. Aber sorge Du dafür, das deine Einrückung konsistent und automatisierbar ist, denn ich hab keine Lust, mir dein Gemecker anzuhören, weil Du die Gleichheitszeichen immer in Spalte 39 haben willst und kein Formatierer der Welt das so für dich hinbekommt. Zitat:
|
AW: Programmierdogmata
Ich muss meinen Vorrednern da einfach zustimmen.
Nur weil man etwas verwenden kann, heißt das noch lange nicht, dass man es verwenden muss. Wenn man wirklich sauberen und durchdachten Code schreibt, dann sind Dinge wie globale Variablen, GOTOs, Do Withs, etc. völlig unnötig. Naja, fast unnötig. Ich habe in den meisten meiner Anwendungen auch globale Variablen. Allerdings beschränke ich die immer gerne auf folgende Definition
Delphi-Quellcode:
Im 'tv' werden alle globalen Werte gespeichert, die für diesen Thread notwendig sind.
threadvar
tv: TThreadVars; var pv: TPublicVars; Zum Beispiel ein Pointer auf den aktuellen Indy-Thread, oder ggf. noch eine Benutzerreferenz. Im 'pv' stehen Werte für die aktuelle Programmversion, der Anwendungspfad, der Logpfad, etc. Somit reichen 2 globale Variablen, die intern eine Klasse oder ein Record sind aus, um diverse Konfigurationsmöglichkeiten durch die ganze Anwendung zu schleifen. |
AW: Programmierdogmata
Zitat:
Also, der nächste Entwickler bist in den meisten Fällen du selbst. Es ist also in deinem eigenen Interesse, den Code so wartbar wie möglich zu gestalten. Dabei ist es nicht wichtig, welche Codier-Regeln du verwendest - Hauptsache du verwendest überhaupt welche. |
AW: Programmierdogmata
Danke an alle!
Was ich nun doch herauslas: Kleines, also vereinzeltes Ausbrechen aus dieser Regelmenge ist also manchmal doch vorteilhaft. Und genau das ist nämlich auch mein Empfinden. Nur darum ging es mir. Zitat:
Zitat:
|
AW: Programmierdogmata
Hallo,
bisher verfolge ich die Diskussion mit wachsendem Interesse und wollte mich eigentlich nicht äußern. Aber: Zitat:
Bitte den Umgangston etwas mäßigen! :evil: Beste Grüße Mathematiker |
AW: Programmierdogmata
Zitat:
|
AW: Programmierdogmata
Naja... Wenn man es auf Haarspalterei auslegt, dann kann eine Anwendung, die nicht mindestens eine
globale Variable beinhaltet gar nicht existieren ;-) Oder zumindest in den seltensten Fällen... |
AW: Programmierdogmata
Zitat:
|
AW: Programmierdogmata
Zitat:
|
AW: Programmierdogmata
Zitat:
Zitat:
Zitat:
Das mit den globalen Variablen dauert etwas, bis man kapiert, weshalb sie 'böse' sind. Im Endeffekt geht es hier im Wiederverwendbarkeit einzelner Module. Das wird genau dann schwer, wenn sie von globalen Variablen abhängig sind. Denn dann sind sie eben nicht unabhängig. Daher ist es auch sinniger, sie in statische Klassen zu packen, dann muss man sich wenigstens nicht damit herumschlagen, ob die globale Variable überhaupt instantiiert ist. Man kann auch mit Singletons arbeiten, die aber auch wieder 'böse' sind (eben wegen der o.g. Abhängigkeiten). Es gibt natürlich Singletons, die da sein müssen, z.B. ist die Festplatte oder der Bildschirm so ein schönes Beispiel. |
AW: Programmierdogmata
Zitat:
1) GOTO ist für mich ebenso wie ein Break eine Todsünde. Allerdings muß ich gestehen, das ich Sourcen gesehen habe wo beides augenscheinlich sinnvoll eingesetzt wurde. 2) Globale Variablen sind zu vermeiden, manchmal geht es allerdings nicht ohne. 3) Oberfläche und Berechnung trennen. Spätestens wenn eine zusätzliche oder abgeänderte Funktionalität benötigt wird, oder aber z.B. die darunterliegende DB sich ändert, erkennt man die Notwendigkeit dieser Trennung. 4) Code Formatieren ist reiner Selbsschutz, da dann der Code leichter zu überblicken ist. Ob man
Delphi-Quellcode:
oder
if b then
begin end
Delphi-Quellcode:
nutzt ist meiner Meinung nach Geschmackssache, hingegen
if b then begin
end
Delphi-Quellcode:
ist nicht so toll.
var
i,j,k,l,cnt,top,base : integer; Gruß K-H a |
AW: Programmierdogmata
@p80286
Nenn doch mal ein Beispiel, wo eine globale Variable sinnvoll ist. |
AW: Programmierdogmata
Hallo,
Zitat:
Zitat:
Was wird wohl auf mich zutreffen? :gruebel: Mathematiker |
AW: Programmierdogmata
Hallo,
ich muss sagen ich glaube daran, dass nur die eigenen Erfahrungen einem selbst wirklich etwas bringen. Mir ist auch erst durch das Anpassenmüssen fremden Codes klar geworden, wie schlecht nachvollziehbar das Verhalten eines Programms sein kann, wenn globale Variablen innerhalb einer Routine gesetzt werden (und nicht Objektfelder sind oder in der Signatur übergeben werden) und damit Auswirkungen auf alles mögliche andere hat - man sucht sich den Wolf, bis man kapiert hat, wo der Hase langläuft. Vorher hatte ich überhaupt kein Problem mit globalen Variablen zum Beispiel. Ich setze auf die Erfahrung, es abstrakt zu vermitteln ist meiner Ansicht nach schwierig. Beste Grüße Caps |
AW: Programmierdogmata
Zitat:
Gruß K-H |
AW: Programmierdogmata
Zitat:
Edit sagt: Man kann sich drüber streiten... Ich verteufel globale Variablen nicht pauschal, es gibt einige Situationen, in denen die praktisch und nützlich sind, aber man muss eben sehr gewissenhaft damit arbeiten und sie nicht an jeder Stelle, an der es gerade möglich ist, in den Quellcode hauen. Ich habe auch schon sinnige Anwendungsfälle für Do With gesehen, und teilweise auch schon Situation, in denen man mit einem Goto arbeiten könnte (KÖNNTE!, nicht MUSS!) Regeln sind dafür da, das sie auch einfach mal gebrochen werden müssen, sonst würde keine Innovation existieren, aber man muss eben immer abwägen, ob es wirklich einen Vorteil bringt und man sich bzw. dem nächsten Programmierer damit Arbeit spart, oder ob man in dem Moment einfach zu faul ist, um es richtig zu programmieren... Ich denke, dass 90% des sauberen Codes einfach damit zusammenhängt, dass man beim Entwickeln nachdenkt und nicht gerade irgendwas reinhackt, was zufällig passt, bzw. sich Quellcode von den verschiedensten Stellen zusammen klaut. |
AW: Programmierdogmata
Zitat:
Und Application als globale Variable habe ich auch nicht zu verantworten und kann ich auch nicht ändern (außer kein Delphi mehr zu benutzen). Ich bin für meinen Code primär und für die 3rd-Party-Libs sekundär verantwortlich und primär gibt es bei mir keine globalen Variablen (nein ich lösche die automatisch erzeugten Form-Variablen nicht - das ist mir zu affig, aber ich benutze diese auch nicht). @p80286 Für beides gibt es sinnvolle(re) Alternativen. Zumal für das Loggen sich eine Klasse empfiehlt, die in ihrer Instanz den Dateinamen verwaltet. |
AW: Programmierdogmata
Zitat:
Mal sehen Wie ich die "Globalen" ausrotten kann. Gruß K-H |
AW: Programmierdogmata
Zitat:
Haben ja auch fast alle Probleme, die generell mit globalem State auftauchen. Eine Ausnahme, die mir gerade in den Sinn kommt, wären immutable Objekte. Da sollte es keine Probleme mit Threads und anderen Nebenläufigkeiten geben. Aber auch die können per DI oder schlicht als Parameter durchgeschliffen werden. |
AW: Programmierdogmata
Ich sehe trotzdem kein Problem darin eine globale Thread-Variable anzulegen, die ggf. nötige Referenzen auf Sessions
oder das Eltern-Thread-Objekt beinhaltet. Ob da nun eine Klasse, eine Referenz, ein Record oder sonstwas hinter steckt ist in dem Fall erstmal egal. Das ist in meinen Augen eine saubere Lösung und sie ermöglicht es an jeder Stelle im Thread darauf zuzugreifen, ohne, dass ich sie in jeder Klasse durchschleifen bzw. sichtbar machen muss. |
AW: Programmierdogmata
Zitat:
Das Böse an globalen Variablen ist doch, dass diese eingesetzt werden, wo es sich absolut nicht um etwas Globales handelt und durch die Verwendung bekomme ich Abhängigkeiten die die Wiederverwendbarkeit nicht zulässt. Wie schon festgestellt wurde, gibt es aber durchaus die Anforderung nach einer einzigen globalen Instanz, die naturbedingt auch nur einmal pro Anwendung vorkommen kann (Application, Screen, etc.). Nimmt man hier aber jetzt eine globale Variable, so kann diese Variable auch übereschrieben werden, ohne dass die abhängigen Teile darüber informiert werden. Gerade im Thread-Umfeld muss auch bedacht werden, dass eine globale Variable eben nicht threadsafe ist. Somit ist das in so einem Umfeld der vorgeplante Schuss ins Knie. |
AW: Programmierdogmata
Zitat:
Zum Thema 'globale Variablen'. Meine Meinung: Einfach nicht verwenden. Wenn schon, dann in ein Singleton-Pattern packen. Und pro Singleton eine Kiste Bier/Brause für die Entwickler. Man muss das wirklich begründen und wenn alle einverstanden sind, dann ist die Welt in Ordnung. |
AW: Programmierdogmata
Es gibt noch zwei Aspekte die hier noch nicht angesprochen wurden:
1.) Unit-Tests Wenn man mit Software Geld verdienen möchte und Softwareentwicklung im grösserem Rahmen betreibt, dann braucht man Unit-Tests.Das bedeutet aber auch dass die Software so geschrieben werden muss, dass sie sich überhaupt testen lässt. Globale Variablen und Singletons wirken sich extrem störend auf die Testbarkeit von Klassen und Funktionen aus. Das gleiche gilt auch wenn die Benutzeroberfläche und die tiefere Logik nicht getrennt sind. 2.) grosse Anwendungen (> 500 Delphi Units) Bei grossen Anwendungen können kleine Änderungen in den Anforderungen grosse Probleme verursachen wenn die Architektur nicht sauber ist. Kleines Beispiel aus der Praxis: Eine Anwendung aus dem Bereich der Logistik soll "mandantenfähig" gemacht werden; d.h. es soll mit mehreren Mandanten statt bisher nur einem umgehen können. Das Problem war aber dass die zum Mandanten gehörenden Daten in einem globalen Objekt gespeichert wurden
Delphi-Quellcode:
Auf diese globale Objekt greifen aber hunderte Units zu.
var
AdrMandant : TAdresseMandant; // enthält Name, Anschrift, Tel, EMail, Fax, Kontoverbindung, Umsatzsteuernr,... Wenn man die Mandantendaten ändert weil man z.B. eine Rechnung drucken möchte, dann hat das globale Auswirkungen auf die ganze Anwendung. Letztendlich wurde die globale Variable vernichtet und vielen Klassen wird jetzt das Mandantenobjekt von Aussen übergeben. Diese Umbauarbeiten haben hunderte Stunden an Arbeit gekostet und sich über ein dreivirtel Jahr hingezogen. Beispiel 2: Ein Kunde wollte den Rechnungsdruck nicht über die Benutzeroberfläche starten, sondern über TCP/IP aus einem anderen System anstossen. Leider ist aber die Benutzeroberfläche, die Datenbankzugriffe und die Logik auf einem Formular so verzahnt, dass man den Rechnungsdruck nur per Mausklick starten kann. Bis heute hat sich daran nicht geändert, weil sich niemand traut an dem komplexen Gebilde etwas zu ändern. |
AW: Programmierdogmata
Zitat:
Aber wenn ein Entwickler auf die Idee kommt eine globale Variable wie Application zu überschreiben, dann gehört er gehörig gesteinigt und daran ist nicht die globale Variable schuld. Gerade Application sehe ich aber eher als gute globale Variable. Wie gesagt, wenn jemand anfängt sowas zu überschreiben, dann ist nicht die Variable schuld. |
AW: Programmierdogmata
Zitat:
Delphi-Quellcode:
einfach
var
Application : TApplication;
Delphi-Quellcode:
zu schreiben. (Die Erzeugung von TApplication hab ich jetzt raus gelassen).
function Application : TApplication;
implementation var _Application : TApplication; function Application : TApplication; begin Result := _Application; end; Das kann man aber auch wirklich keinem zumuten :roll: |
AW: Programmierdogmata
Application ist ein ebenso zweifelhaftes 'gutes' Beispiel gegen die Verwendung von globalen Variablen. Im Kontext einer VCL-Anwendung ist das Application-Objekt existentiell, d.h. Abhängigkeiten eines VCL-Objektes vom Application-Objekt sind systemimmanent.
Nur die Umsetzung des globalen/singulären Zugriffs sollte eben -wie von Sir Rufo beschrieben- über ein Singleton-Pattern laufen. Andere Beispiele für den globalen Kontext sind z.B. Benutzereinstellungen (die 'INI-Datei') oder auch der Bildschirm und generell die Hardware, wobei der globale und exklusive Zugriff nicht in allen Bereichen notwendig ist. |
AW: Programmierdogmata
Zitat:
Spätestens beim Einsatz der zweiten Unit, wird das doch so komplex, daß man eine saubere Schnittstelle braucht und sich nicht auf "das steht da irgendwo in der..." zurückziehen kann. Eben darum sollten ja auch die Daten von der Oberfläche getrennt sein. Ich bin viel zu faul (je weniger Aufwand für ein Ergebnis desto besser) als daß ich mir so etwas antuen würde. Gruß K-H |
AW: Programmierdogmata
Zitat:
Manchmal muss man sich einfach selbst zwingen, solche Dinge rechtzeitig zu bereinigen. Unterm Strich spart man dann doch wieder Zeit. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 05:45 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-2025 by Thomas Breitkreuz