Was würdet ihr an diesem Python Code verbessern?

5 Antworten

Weg mit dem "global". Wenn du das Resultat als Funktionswert zurückgibst, brauchst du das nicht. Es ist fast immer eine schlechte Idee, so zu arbeiten.

Du kannst dir auch überlegen, ob du das Mapping von Operator auf Funktion besser lösen kannst. Natürlich funktioniert deine if-elif-Sequenz, aber es ist eine nette Übung sich andere Wege anzuschauen.

Und natürlich Fehlerbehandlung. Was, wenn die Eingabe nicht aussieht wie erwartet?

Ist doch guter code, sehe da keine probleme.

Könntest du aber (raltiv leicht) erweitern dass man mehrere operatoren benutzen kann, also sowas wie 2*3+5.

Quelltext dokumentieren! Mache ich immer, da ich es ziemlich hilfreich finde - vor Allem bei aufwändigeren Anwendungen und wenn man selber (oder wer anders) später reinguckt. Damit ist der Quelltext besser nachvollziehbar! Sollte man sich von Anfang an angewöhnen!

Woher ich das weiß:Hobby – Programmierer, EDV, ... seit den 80er :)

Kommentare - abgesehen von der Dokumentation - sind ein Antipattern und ein Zeichen für schlechten Code.

Daher auch die Redewendung "Kommentare lügen".

Außerdem gibt es im Code des Fragestellers keine Stelle, die eines Kommentars bedarf, bzw. an der ein Kommentar irgendeinen Mehrwert hätte.

1
@TinaAusWien

Bin ich absolut nicht (!) Deiner Meinung!

Bei so "kleinen" Texten gewöhnt man sich das Kommentieren an - was richtig und wichtig ist, zumal man später in Teams arbeitet und für einen selbst in der Praxis!

Gebe Dir gerne einen unkommentierten Quelltext mit 180.000 Zeilen! Also eine von 23.000 Dateien der Software!

Würde mich interessieren, wie lange Du brauchst die eine Stelle zu ändern, wenn Du keine Ahnung davon hast, wo diese eine Stelle - oder in welcher Datei überhaupt - im Quelltext zu finden ist! *praxis_erfahrung

0
@PeterP58

Dann ist der Code schlecht!

Wenn Dokumentation, durchdachtes Design und vernünftige Bezeichner vorhanden sind, erübrigt sich jeder Kommentar.

Das steht auch so in den Büchern "The Art of Readable Code", "Clean Code", uvw.

Sämtliche namhaften Security-Guidelnes, z. B. wie Cert, warnen eindringlich vor Kommentaren.

Ich auditiere oft Drittsoftwarey und sicherheitsrelevante Bugs, die auf schlechte, alte und falsche Kommentare zurücknzu führen sind, tummeln sich im zweistelligen Prozenbereich.

In den 80ern hat man zum Kommentieren geraten, seit spätestens 25 Jahren weiß man es besser.

Kommentare sollten so spärlich wie nur irgend möglich eingestzt werden. Meistens sind sie ein Zeichen für schlechte und fehlerhafte Programmierung. Und das hat auch nichts mit Meinung zu tun.

Zeig doch mal einen ausführlch kommentierten Quelltext, dessen Kommentare wirklich sinnvoll sind, und der anderweitig KEINE anderen Probleme hat. Du wirst so etwas nich findn können!

0
@TinaAusWien

Jede Open-Source-Software ist ausführlich dokumentiert und kommentiert!

// define additional filters //
...
//fsk18 lock
...
//group check
...
//manufacturers if set
...
//include subcategories if needed
...

Ansonsten findet sich ja niemals zurecht - vor Allem nicht, wenn da 30 Leute dran arbeiten ...

0
@PeterP58

All die genannten Kommentare sind ohne die folgenden Codezeilen belanglos.

Aber auf den ersten Blick sehe ich mich bestätigt. All deine genannten Kommentare deuten auf schlechtn Code hin.

  • define additional filters: Dieser Kommentar sagt NICHTS aus. Was für Filter? Worum geht es? Warum wird überhaupt in additional und nicht-additional getrennt? Fragen über Fragen, die durch gute Bezeichner und gutes Design, nicht aber durch solch einen Kommentar, beantwortet werden.
  • fsk18 lock: Nichtssagend. In welchem Kontext steht das? Hätte man nicht einfach eine Funktion "fsk18_lock(context)" definieren können?
  • group check: Was soll das? Unter "Gruppe" kann man eine Million Dinge verstehen. Worum es geht, verrät der Kommentar nicht mal ansatzweise.
  • manufacturers if set: Das gleiche! Absolut Null komma Null Mehrwehrt. Solche Kommentare sind reines Rauschen.
  • include subcategories if needed: Warum nicht einfach "if (subcategories_needed) { include_subcategories(); }" oder so ähnlich?

