Programmstruktur

[Namlus]

Hallo zusammen, ich bin mit meinem ersten "Projekt soweit fertig". Zur Erstellung habe die Abschnitte in einzelne Dateien untergliedert und dort getestet.
Dateien heissen

- Emails_importieren.py
- Emails_Daten_auslesen.py
- Daten_exportieren.py


Jetzt möchte ich die zusammenführen. Wie ist das am sinnvollsten? Den Code einfach in 1 Datei zu kopieren finde ich sehr unübersichtlich (ich schreibe auch zu jedem Befehl sehr viel Kommentare dazu, damit ich später mal weis was ich da gemacht und mir dabei gedacht habe). Jede Datei benötigt auch unterschiedliche Packages. Kriege ich da u.U. ein Problem wenn ich zu viel lade? Wie würdet Ihr das machen?

[__blackjack__]

@Namlus: Ich würde grundsätzlich erst einmal mit *einer* Datei anfangen. Auch zum testen muss man das ja nicht in drei Dateien aufteilen. Falls das ”nötig” gewesen sein sollte, ist der Code nicht wirklich ”testbar” geschrieben worden. Erst wenn es für eine Datei tatsächlich zu viel wird, würde ich das sinnvoll in Module aufteilen in einem Package. Also aus dem Modul ein Package machen.

Zusammenführen sollte recht einfach sein: In eine Datei kopieren und dann etwas umordnen, so dass nach Konvention erst die Importe und dann die Konstantendefinitionen vor dem restlichen Code in der Datei stehen. Dann noch die Importe sortieren/aufräumen.

Es klingt so ein bisschen danach, dass der Code vielleicht ”überkommentiert” ist. In Kommentaren sollte wirklich nur stehen warum etwas so gemacht wird, wie es da gemacht wird, sofern das nicht offensichtlich ist. Wobei offensichtlich auch alles ist, was in der Dokumentation der Programmiersprache und den verwendeten Bibliotheken steht. Sonst wäre man ja ständig dabei die Dokumentation noch mal in den Programmen zu wiederholen. Und bei sehr vielen Kommentaren würde ich auch noch mal schauen ob man den Code nicht besser formulieren kann, so dass die Informationen aus den Kommentaren in den Code wandern.

Für ”übergeordnete” Information gibt es dann auch noch die Möglichkeit die nicht in den Python-Quelltext zu schreiben, sondern tatsächlich Dokumentation zu erstellen wo das drin steht.

[Namlus]

Vielen Dank für die Antwort.

@Namlus: Ich würde grundsätzlich erst einmal mit *einer* Datei anfangen. Auch zum testen muss man das ja nicht in drei Dateien aufteilen. Falls das ”nötig” gewesen sein sollte, ist der Code nicht wirklich ”testbar” geschrieben worden. Erst wenn es für eine Datei tatsächlich zu viel wird, würde ich das sinnvoll in Module aufteilen in einem Package. Also aus dem Modul ein Package machen.

Dachte nur, Email Import z.B. kann man später auch mal für andere sachen brauchen, aber ich kanns auch rauskopieren.

Zusammenführen sollte recht einfach sein: In eine Datei kopieren und dann etwas umordnen, so dass nach Konvention erst die Importe und dann die Konstantendefinitionen vor dem restlichen Code in der Datei stehen. Dann noch die Importe sortieren/aufräumen.

Ja da ist nichts dabei, ich mag das nur nicht wenn der Code so lange ist (über 200 Zeilen). Ist aber was persönliches. Ich mag es einfach nicht. Ich mag das immer sauber strukturiert, am besten in einer Zeile darunter Kommentar in der Form: Datum + Kommentar

Es klingt so ein bisschen danach, dass der Code vielleicht ”überkommentiert” ist. In Kommentaren sollte wirklich nur stehen warum etwas so gemacht wird, wie es da gemacht wird, sofern das nicht offensichtlich ist. Wobei offensichtlich auch alles ist, was in der Dokumentation der Programmiersprache und den verwendeten Bibliotheken steht. Sonst wäre man ja ständig dabei die Dokumentation noch mal in den Programmen zu wiederholen. Und bei sehr vielen Kommentaren würde ich auch noch mal schauen ob man den Code nicht besser formulieren kann, so dass die Informationen aus den Kommentaren in den Code wandern.

