Das deutsche Python-Forum

Beim Schreiben eines Codes werden immer neue Namen für Variablen und Konstanten vergeben.
Wie verhindert man, dass man einen Namen doppelt/mehrfach vergibt? Ist es sinnvoll sich am Anfang des Codes eine Liste mit Bemerkungen (#......) über vergebene Namen anzulegen? Wie gehen Profis hier vor?

Die Anzahl der Variablen bleibt eigentlich immer sehr übersichtlich. Wenn eine Funktion mehr als 10 Variablen braucht, dann ist sie meist zu lang und sollte in mehrere Subfunktionen unterteilt werden.
Konstanten stehen eh schon am Anfang des Programms, da braucht mal also auch keine Bemerkungen.

Erkennt Python Konstanten an der GROSSSCHREIBUNG und schreibt sie dann automatisch an den Anfang?

Es wurde schon angesprochen, aber hier nochmal deutlicher: Dieses Problem kann nur bestehen, wenn der Code stumpf als Skript auf der Modulebene geschrieben ist. Oder wenn er zwar in Funktionen steckt, diese aber zu aufgebläht sind. Eine Funktion mit 30 Zeilen (ohne Doku) ist zB nicht besonders sinnvoll. Immer dann, wenn die Zeilenzahl in den zweistelligen Bereich kommt, sollte man den Code auf mehrere Funktionen unterteilen. Dieses Neuorganisieren mag aufwändig sein und zusätzlichen Gehirnschmalz einfordern, aber es hält den Code insgesamt übersichtlich und somit wartbar. Somit zahlt sich die Mühe dann entsprechend aus.

@Bill987654321: Am Anfang in einem Kommentar alles aufzulisten ist nicht sinnvoll. Das macht nur unnötig Arbeit und führt in der Regel dazu das sehr schnell die Liste in den Kommentaren nicht mehr mit dem tatsächlichen Code übereinstimmt. Die Namen stehen ja schon *im* Code. Wenn man eine Liste braucht kann man sich die daraus auch generieren. Einige Editoren bieten so eine Funktion, IDEs sowieso, und auch wenn man Dokumentation aus Quelltext generiert, bekommt man eine Liste. Wenn man dazu Dokumentation geschrieben hat, sogar nicht nur eine Liste sondern tatsächlich Dokumentation.

Ich denke Du siehst da ein Problem, welches es so überhaupt nicht gibt. Man hat nie so viele Namen, dass die Gefahr besteht, dass man durcheinander kommt. Wenn man so etwas macht, dann nützt auch eine Liste der Namen nicht mehr wirklich etwas. Konsens scheint zu sein das normale Menschen nicht mehr als ca. 7 benannte Dinge gleichzeitig im Kopf jonglieren können. In der Regel sollte man also auch nicht deutlich mehr als 7 Namen in einem Namensraum haben. Das ist keine harte Grenze, aber daran sollte man sich schon daran orientieren, bei Namen in Funktionen und Methoden und Argumenten. Falls man deutlich mehr hat, sollte man überlegen wie man das reduzieren kann.

Ich habe so ein bisschen den Eindruck Du kommst von Sprachen aus dem letzten Jahrhundert wo (fast?) alles global war und solche Kommentarblöcke am Anfang von Code üblich waren. Mit schlechteren Editoren und auch noch viel mit Ausdrucken von Quelltext oder zumindest den Kommentarblöcken am Anfang um einen Überblick zu haben. Ich kann mich auch noch daran erinnern zu BASIC-Programmen auf Papier Namenslisten mit Erklärungen und in welchen Unterroutinen welche Namen benutzt wurden, geschrieben zu haben um den Überblick nicht zu verlieren. Das schöne daran keine globalen Variablen zu verwenden ist, dass man diesen ganzen Kram nicht mehr braucht.

Bill987654321 hat geschrieben: Sonntag 5. April 2020, 15:15 Erkennt Python Konstanten an der GROSSSCHREIBUNG und schreibt sie dann automatisch an den Anfang?

Python kennt keine Konstanten. Die Großschreibung ist hier nur Konvention unter Programmierern, dass man den zugeordneten Wert nicht verändert. Inwieweit man sich daran tatsächlich hält, kümmert Python nicht. Kann man auch ganz leicht mal selbst ausprobieren.

Den zweiten Teil verstehe ich nicht. Wie genau ist das mit dem Anfang gemeint? Der Anfang von deinem Modul, also dass Python automatisiert deinen Quelltext bearbeitet, oder wie?

@snafu
Ich meine, dass man sich ab der zweiten bzw. dritten Zeile in Bermerkungen (# vergeben: Mannschaftsnamen, .....) "notiert" welche Namen bereits vergeben sind.

@blackjack
Du hast recht. Ich habe vor über 30 Jahren Basic V2 auf dem C64 in der Schule gelernt.
Das Programm, das ich gerade in Python angefangen habe, habe ich vorher (vor ca. 3 Jahren) auf dem Vice Emulator geschrieben. Es hat alles funktioniert. Vor ca. 30 Jahren habe ich das gleiche Programm schon zu Hause auf meinem C64 geschrieben.
Obwohl ich zwischen den Zeilen immer freie Zeilennummern gelassen habe, habe ich häufig Zeilennummern geändert, weil der Platz trotzdem nicht ausreichte. Weil mir dass zu aufwendig war, habe ich mich entschieden, das Programm in Python zu schreiben.

Basic auf dem C64 mit Zeilennummern und goto ...

Falls Du versucht sein solltest, den früheren Code einfach nach Python zu übertragen, so verwirf diese Idee besser. Die Unterschiede beider Sprachen sind gewaltig, obgleich Du ähnlich wie in C64-Basic alles einfach runter schreiben könntest.

Meine Empfehlung wäre, das Programm in Python _völlig_ neu zu schreiben.

Nein, nein, den Code will ich nicht übertragen. Ich habe auch kein Basic-Listing vor mir liegen.
Manches wie z.B. Print-Ausgaben oder Fileprogrammierung sind ähnlich.

@Bill987654321: Genau das BASIC war auch meine erste Programmiersprache. Ich habe auch immer noch den ersten C64 den ich damals bekommen habe, und der läuft auch noch. Mit einem Haufen Erweiterungen die ich mir damals als Schüler nicht leisten konnte, oder mich nicht getraut habe. Zum Beispiel eine RAM-Erweiterung direkt in den Rechner reinlöten. Zwischenzeitlich war das meiste an Hardware von damals ja recht günstig im Netz zu finden. Mittlerweile sind einige Teile seltener und damit teurer.

Als die Schule noch C64er hatte wurde für meine Jahrgänge noch kein Unterricht damit angeboten. Als es dann soweit war, waren es schon PCs mit GW-BASIC, was ja nicht sooo deutlich besser als das CBM BASIC V2 ist, beziehungsweise war es unüblich einige Verbesserungen zu nutzen.

Das Problem mit den Zeilennummern löst man auf dem C64 durch BASIC-Erweiterungen die einen Befehl zum neu nummerieren von Zeilen anbieten. Ich habe so etwas beispielsweise gleich nach dem Einschalten des Rechners schon zur Verfügung weil da eine Retro Replay-Cardridge drin steckt und die erweitert das BASIC um ein paar Befehle, unter anderem RENUM(BER). Die Action Replay die vorher drin steckte hat den zwar auch, aber da war er nicht wirklich sinnvoll nutzbar, weil die Implementierung nur die Zeilennummern der Zeilen, aber nicht die Nummern hinter GOTO & Co angepasst hat. Ein Retro Replay kann man mit VICE auch emulieren. Das ROM-Image kann man legal im Netz herunterladen.

Alle späteren BASIC-Versionen aus der CBM BASIC Familie, beziehungsweise auch auf Microsoft BASIC basierende BASIC Dialekte (mit Zeilennummern) auf anderen Plattformen, haben so einen Befehl schon dabei. GW-BASIC auch schon.

Wenn Du das Programm auf eine moderne Programmiersprache portieren willst, und da sind eigentlich auch schon so alte Sprachen wie Pascal, C, oder auf dem PC alle strukturierten BASICs mit gemeint, vergiss am besten alles was Du so von klassischem BASIC kennst und gewohnt bist. Selbst der Nachfolger von GW-BASIC, also QBasic/QuickBASIC, ist schon komplett anders was die herangehensweise angeht. Also alles was nicht *einen* globalen Namensraum, mit extrem begrenzten Namen, Zeilennummern, und GOTO als allgemeines, normales mittel den Programmablauf zu ”strukturieren” hat, ist eine komplett andere Welt. In der Regel eine deutlich bessere Welt.

Portieren von so einem archaischen BASIC läuft auf komplett neu schreiben hinaus. Wenn Du jetzt anfängst Code so nah wie möglich am Original zu ”übersetzen”, kommt da etwas heraus was der Python-Syntax genügen mag, aber was ganz und gar kein Python-Programm sein wird.