Zugreifen auf Variablen innerhalb einer Funktion.

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Sirius3
User
Beiträge: 17741
Registriert: Sonntag 21. Oktober 2012, 17:20

Returnwerte machen bei einer GUI-Anfrage keinen Sinn. Jedes nicht-triviale GUI-Programm braucht OOP und Du solltest die Geschäftslogik von der Darstellung trennen.

Code: Alles auswählen

def transf_geld(konto1, konto2, menge):
    betrag1 = konto1.get()
    betrag1 -= menge
    konto1.set(betrag1)
    betrag2 = konto1.get()
    betrag2 += menge
    konto2.set(betrag2)
    
button_atm_abheben_200.configure(command=partial(transf_geld, balance_bank, balance_cash, 200))
Benutzeravatar
__blackjack__
User
Beiträge: 13079
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@Spedex: So geht das nicht. `balance_bank.get()` und `balance_cash.get() werden da nur *einmal* am Anfang aufgerufen und die Rückgabewert werden dann als feste Werte per `partial()` gebunden, das heisst jeder Aufruf von `transf_geld()` bekommt die gleichen Werte für `konto1` und `konto2` übergeben. Und die Funktion die als `command` übergeben wird darf immer noch keinen Rückgabewert haben. Also sie darf schon, aber es macht halt immer noch keinen Sinn weil die GUI-Hauptschleife nichts damit anfangen kann und den Rückgabewert einfach ignoriert.

Du müsstest die `IntVar`/`DoubleVar`-Objekte an die Funktion übergeben. Dann kann man dort in der Funktion sowohl die Werte auslesen als auch setzen. Und wenn das dann noch auf Labels angezeigt werden soll, dann müssen auch die `Label`-Objekte als Argumente übergeben werden. Und dann sind wir so langsam an dem Punkt wo für meinen Geschmack schon fast zu viel übergeben wird und man das objektorientiert lösen sollte.

Namen sollte man nicht durchnummerieren. Bei `konto1` und `konto2` muss man beispielsweise raten in welche Richtung der Transfer passiert. Das sollte man an den Namen ablesen können.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Spedex
User
Beiträge: 54
Registriert: Mittwoch 29. Januar 2020, 03:27

Aha jetzt funktioniert es. Ich hab das gleiche auch mit add_cash() gemacht, da ist man dann flexibler. Vielen Dank.
Das mit .get() und .set() scheint ja wirklich praktisch zu sein. Ist das nur Tkinter vorbehalten oder kann man das in genau dieser Art und Weise (set und get innerhalb Funktionen) generell in Python anwenden?
Benutzeravatar
sparrow
User
Beiträge: 4187
Registriert: Freitag 17. April 2009, 10:28

IntVar sind Objekte. set und get deren Methoden.
Das hat also nichts mit Python zu tun, insbesondere weil das aus Tkinter/tcl kommt.

Es kann natürlich ein ähnliches Verhalten bei anderen Klassen geben. Wenn sie gleiche Methoden enthalten.
Benutzeravatar
__blackjack__
User
Beiträge: 13079
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@Spedex: Du kannst Dir auch selbst so etwas wie die `tkinter.Variable`-Klassen schreiben, aber das macht wenig Sinn genau *einen* skalaren Wert eines Grunddatentyps so allgemein in einem Objekt zu kapseln. In `tkinter` wird das nur gemacht weil Variablen in Tcl ”observable” sind (`trace*()`-Methoden auf `tkinter.Variable`) und weil Tcl eigentlich ”stringly typed” ist, also alles dort eine Zeichenkette ist und man auf Pythonseite das konvertieren zwischen Tcl und Python mit den verschiedenen `Variable`-Untertypen beim setzen und abfragen der Werte irgendwo machen muss. So ein `tkinter.Variable`-Objekt macht also mehr als einfach nur einen Wert per trivialen Getter/Setter zu kapseln.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Spedex
User
Beiträge: 54
Registriert: Mittwoch 29. Januar 2020, 03:27

Ok ich füge hier jetzt noch was hinten dran.
Ich habe mehrere Frames, nennen wir sie "Städte Frames", und innerhalb dieser Frames öffne ich mit einem Button einen anderen Frame. Dieser andere Frame, wir nennen ihn jetzt einfach mal "ATM Frame" ist immer derselbe. Das heißt, egal von welchem Frame aus ich mit dem Button den "ATM Frame" öffne, es würde genau der gleiche Frame geöffnet werden, wenn ich in einem anderen Frame den Button drücken würde.
Das ganze in Code verdeutlicht:

Code: Alles auswählen

#Init Malay
frame_malay = Frame(root, width=1450, height=770)
frame_malay.place(x=0, y=0)
button_goto_atm = Button(frame_malay, bg="LightGrey", image=atm_preview_image, bd=0)
button_goto_atm.place(x=312, y=495)

#Init Nabas
frame_nabas = Frame(root, width=1450, height=770)
frame_nabas.place(x=0, y=0)
button_goto_atm = Button(frame_nabas, bg="LightGrey", image=atm_preview_image, bd=0)
button_goto_atm.place(x=540, y=780)
Hier wären jetzt zum Beispiel mal zwei "Städte Frames". Die zwei Frames heißen frame_malay und frame_nabas.
Mit dem Button button_goto_atm wird der ATM-Frame aufgerufen. Der command-Teil dieser Buttons befindet sich weiter unten im Code, ist aber auch nicht sonderlich wichtig:

Code: Alles auswählen

button_goto_atm.configure(command=call_atm)
Die call_atm Funktion schaut wie folgt aus:

Code: Alles auswählen

def call_atm():
    frame_atm.tkraise()
    #Hier steht natürlich eigentlich noch mehr, sonst könnte man sich die Funktion einfach sparen.
Innerhalb des ATM-Frames gibt es einen "Back-Button", sprich einen Button, der beim Drücken den vorherigen Frame anzeigen soll. Das heißt, wenn ich von frame_malay in den "ATM-Frame" komm, dann möchte, wenn ich den "Back-Button" drücke, wieder zu frame_malay.
Vielleicht sollte ich den "ATM-Frame" auch kurz zeigen:

Code: Alles auswählen

#Init ATM
frame_atm = Frame(root, width=1450, height=770) 
frame_atm.place(x=0, y=0)
button_back_atm = Button(frame_atm, text= "", bg="LightGrey", image=button_back_image, command=???)
button_back_atm.place(x=1340, y=715)
Man beachte die command-Funktion des "Back-Buttons" button_back_atm. Hier kommt nämlich das Problem. Ich habe bis jetzt noch keine Lösung gefunden, wie ich den vorherigen Frame aufrufe.
Folgendes: Diese Städte-Frames werden auch wieder in einem Haupt-Frame mittels Buttons aufgerufen.
Zum Beispiel so:

Code: Alles auswählen

button_malay = Button(frame_main_map, text="", bg="LightGrey", image=button_pic_1)
button_malay.place(x=364, y=49)
def call_malay_map():
    frame_malay.tkraise()
    #Hier steht natürlich eigentlich noch mehr, sonst könnte man sich die Funktion einfach sparen.
button_malay.configure(command=call_malay_map)
Ich habe mir überlegt, dass ich, beim Aufrufen der Städte-Frames zum Beispiel folgendes mache:

Code: Alles auswählen

last_called = None
def call_malay_map():
    frame_malay.tkraise()
    last_called = frame_malay
last_called würde ich dann einer anderen "Aufruf-Funktion" als Parameter mitgeben, die dann last_called.tkraise() durchführt.
Aber, wie ich ja bereits in diesem Topic erfahren habe, würde das nicht funktionieren, denn die Variable last_called bleibt bei der Funktion call_malay_map() innerhalb der Funktion. Dementsprechend müsste ich die mit return "raus bringen". Allerdings wüsste ich dann kein Ort, wo ich einer Variable die Variable last_called zuordnen kann. Denn alles, was nicht in einer Funktion steht, wird ja beim GUI nur einmal, nämlich beim Starten des Programms aufgerufen. Dementsprechend wäre hier jetzt .set() extrem nützlich. Allerdings gibt es das laut https://effbot.org/tkinterbook/variable.htm nur bei Strings, Doubles, Integers und Bool'sche Variablen. Also nicht bei Objekten wie es frame_malay zum Beispiel ist.
Hätte jemand von euch da eine Lösung?
Sirius3
User
Beiträge: 17741
Registriert: Sonntag 21. Oktober 2012, 17:20

Man kann das noch ein paar mal wiederholen: für so etwas mußt Du Dir passende Klassen definieren.
Benutzeravatar
__blackjack__
User
Beiträge: 13079
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Ich habe auch den leisen Verdacht, dass es nicht wirklich einen Frame pro Stadt geben sollte, weil die doch ziemlich wahrscheinlich alle nach dem gleichen Muster aufgebaut sind. Das ganze Programm ist viel zu ”grafisch gedacht”, statt die Programmlogik von der GUI sauber zu trennen und Daten tatsächlich in Datenstrukturen zu speichern statt in der GUI und statischem Code.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Spedex
User
Beiträge: 54
Registriert: Mittwoch 29. Januar 2020, 03:27

Also ich habe den Verdacht, dass ich mir da schon was dabei gedacht habe. Natürlich soll es einen Frame pro Stadt geben. Ich habe ungefähr 30 Städte und innerhalb jedes Stadt-Frames finden sich unterschiedliche Buttons wieder (Noch nicht implementiert). In den meisten Städten findet sich jedoch der ATM-Button wieder, schließlich ist ein Bankautomat in den meisten Städten zu finden.
Wer, will, kann es ja einfach mal selber anschauen oder ausprobieren: https://mega.nz/#F!TjIDRKxK!PqLBBvSxb3QXGu4JgqJvXg
Kann natürlich sein, dass das jetzt erstmal verwirrend ausschaut, schließlich ist der Code ja nicht optimal aufbereitet, was mir persönlich aber egal ist. Sauberer oder schöner Code dient meiner Meinung nach dafür, dass entweder wenn man im Team arbeitet, die Kollegen sich auskennen, oder dazu, dass einem selber das Arbeiten erleichtert wird. @__blackjack__ was meinst du mit "alle nach dem gleichen Muster aufgebaut"? Warum sollte es nicht einen Frame je Stadt geben?
Ich wüsste nicht wie ich Programmlogik und GUI sauber voneinander trennen sollte, etwa mit Objektorientierte Programmierung?. Geschweige denn was Daten in Datenstrukturen seien sollen.
@Sirius3 Klassen? Angenommen ich würde die Objektorientierte Programmierung tatsächlich umsetzten, müsste ich erstmal so viele Grundlagen der OOP erlernen, und dann auch noch mein Programm umschreiben. Ich kann mir nicht vorstellen, dass sich das rentiert, wenn ich bis jetzt auch alles ohne OOP geschafft habe. Lassen sich manche Probleme wirklich nur mit OOP lösen, oder ist OOP einfach nur schöner?
__deets__
User
Beiträge: 14529
Registriert: Mittwoch 14. Oktober 2015, 14:29

"Nicht gehen" ist so ein Ding. Natuerlich geht es. Man kann auch auf einem Floss aus Plastikflaschen den Antlantik ueberequeren. Und sagen, ein richtiges Schiff ist ja nur schoener.

OO loest bestimmte Dinge *besser*. So wie Glasfaserruempfe besser sind, als mit Kordel verbundene Flaschen.

Und es mag sein, dass du dir was gedacht hast - nur fehlen dir die Werkzeuge und Verfahren, um das Problem *anders* zu loesen. Wenn alles was man hat ein Hammer ist, dann ist jedes Problem ein Nagel.

Ein Frame / Stadt geht bei 10 oder 100 ok, aber irgendwann kommt der Moment, wo das ganze in die Knie geht - und es waere besser gewesen, immer den gleichen Frame zu benutzen, und stattdessen dessen Inhalt auszutauschen. Und es hat auch andere Vorteile, weil jeder ANDERE Teil des Programms, das jetzt irgendwie mit der aktuellen Stadt/deren GUI interagieren soll, genau EINEN Frame kennt, und nicht muehselig beigrebracht bekommen muss, welcher der hunderten Frames jetzt gerade der richtige ist. Was ja dein Problem ist.
Sirius3
User
Beiträge: 17741
Registriert: Sonntag 21. Oktober 2012, 17:20

Du kannst natürlich einfach drauf los programmieren und 648 Zeilen am Strück herunterschreiben und 36 mal quasi identischen Code für jede Stadt kopieren. Aber irgendwann wirst Du an den Punkt kommen, wo jede weitere Änderung schwierig bis unmöglich wird, weil man z.B. den Zustand des Spiels sich irgendwie merken muß.
Also ich habe den Verdacht, dass das genau jetzt der Fall ist.
Dann muß man seine Struktur nochmal komplett überdenken. Z.B. könnte man sich fragen, was denn jede Stadt gemeinsam hat und wie man die Unterschiede modelieren könnte. Durch solche abstrakten Überlegungen kommt man dann relativ schnell zu einem konkreten Klassendesign für eine Stadt-Klasse.
Aber dazu müßte man erst einmal die Grundlagen von Objektorientierung lernen und sie nicht Grundweg ablehnen. Dabei lernt man dann auch, wann man sie nicht einsetzen sollte, aber solange man sich damit überhaupt nicht auskennt, weiß man auch nicht von deren Möglichkeiten.
Benutzeravatar
__blackjack__
User
Beiträge: 13079
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@Spedex: Du kannst also nicht programmieren und willst es auch nicht lernen. Da nützt es auch nichts wenn Du darüber nachdenkst, wenn Dir die Grundlagen und das Verständnis davon fehlen über das was Du da nachdenkst. Du willst ohne Kenntnis von Datenstrukturen, Funktionen (es gibt in dem Code nur zwei Stück und das ist wahrscheinlich auch mehr Zufall), und Klassen, eine nicht-triviale GUI-Anwendung programmieren. Da kommen so viele Code und Datenwiederholungen und Daten fest in Code und sogar Namen vor, dass ich nicht mal weiss ob Du Schleifen überhaupt verstanden hast.

Natürlich kann man das so machen wie Du das da machst, denn letztlich könnte man auch alles in Assembler programmieren, oder in einem BASIC-Dialekt mit Zeilennummern ohne Funktionen, Namensräume, und Verbunddatentypen, wie beispielsweise GW-BASIC. Das habe ich vor 30 Jahren auch mal ernsthaft verwendet. Aber da hat man das so gemacht weil es einfach nicht besser ging, weil die Programmiersprache einem diese Grenzen gesetzt hat. Selbst dort hätte man Arrays und Schleifen zur Verfügung und würde die auch nutzen, beispielsweise für die Städte.

So wie Du die Begriffe „sauber“ und „schöner“ verwendest scheint das irgendwie ein optionaler und eher ästhetischer Aspekt zu sein. Etwas das nett wäre, aber nicht wirklich wichtig. Das ist wichtig! Gute Namensgebung, keine globalen Variablen, sinnvoll strukturierte Daten und sinnvoll strukturierter Code sind wichtig damit man Code gut versteht, was wiederum wichtig ist um möglichst fehlerfreien Code zu schreiben, und Fehler im Code leicht finden und beheben zu können, und Code einfach warten und erweitern zu können. Das ist auch nicht für Kollegen und Fremde sondern auch für den Autor selbst, denn was eben als man es geschrieben hat noch völlig klar und selbstverständlich war, kann auch dem Autor nach wenigen Wochen Kopfzerbrechen bereiten, denn dann ist er selbst ein ”Fremder” der den Quelltext liest.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Spedex
User
Beiträge: 54
Registriert: Mittwoch 29. Januar 2020, 03:27

So wie sich das für mich anhört, muss man echt ein erfahrener Programmierer sein, um so ein GUI wie ich es mir vorstelle richtig umzusetzen. Auch die Planung habe ich unterschätzt. Wenn ich mein Spiel genau durchgeplant hätte, wüsste ich zwar (wenn ich mich mit OOP auskennen würde, was ich nicht tue), wie ich meinen Code besser mache, aber da geht doch der Spaß verloren.

Naja auf jeden Fall bin ich jetzt etwas verzweifelt, denn ich weiß nicht wie ich fortfahren soll. Soll ich jetzt die Grundlagen der OOP erlenen, und dann mit dem Programm weitermachen. Oder soll ich das Programm aufgegeben, und mich etwas leichterem widmen.

@__blackjack__ du hast geschrieben: "Da kommen so viele Code und Datenwiederholungen und Daten fest in Code und sogar Namen vor, dass ich nicht mal weiss ob Du Schleifen überhaupt verstanden hast."
Und wenn ich ehrlich bin, dann bin ich mir auch nicht sicher, ob ich Schleifen richtig verstanden habe. Ich hab nicht so viel Zeit fürs Programmieren, stehe aktuell kurz vor Abitur. Wenn ich mir also im Internet Tutorials anschauen, dann aber länger Pause mache, weil ich gerade keine Zeit fürs Programmieren habe, vergesse ich wieder viel.

Habt ihr eine Idee, wie ich fortfahren sollte?

Am meisten beschäftigt mich allerdings folgendes: Mein Plan ist es eigentlich, nächstes Jahr mit dem Informatik-Studium zu beginnen. Denkt ihr, auch wenn ihr keine Psychologen seit (die meisten zumindest nicht, denke ich mal), dass das trotzdem noch eine gute Entscheidung ist, auch wenn ich vielleicht mal nicht etwas verstehe beim Programmieren oder Hilfe brauche?
__deets__
User
Beiträge: 14529
Registriert: Mittwoch 14. Oktober 2015, 14:29

Ich wuerde vor allem sagen, dass die Entscheidung, welches Studium man ergreift, nicht an der Meinung von ein paar random dudes aus dem Internet haengen sollte.

Ich konnte vor dem Studium Programmieren, weil ich mir persoenlich die Zeit genommen habe - weil ich's cool fand. Teil des ganzen war uebrigens auch, Dinge zu lernen, von denen ich nur wusste, dass man sie koennen oder machen *sollte*. Statt wie du an jeder Abzweigung in Frage zu stellen, ob du das nun genau jetzt ganz unbedingt brauchen kannst. DAS ist ein viel groesseres Problem, und wird auch in keinem anderen Fach der Welt anders sein. Ohne ein gewisses Vertrauen darein, dass einem erfahrenere Leute keinen Unfug erzaehlen, und den Willen, das mal auszuprobieren (gerade wenn es um ueberaupt nichts geht bei einem Spass-Projekt), wird es nichts werden. Das ist kein Plädoyer fuer unkritische Rezeption - aber man muss schon wissen, warum man etwas nicht macht, statt es einfach abzulehnen.

Ich denke aber nicht, dass man schon als Programmier-Crack ins Studium kommen muss, und kenne diverse Leute, fuer die das erst spaeter in ihrem Leben eine relevante Beschaeftigung und Faehigkeit wurde. Darueber wuerde ich mir also nicht so viele Sorgen machen. ABER, und das gilt AFAIK auch heute noch: du wirst NICHT systematisch programmieren lernen im Studium! Trotz Bologna wirst DU programmieren lernen muessen, die Uni gibt dir nur einen Rahmen vor, welche Sprache & konkrete Aufgabe das gerade ist. Insofern - wenn du dich mit eigenen Projekten dadurch bildest, schadet das nicht.
Benutzeravatar
__blackjack__
User
Beiträge: 13079
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@Spedex: Unis bieten oft in den Sommerferien Schnupperveranstaltungen an. Das kann von lockeren Vorstellungen der Fachrichtung, bis hin zu Vorlesungen gehen, für die man sich bei einem Studium in dem Fach an der Uni sogar Leistungspunkte anrechnen lassen kann. Zumindest bei uns war es damals so, dass viele Anfänger eine falsche Vorstellung von Informatik hatten und deshalb die Abbrecherquote im bzw. nach dem ersten Semester ziemlich hoch war.

Ich konnte auch schon vorher programmieren, es haben aber mit mir auch welche angefangen, die vorher noch keine einzige Zeile programmiert hatten und Informatik wegen guter Mathematiknoten angefangen haben. Informatik ist in vielerlei Hinsicht ja angewandte Mathematik. Mich hat der ”hohe” Matheanteil etwas überrascht (um nicht zu sagen erschreckt) und im ersten Semester wurde durch funktionale Programmierung mein „Ich kann schon programmieren“ etwas in Frage gestellt. Weil Haskell so ganz anders als Assembler, BASIC, Pascal, und C ist. Da waren meine Vorkenntnisse eher hinderlich und Kommilitonen für die Haskell die erste Programmiersprache war, haben sich da teilweise deutlich leichter getan. Die mussten dafür dann umgekehrt beim Übergang zu Java stark umdenken, wo ich dann wieder schon vorhandenes Wissen von Pascal wiederverwenden konnte.

Den Satz „das hier ist kein Programmierkurs“ oder „wir sind nicht hier um Sprache XY in der Veranstaltung zu lernen“ obwohl Programmieren und das in Sprache XY in den Übungen verlangt wurde, gab es recht regelmässig. Die konkrete Programmiersprache ist in der Regel in den Veranstaltungen nur ein Werkzeug, dessen Handhabung man eigenverantwortlich lernen muss. In der Literaturliste gab es in der Regel Empfehlungen für Standardwerke oder was der Dozent oder Tutoren hilfreich fanden, und natürlich wurden auch einzelne Fragen in den Tutorien beantwortet wenn Zeit dafür war.

Auf der einen Seite gibt es Informatiker die nach dem Studium so gut wie nichts mehr programmieren, oder zumindest darauf hinarbeiten das sie nicht mehr programmieren müssen. Auf der anderen Seite bist Du heute in so gut wie keinem Studienfach mehr sicher vorm programmieren. Das zu können ist sicher kein Schaden.

Erfahrener Programmierer muss man für so eine GUI-Anwendung sein, man wird aber nur ein erfahrener Programmierer wenn man programmiert, Fehler macht, daraus lernt, und Code entsprechend um oder neu schreibt. Ein Problem sehe ich darin mit so einer GUI-Anwendung *anzufangen*, denn das setzt die kompletten Grundlagen einer objektorientierten Programmiersprache voraus wo dann noch mal die Eigenheiten von GUI-Programmierung oben drauf kommen. Also zum Beispiel das nicht mehr der Programmierer den Programmfluss bestimmt, sondern das der GUI-Hauptschleife übertragen wird und der Programmierer Code schreibt der auf Ereignisse reagiert.

Wenn beim planen der Spass verloren geht, dann läuft was schief, denn das planen sollte einem auch Spass machen, weil das zum programmieren dazu gehört. Man muss am Anfang auch nicht erst alles komplett bis ins kleinste Detail durchplanen bevor man anfängt den Code zu schreiben. Gerade bei Anfängern und bei Spielen ist es wichtig möglich schnell etwas lauffähiges zu haben um die Motivation nicht zu verlieren. Aber so ganz ohne ein bisschen Planung geht es halt auch nicht. Man sollte sich am Anfang überlegen was das Spiel am Ende können/beinhalten soll. Daraus ergibt sich welche Daten da anfallen. Je nach dem wie mit denen dann umgegangen werden muss, leitet man daraus ab wie man die Daten strukturiert.

Daten vermisse ich bei dem Stand jetzt aber so ziemlich komplett, denn es gibt keine Daten mit denen der Code dann etwas macht, sondern die Daten sind hart im Code verdrahtet, und das nicht nur als literale Werte sondern auch noch in Namen, wo Daten gar nichts zu suchen haben. Ein beträchtlicher Anteil der 203 Namen denen auf Modulebene direkt Werte zugewiesen werden, enthalten einen Städtenamen und es gibt für jeden Städtenamen den gleichen Satz von 5 Namen + ein Funktionsname in dem der jeweilige Stadtname steht. Und der Stadtname steht dann auch noch mal in der Zeichenkette als Teil des Dateinamens für das Bild für die jeweilige Karte. Wenn man sich da jetzt vertippt hat bei einem Namen muss man den an 7 Stellen im Programm anpassen. Mit jeder Stadt kämen 6 Namen auf Modulebene hinzu. Die Städtenamen sind aber Daten, das heisst jeder Stadtname sollte genau *einmal* im Programm stehen weil es jede Stadt ja auch nur genau einmal gibt.

Zu den Städten gehören Koordinaten. Die sollten auch nicht hart im Code stehen sondern in einer Datenstruktur mit dem Stadtnamen zusammengefasst. Und ich Frage mich gerade wie die `label_curr_pos_image`-Koordinaten zustande gekommen sind? Die sind so ähnlich wie die Stadtkoordinaten, aber eben nicht ganz. Also wahrscheinlich relativ dazu — etwa alle von Hand berechnet und eingetippt? Ich hätte ja schon die eigentlichen Städtekoordinaten selbst nicht als Pixelwerte ermitteln und eintippen wollen, das ist doch alles eine unglaubliche Sisyphusarbeit. Programmierer sind (die gute Art von) faul. Man wiederholt weder Code noch Daten und man erstellt auch nicht selbst Daten die sich aus bereits vorhandenen Daten ableiten lassen. Genau für solche repetitiven, stupiden Arbeiten hat man doch den Rechner.

Ein weiteres Beispiel für Codewiederholung und warum das schlecht ist, sind die drei `call_atm*()`-Funktionen: Die ganzen `str()`-Aufrufe dort sind überflüssig. Da der Codeblock von einer Zeile abgesehen drei mal kopiert wurde, muss man diese Änderung jetzt an drei mal so vielen Stellen durchführen.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Spedex
User
Beiträge: 54
Registriert: Mittwoch 29. Januar 2020, 03:27

Ok. Vielen Dank für eure Antworten.
Antworten