Für ”übergeordnete” Information gibt es dann auch noch die Möglichkeit die nicht in den Python-Quelltext zu schreiben, sondern tatsächlich Dokumentation zu erstellen wo das drin steht.

Ja. Aber wenn ich eins gelernt habe: Schreib alles dazu - gerade wenn du mit einer Programmiersprache beginnst. Denn in 2 Jahren wenn du reinschaust denkst du dir: Was habe ich damals verbrochen..... was für einen Müll habe ich damals geschrieben.
Und in 2 Jahren wenn ich drüberschau weil ich was ändern muss bin ich froh um jedes Wort dass ich da reingeschrieben habe und werde dann auch sicherlich ein bisschen mehr wissen und das ganze viel kompakter und professioneller schreiben können.

Man wächst mit seinen Aufgaben und ich machs ja auch nicht zum Spass, sondern weil ich das Script JETZT brauche damit bei uns die Arbeit weitergeht und damit ein bestehendes Problem gelöst wird.

[Sirius3]

Die Dateinamen, "eMail importieren", "eMail-Daten auslesen" und "Daten exportieren" lesen sich für mich so, dass die eh aufeinander aufbauen. Da Du gestern noch nicht wußtest, was Funktionen sind, kann ich mir vorstellen, wie die Dateien bisher aussehen, also von "Projekt soweit fertig" noch weit entfernt. Nimm Dir die Zeit, und schreibe für Dein erstes Projekt alles so sauber wie es geht.

[__blackjack__]

@Namlus: 200 Zeilen ist deutlich unter der Länge an der ich anfangen würde zu sagen das wäre alleine wegen der Zeilenanzahl zu viel. So was um die 1000 bis 1500 Zeilen müssen es dafür schon werden, das ich alleine aufgrund der Zeilenanzahl eines Moduls sagen würde da müsste man mal über's Aufteilen nachdenken. Wenn ich immer bei 200 Zeilen anfangen würde Module aufzuteilen, wird es *unübersichtlicher* weil es dann mehr Module gibt, und man beim verfolgen vom Programm- und Datenfluss deutlich mehr Dateien öffnen und zwischen denen hin und her wechseln muss.

Kommentare stehen in Python *über* dem Code der damit kommentiert wird. Unter Code kommen in Python Docstrings. An bestimmten von der Sprache und eventuell noch vom Dokumentationswerkzeug vorgesehenen Stellen.

Was hat das Datum in Kommentaren verloren? Die Information braucht man in der Regel nicht, und falls man die doch mal benötigt, kann man sich die aus der Versionsverwaltung holen, da sieht man ja wann welcher Quelltextteil hinzugefügt oder verändert wurde.

Wenn ich eins gelernt habe, dann Code zu schreiben der möglichst keine Kommentare braucht, weil das aus dem Code selbst klar wird was der macht und gegebenenfalls was man sich dabei gedacht hat. Das Problem bei vielen Kommentaren ist auch, dass man die pflegen muss, also neben dem Code aktuell halten muss. Tut man das nicht, hat man irgendwann falsche Kommentare und kann am Ende *keinem* Kommentar im Programm mehr trauen weil man immer erst einmal schauen muss ob der jeweilige Kommentar auch tatsächlich noch zum Code passt. Das macht dann unnötig Arbeit beim schreiben, und später unnötig Arbeit beim Lesen und Verändern vom Quelltext. Wenn ich anfange Kommentare zu schreiben, dann versuche ich immer noch mal zu schauen ob man den Kommentar nicht durch verständlicheren Code überflüssig machen kann.