Ausnahmslos alle von dir genannten vermeintlichen Beispiele von guten Kommentaren, sind also exakt das Gegenteil.

Deshalb frage ich dich jetzt nochmal ganz ausdrücklich: Kannst du hier mal zwei oder drei - deiner Meinung nach - gute Kommentare MIT den dazu gehörigen folgenden Codezeilen posten?

Denn auf Ratespielchen habe ich keine Lust, und offensichtlich war alles, was bisher kam, ein wunderbarer Nachweis dessen, was ich kritisiert hatte.

Also nochmal: Nenne mir doch bitte mal einen Quelltext mit wirklich guten und sinnvollen Kommentaren, der keine groben Designprobleme (wie alle deine Beispiel oben) hat.

Ein Link zu einer Quelltext-Datei bei GitHub & Co tuts auch.

Ich bin gespannt ... weiß aber, dass du da nichts finden wirst. :)

0
@TinaAusWien

Die genannten Beispiele von mir sind natürlich aus dem Kontext gegriffen - das dürfe aber klar sein!? o_O Die dienten nur als Beispiele!? o_O

Beispiele mit // Kommentar:

for ($i = 0, $n = sizeof($products); $i < $n; $i ++) {

// Push all attributes information in an array

 if (isset ($products[$i]['attributes'])) {

while (list ($option, $value) = each($products[$i]['attributes'])) {

//scalepriceoption_module pa.options_values_scale_price in query added

$hidden_options .= xtc_draw_hidden_field('id['.$products[$i]['id'].']['.$option.']', $value);

0
@PeterP58

Soll das jetzt ein Witz sein? Der Code ist eine totale Katastrophe!

Und zwar sowohl Programmier- als auch Designtechnisch.

Und da helfen auch die sehr schlechten Kommentare nicht drüber hinweg. Der Sinn erschließt sich mir nicht zu 100%, trotz mehrmaligem Lesen.

So wirds richtig gemacht, ohne Kommentare, mit Struktur, vernünftigen Bezeichnern, und Dokumentation:

foreach ($products as $product) {
  generate_hidden_fields($buffer, $product);
}

Dabei sähen die Funktionen so aus:

function has_attrs(&$product) {
  return isset($product['attributes']);
}

function generate_hidden_fields(&$buffer, &$product) {
  if (!has_attrs($product)) {
    return;
  }

  foreach ($product['attributes'] as $option => $value) {
    add_hidden_field($buffer, $product, $option, $value);
  }
}

function add_hidden_field(&$buffer, &$product, &$option, &$value) {
  // xtc call hier hin ...
}

Da aber auch Funktionen mit mehr als 2 bzw. maximal 3 Parametern ebenfalls ein Antipattern sind, würde ich alles ordentlich in eine Klasse verpacken.

Außerdem habe ich mir jetzt Dokumentationskommentare gespart, weil der Code auch so lesbar sein sollte und ich ehrlich gesagt zu faul dazu bin.

So, und jetzt plötzlich ist der Code auf einmal viel übersichtlicher, tatsächlich lesbar, wartbar und testbar geworden.

Ein Einsteiger ohne Erfahrung sieht bei meinem refaktorisierten Code auf den ersten Blick, was passiert, was vorher unmöglich war und viel mehr Zeit in Anspruch nahm.

Ich hoffe, das ist nicht dein Ernst, dass du vorher den Codeblob mit den wirren Kommentaren aus deinem Snippet, als gutes Beispiel vorführen wolltest.

Dein Codebeispiel vereint schlechten Stil, alte Programmiertechniken und eine ganze Hand voll Antipatterns sehr "elegant" auf engstem Raum. :)

Ich halte mal fest: Bis jetzt hast du es nicht geschafft, mir einen einzigen sinnvollen Kommentar zu zeigen, der - guter Code vorausgesetzt - auch wirklich sinnvoll ist.

Denkst du nicht auch langsam, dass ich evtl. recht habe, wenn ich sage, Kommentare schaden und sind ein Zeichen für schlechten Code?

Du darfst hier gerne noch weitere Codebeispiele posten, wenn du meinst, auch nur einen einzigen sinnvollen Kommentar gefunden zu haben! Viel Erfolg! ;)

0
@TinaAusWien

Ohne Kommentare und Dokumentation - was man sich von Anfang an angewöhnen sollte - geht es nicht!!! Was ist daran so schwer zu verstehen? o_O

Mein aktuelles Projekt besteht aus 2.074 PHP-Dateien, wo die größte PHP-Datei 965 KB groß ist! Das sind in diesem Fall in nur der einen Datei: 26.365 Zeilen Quelltext!!! [< habe für Dich nachgeguckt!]

Wenn ich jetzt einen Angestellten/Externen damit beauftrage eine Änderung durchzuführen - oder Dich!! - dann brauchst Du wie lange um die Datei und darin die Stelle zu finden wo die Änderung vorgenommen werden muss? o_O

Gehe mal davon aus, dass das ohne Dokumentation nicht in 5min erledigt ist!

0
@PeterP58

Jetzt lenk bitte nicht ab!

Ich habe von Anfang an (sogar in meiner Antwort direkt) geschrieben, dass eine Dokumentation nötig ist.

Es geht hier um Kommentare im Code, so wie in deinem Beisspielsnippet. Nicht mehr, und nicht weniger!

Und solche Kommentare (also nicht die Dokumentation!) sind grundsätzlich sinnlos.

Und du hast mir immer noch keinen Codeschnipsel mit sinnvollen Kommentaren gezeigt.

Meine Aussage ist: Kommentare sind ein Zeichen für schlechten Code und bei sauberem Code sind Kommentare grundsätzlich überflüssig. Bisher kam von dir aus kein richiges Argument dagegen.

Und mal ganz nebenbei: Deine Riesendatei mit zich tausend Zeilen Quelltext ist eine Katastrophe, und du solltest wirklich mal Softwareentwicklung lernen, falls du so etwas produktiv einsetzen willst.

Dass man es bei der Länge von Quelldateien möglichst nicht übertreiben sollte, gilt für ALLE Programmiersprachen.

Es ist ein Zeichen für Totalversagen im Designprozess, fehlender Aufteilung und keinerlei Struktur.

Meckern deine Tools zur statischen Codeanalyse dabei denn gar nicht?

Ich muss ehrlich sagen, dass ich Codepfusch bisher größtenteils von PHP-Entwicklern kenne. Und du scheinst da keine Ausnahme zu sein.

Ich denke, PHP-Entwickler haben mehr Probleme damit, über den Tellerrand zu schauen und sich weiter zu bilden, als Programmierer anderer Sprachen.

Normalerweise würde ein Python-, Ruby-, C++-, C#-, Java- oder Wasauchimmer-Programmierer Gedanken zu meinen Aussagen machen, danach Googeln und erkennen, dass Kommentare (und ellenlange Quelldateien) totaler Mist sind.

PHPler haben oft Probleme damit, über den eigenen Schatten zu springen, sich Fehler einzugestehen, und in Zukunft zu vermeiden.

Aber egal, ich hab eine Buchempfehlung für dich: "Weniger Schlecht Programmieren". Das wurde von PHP-Entwicklern geschrieben, und hat ein ganzes Kapitel über die Schädlichkeit von Kommentaren und ebenfalls eins zu Bllob-Dateien.

Ernsthaft, du machst auf mich den Eindruck, noch nicht allzu viel Erfahrung zu haben. Solltest du hingegen schon länger in dem Bereich arbeiten, dann umso schlimmer.

Du solltest dich DRINGEND weiter bilden! Bisher war so ziemlich alles, was du schreibst, bekannte Antipattern, Codesmells, und deine Quelltextbeispiele auch nicht wirklich so doll.

Lies auf jeden Fall "Weniger Schlecht Programmieren" vom O'Reilly-Verlag. Das Buch richtet sich genau an Leute wie dich, und wurde von Leuten geschrieben, die laut ihren eigenen Aussagen früher die gleichen Fehler gemacht haben, wie du jetzt gerade.

Ich garantiere dir, dass du deinen PHP-Code nach der Lektüre dieses Buches wegwerfen und einen Rewrite vorziehen wirst! ;)

Viel Ergolg beim Lernen!

0

Eine Funktion schreiben der deine Eingabe parst, sodass du auch 3+4-5*8 etc. schreiben kannst.

wie könnte die aussehen?

0
@PythonNeuling00

Überleg dir doch mal die Komponenten deiner Funktion.

Zuerst solltest du deinen input String nehmen und die Zahlen und operanden irgendwie extrahieren und in einer Form speichern mit der du gut weiterarbeiten kannst.

Dann schaust du wie du diese mathematischen Operationen auf die Zahlen anwenden kannst. Dabei sollte man dann punkt vor Strich Rechnungen beachten. Vllt bietet sich auch ein rekursiver Ansatz an.

0

Ist es wirklich notwendig die globale Variable "res" zu verwenden?

Wenn es anders auch geht könntest du satt dieser Funktionen auch so etwas verwenden:

operation = {
    '+': lambda a, b: a + b,
    '-': lambda a, b: a - b,
    '*': lambda a, b: a * b,
    '/': lambda a, b: a / b}

print(operation['+'](1, 1))
print(operation['*'](2, 5))

Ich finde Lambda Funktionen in einem Dictionary währen eine kürzere Variante.

Woher ich das weiß:Hobby

Was möchtest Du wissen?