Dokumentation von Sprache und Bibliotheken noch mal in Kommentare zu packen, birgt auch die Gefahr, dass man dort falsches in Stein meisselt, gerade wenn man neu in der Sprache ist, kann es passieren, dass man dort Missverständnisse als Kommentar hin schreibt, und als Fakt hin nimmt, wenn man da nach zwei Jahren wieder dran geht, wo man den Irrtum vielleicht erkennen würde, wenn man stattdessen noch mal in der tatsächlichen Dokumentation nachliest. Und für Leute, die die Sprache können, ist es nervig sich durch Offensichtlichkeiten zu lesen um an die tatsächlich relevanten Teile in den Kommentaren zu kommen.

Wenn ich eine neue Programmiersprache anfange (ich schaue mir gerne Sprachen/Implementierungen an), dann mache ich mir dazu ausserhalb von konkreten Quelltexten Notizen über die Gemeinsamkeiten, Unterschiede, und Besonderheiten gegenüber anderen Sprachen die ich schon kenne. Oft mache ich mir auch einen „Spickzettel“ um immer eine Übersicht zur Hand zu haben. Das halte ich für sinnvoller als solche Informationen immer und immer wieder in die Quelltexte zu schreiben. Oder dort dann auch nur einmal, was mir dann aber nicht weiterhilft wenn ich gerade bei einem Quelltextteil bin, wo es nicht noch mal steht.

[Namlus]

@Namlus: 200 Zeilen ist deutlich unter der Länge an der ich anfangen würde zu sagen das wäre alleine wegen der Zeilenanzahl zu viel.

Wie gesagt, ich mag das einfach nicht. Ich bin da sehr eigen, je kompakter desto lieber ist es mir. Natürlich nur eine persönliche Vorliebe. Kein muss. HTML und CSS (gut keine Progammiersprache) kannst halt z.B. schön strukturieren. Genauso wie Filemaker und VB (ok ich weis, sind bei Programmierern sehr unbeliebt, da die unprofessionell sind)

Was hat das Datum in Kommentaren verloren? Die Information braucht man in der Regel nicht, und falls man die doch mal benötigt, kann man sich die aus der Versionsverwaltung holen, da sieht man ja wann welcher Quelltextteil hinzugefügt oder verändert wurde.

Ich brauche Sie, ich muss mich auch darin zurechtfinden. Habe ich mir einheitlich so angewöhnt - hat sich bewährt. Es ist doch so, man ändert immer mal wieder was an Scripts, oft nach Wochen, Monaten.... Plötzlich hat man an einer ganz anderen Stelle eine Auswirkung, die man nicht bedacht hat. Dann geht die Fehlersuche los und da ist es sehr praktisch wenn man in den Kommentaren sieht welche Abschnitte man wann geändert hat. Mir hilft das und darum mache ich es. Ich bin kein Profi und beschäftige mich nicht täglich mit dem Thema. Ein Profi braucht das natürlich nicht.

Deshalb muss ich umfangreicher Dokumentieren um Fehler auszuschließen. In 2 Monaten schaue ich in den Code und frage mich: Warum zum Teufel habe ich damals ein "If", "For", gesetzt.

Wenn ich eine neue Programmiersprache anfange (ich schaue mir gerne Sprachen/Implementierungen an), dann mache ich mir dazu ausserhalb von konkreten Quelltexten Notizen über die Gemeinsamkeiten, Unterschiede, und Besonderheiten gegenüber anderen Sprachen die ich schon kenne. Oft mache ich mir auch einen „Spickzettel“ um immer eine Übersicht zur Hand zu haben. Das halte ich für sinnvoller als solche Informationen immer und immer wieder in die Quelltexte zu schreiben. Oder dort dann auch nur einmal, was mir dann aber nicht weiterhilft wenn ich gerade bei einem Quelltextteil bin, wo es nicht noch mal steht.

Ja, auch eine gute Idee.

[Namlus]

Die Dateinamen, "eMail importieren", "eMail-Daten auslesen" und "Daten exportieren" lesen sich für mich so, dass die eh aufeinander aufbauen. Da Du gestern noch nicht wußtest, was Funktionen sind, kann ich mir vorstellen, wie die Dateien bisher aussehen, also von "Projekt soweit fertig" noch weit entfernt. Nimm Dir die Zeit, und schreibe für Dein erstes Projekt alles so sauber wie es geht.

Da siehst mal wie schnell ich lerne . Ja die bauen aufeinander auf, sind auch so geschrieben, dass ich Sie einfach per STRG + C aneinander reihen kann. Ich arbeite gerne in Blöcken/Abschnitten, teste die auch einzeln ob Sie funktionieren. Am Ende kommt dann die "Reinschrift". In dem Fall STRG+C.

Ist schon alles fertig und ist durchgelaufen. 13.000 Emails (incl. Auftragshistorie) aus den letzten 5 Jahren in die Kundenverwaltung eingelesen. Aus den Email habe ich automatisch fehlende Daten (Telefonnummern, fehlende Vornamen - Ergänzung Firmennamen) und die Daten so strukturiert dass Sie die Kundenvewaltung einlesbar sind und die fehlenden Daten automatisch ergänzt/bzw. abgeglichen werden.

85 Fehler die ich per Hand nacharbeiten habe müssen! Job Done. Hat mir viel Arbeit erspart.

[__blackjack__]

@Namlus: Zum Datum in Kommentaren: Ja aber genau dafür ist doch die Versionsverwaltung da. Dort sieht man ja was sich um welches Datum herum geändert hat. Und man kann auch einfach mal schauen wann es das letzte mal noch funktioniert hat und dann Intervallsuche machen um den Punkt zu finden an dem es kaputt ging. Manche Versionsverwaltung unterstützt das sogar direkt durch Kommandos (`bisect` oder ähnlich).

``if`` und ``for`` muss man ja nicht wirklich erklären. Warum ein ``if`` da steht, sieht man ja an der Bedingung und beim ``for`` sieht man worüber iteriert wird. Wenn die Bedingung beim ``if`` kompliziert ist, bietet es sich auch oft an da eine sinnvoll benannte Funktion oder Methode herauszuziehen, um sich einen Kommentar sparen zu können.

[Namlus]

@Namlus: Zum Datum in Kommentaren: Ja aber genau dafür ist doch die Versionsverwaltung da. Dort sieht man ja was sich um welches Datum herum geändert hat. Und man kann auch einfach mal schauen wann es das letzte mal noch funktioniert hat und dann Intervallsuche machen um den Punkt zu finden an dem es kaputt ging. Manche Versionsverwaltung unterstützt das sogar direkt durch Kommandos (`bisect` oder ähnlich).

``if`` und ``for`` muss man ja nicht wirklich erklären. Warum ein ``if`` da steht, sieht man ja an der Bedingung und beim ``for`` sieht man worüber iteriert wird. Wenn die Bedingung beim ``if`` kompliziert ist, bietet es sich auch oft an da eine sinnvoll benannte Funktion oder Methode herauszuziehen, um sich einen Kommentar sparen zu können.

Das habe ich doch auch nie gesagt das ich die Befehle "if" und "for" erkläre. Oder?

[__deets__]

Das hat auch blackjack nicht gesagt. Sondern das es da steht, was die machen. Was also ist der Mehrwert? Vielleicht zeigst du mal ein Beispiel, statt abstrakt zu bleiben.

Und so insgesamt wirkt das hier ziemlich sinnlos. Auf jeden Vorschlag mit “ich will es aber so machen, wie ich es machen will” zu antworten, dann kann man sich das ja auch sparen?

[Sirius3]

Da siehst mal wie schnell ich lerne . Ja die bauen aufeinander auf, sind auch so geschrieben, dass ich Sie einfach per STRG + C aneinander reihen kann. Ich arbeite gerne in Blöcken/Abschnitten, teste die auch einzeln ob Sie funktionieren. Am Ende kommt dann die "Reinschrift". In dem Fall STRG+C.

Abschnitte und Blöcke benutzt man, wenn man (noch) nicht weiß, was Funktionen sind.
Die machen nämlich alles viel einfacher. Man braucht weniger Kommentare, weil Funktionsnamen ja schon deutlich machen, welcher Code was macht. Man muß nicht per STRG+C programmieren, weil das Programm nicht einfach von oben nach unten durchläuft, sondern man entscheiden kann, was wann ausgeführt wird (oder auch nicht). Man kann wirklich testen, weil man Testfunktionen für jede Funktion schreiben kann. Und letztlich ist eine Datei mit 2000 Zeilen noch ohne weiteres bewältigbar, weil die Datei in sich durch die Funktionen strukturiert ist.
Und dann sind natürlich viele Probleme gar nicht lösbar, wenn man keine Funktionen schreiben kann.

[Namlus]

Das hat auch blackjack nicht gesagt. Sondern das es da steht, was die machen. Was also ist der Mehrwert? Vielleicht zeigst du mal ein Beispiel, statt abstrakt zu bleiben.

Und so insgesamt wirkt das hier ziemlich sinnlos. Auf jeden Vorschlag mit “ich will es aber so machen, wie ich es machen will” zu antworten, dann kann man sich das ja auch sparen?

Ja stimmt, es ist sinnlos mir Antworten auf Fragen zu geben die ich nie gestellt habe und mir Ratschläge zu erteilen um die ich nie gebeten habe. Dennoch versuche ich allen die mich "belehren" aber nicht zur Problemlösung beitragen durch geheuchelte Anerkenng das Bedürfnis sich weiterhin in der Maschloischen Pyramidenspitze zu sulen zu geben. Gelingt mir leider nicht immer, sorry dafür. Ich sollte mir angewohnen einfach nicht mehr darauf einzugehen.

Ich wäre auch dankbar wenn wir uns auf die gestellte Frage konzentrieren könnten, ich bin ja ein genügsamer Mensch dem ein "Ja macht Sinn in einer Datei" oder "Nein gliedere es auf, das ist besser" zufrieden ist. Damit wäre alles gesagt.

[sparrow]

Und du magst es ja quick&dirty

[Namlus]

Und du magst es ja quick&dirty

Ja genau. Ich hab ein Problem ich brauch ne Lösung. Jetzt. Wie ist mir egal. Und mir ist egal ob ich

1+1 rechne

oder
a = 1
b = 1
a+b

Das Ergebnis zählt. Der Rest ist mir egal. ich will keinen "schönen" Quellcode, ich will das Ergebnis. Ich weis das ist für nen Programmierer schwer zu verstehen. Wir haben schon einiges an Websiten/Software entwickeln lassen. Das ist immer wieder ein Thema....

[Namlus]

Das hat auch blackjack nicht gesagt. Sondern das es da steht, was die machen. Was also ist der Mehrwert? Vielleicht zeigst du mal ein Beispiel, statt abstrakt zu bleiben.

Gerne, hier ein Beispiel eines Kommentars zur If:

Code: Alles auswählen

# 23-01 Wenn die Zeichenanzahl über 1000 ist muss ich den Bildschirm um 400 scrollen und erst dann den Screenshot machen da sonst der untere Teil fehlt
if (Text_wörter >= 1000):
    driver.execute_script("window.scrollTo(0, 400)")

[sparrow]

Gutes Beispiel von "Kommentar versucht schlechte Benennung zu heilen und ist falsch".
Oder anders: Dein Kommentar wiederspricht dem Programmcode. Denn "Text_wörter" suggeriert ja, dass es sich um _Wörter_ handelt. Dein Kommentar spricht aber von Zeichen.
Dann sagt dein Kommentar, dass du etwas tust, wenn du mehr als 1000 irgendwas hast. Dein Quellcode sagt aber gleich 1000 oder mehr.
Das heißt: Du schreibst, was eh schon im Quellcode steht - nur schlechter oder falsch.

Namen schreibt man in Python klein_mit_unterstrich (ausgenommen Konstanten (KOMPLETT_GROSS) und Klassennamen (PascalCase).
Um die if-Bedingung gehören keine Klammern.

Code: Alles auswählen

if zeichen > 1000:
    driver.execute_script("window.scrollTo(0, 400)")

Und das ist aussagekräftiger als jeder Kommentar. (und wengier fehleranfällig, was dein Beispiel zeigt).

[Namlus]

Abschnitte und Blöcke benutzt man, wenn man (noch) nicht weiß, was Funktionen sind.

Der Meinung bin ich auch. Man wächst mit seinen Aufgaben und lernt dabei. - Was man gestern noch "auf die eine Art" gemacht hat, macht man mit dem Wissen von morgen ganz anders.

[Namlus]

Gutes Beispiel von "Kommentar versucht schlechte Benennung zu heilen und ist falsch".
Oder anders: Dein Kommentar wiederspricht dem Programmcode. Denn "Text_wörter" suggeriert ja, dass es sich um _Wörter_ handelt. Dein Kommentar spricht aber von Zeichen.
Dann sagt dein Kommentar, dass du etwas tust, wenn du mehr als 1000 irgendwas hast. Dein Quellcode sagt aber gleich 1000 oder mehr.
Das heißt: Du schreibst, was eh schon im Quellcode steht - nur schlechter oder falsch.

Namen schreibt man in Python klein_mit_unterstrich (ausgenommen Konstanten (KOMPLETT_GROSS) und Klassennamen (PascalCase).
Um die if-Bedingung gehören keine Klammern.

Code: Alles auswählen

if zeichen > 1000:
    driver.execute_script("window.scrollTo(0, 400)")

Und das ist aussagekräftiger als jeder Kommentar. (und wengier fehleranfällig, was dein Beispiel zeigt).

Ja stimmt. Erwischt. Den Code habe ich grad ziemlich lustlos ausm nem Forum (https://stackoverflow.com/) kopiert und einfach was drübergeschrieben, damit du Ruhe gibst. Hab dabei nicht wirklich nachgedacht. Naja erwischt. Ich sollte mir angewöhnen einfach nicht mehr zu Anworten um "freundlich zu sein"...... wenn ich nicht wirklich Lust drauf habe.

Aber freut mich wenn dir jetzt einer abgeht.

Worüber ich grad schmunzeln muss, einerseits bist so ein Klugschei.... beim Code, andererseits bringst du nicht mal einen vernünftigen fehlerfreien Satz zusammen. #genaumeinhumor
Wünsch dir einen schönen Abend

[__blackjack__]

Ich wäre auch dankbar wenn wir uns auf die gestellte Frage konzentrieren könnten, ich bin ja ein genügsamer Mensch dem ein "Ja macht Sinn in einer Datei" oder "Nein gliedere es auf, das ist besser" zufrieden ist. Damit wäre alles gesagt.

Du fragst das obwohl Du schon weisst, dass Du bei 200 Zeilen nicht mehr bei einer Datei bleiben willst. Also warum fragst Du dann?

[Namlus]

Ich wäre auch dankbar wenn wir uns auf die gestellte Frage konzentrieren könnten, ich bin ja ein genügsamer Mensch dem ein "Ja macht Sinn in einer Datei" oder "Nein gliedere es auf, das ist besser" zufrieden ist. Damit wäre alles gesagt.

Du fragst das obwohl Du schon weisst, dass Du bei 200 Zeilen nicht mehr bei einer Datei bleiben willst. Also warum fragst Du dann?

Ja genau, weil ich es wissen will ob man es so machen kann.

Und wenn die Antwort gewesen wäre: "Egal kannst beides machen, macht keinen Unterschied musst nur aufpassen .... " -> Dann hätte alles in 200 Zeilen Scripts aufgeteilt bevorzugt .
Wenn es aber keinen Sinn mach, ja mei.... dann wirds halt ein langes Script. Mag ich halt nicht so gern, davon sterbe ich nicht. Du hast es richtig gesagt/zitiert "bleiben willst". Es ist lediglich eine persönliche Vorliebe, eigentlich schon fast total egal. Nicht mehr nicht weniger. Funktionieren muss es.

Warum muss ich mich eigentlich für jede Frage eigentlich rechtfertigen?
Wenn mich jemand frägt "Du ich hab ein Problem ich möchte gerne 8+3*2 rechnen wie stelle ich das an", dann frage ich doch auch nicht: Erkläre mich doch erst mal, wieso willst das wissen?