Gruselige FOR-Schleifen

Es gibt 165 Antworten in diesem Thema, welches 17.725 mal aufgerufen wurde. Der letzte Beitrag (11. Juni 2022 um 02:54) ist von oobdoo.

  • warum nicht einfach sleep(int milliseconds)?

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Da würde ich sleep_ms(int timeout) bevorzugen, dann sind sogar Aufrufe mit Literalen noch verständlich lesbar (dass symbolische Konstanten meist besser wären, steht auf nem anderen Blatt).

    Das hab ich nicht verstanden.

    Endurions Beispiel macht deutlich, dass die Funktionsdeklaration mit Einheit deutlich lesbarer ist. Mein Beispiel sollte aufzeigen, dass auch die Funktionsaufrufe durch die Einheit lesbarer gemacht werden können:

    sleep(300); vs. sleep_ms(300);

    Natürlich hätte dann sofort jemand eingewandt, dass Literale wie 300 im Code nichts zu suchen haben, und wenn da statt 300 korrekterweise TIME_DURATION_BETWEEN_THIS_ONE_THING_AND_THAT_OTHER_THING_ms gestanden hätte, man die Einheit ja daran ablesen kann und man sie somit nicht im Funktionsnamen braucht - deshalb mein Disclaimer in Klammern.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

    Einmal editiert, zuletzt von Mac Bacon (10. Juni 2022 um 17:49)

  • Man kann sich trotzdem selbst zum Mantra machen, zu versuchen, alles möglichst selbsterklärend zu schreiben. Und da wo es halt nicht geht, da macht man halt nen Kommentar. Anstatt z.B. nach der Vorgehensweise vorzugehen, einfach wie Kraut und Rüben zu coden, weil man sich sagt, da kommt ja dann eh ein erklärender Kommentar hin.

    So hab ich es auch nicht gemeint. Man kann und soll vor allem schon ordentlich programmieren. Ich befürchte, ich kann meinen Punkt nicht rüberbringen. Meiner Erfahrung nach gibt es Dinge, die nicht durch den Code erklärt werden können, egal wie sauber der auch immer ist, und egal, wie sehr man sich bemüht, selbsterklärenden Code zu schreiben. Betrachte es bitte weniger von der Seite dessen, der Assembler programmiert, sondern aus dem Blickwinkel dessen, der Business-Software programmieren soll. Da gibt es einfach fachliche Details, die eben nicht Teil des Programmcodes werden. Ohne diese Details zu kennen, ist der Prorgrammcode zwar vielleicht selbsterklärend, aber eben nicht in der Form, dass zweifelsfrei sicher ist, dass der Code korrekt ist. Nur weil Programmcode syntaktisch und semantisch korrekt ist, heißt das noch lange nicht, dass er auch fachlich korrekt ist, nur oft genug lässt sich die Fachlichkeit nicht im Code verständlich dokumentieren. Das hat auch gar nichts mit einem Idealfall zu tun. Das ist der Regelfall.

    Es geht hier ja um Regeln und sowas. Ich sagte ja selbst, dass ich diese automatischen Regel-Checker nicht mag. Weil die zu realitätsfern sind. Trotzdem kann man grundsätzlich versuchen den Regeln entsprechend vorzugehen, und z.B. eine unschöne Stelle im Code doch nochmal umschreiben, wenn ein Kommentar nötig war. Sofern es eben geht. Und wenn nicht, dann fällt das halt unter "Ausnahme" ;)

    Gut, mein Punkt hat gar nichts mit Regelcheckern zu tun. Ich sehe das allgemeiner. Regelchecker sind vermutlich realitätsfern. Automatische Tests sind schon besser, aber die sind nur mit hohem Aufwand zu machen.

    Mir geht es, wie gesagt, nicht um dieses “Clean-Code”-Zeug, was auch immer das sein soll. Das find ich jetzt auch nicht unbedingt realitätsnah. Außerdem sagte ich ja auch, dass ich weder den Autor noch das Buch kenne.

    Mir gehts eigentlich darum, Code so zu hinterlassen, dass der nächste Entwickler nicht raten muss, was wirklich damit gemeint war und was der Code tatsächlich erreichen will.

    Ich habe einige Jahre lang Software für (Rück-)Versicherungen entwickelt, auf SAP-Basis, und es war sowieso schwer genug, den Rück-Versicherern aus dem Kreuz zu leiern, wie deren fachliche Prozesse funktionieren. Das kam nur scheibchenweise. Die fachliche Seite bedingt natürlich die Programmierung, das ist klar, aber die Programmierung erklärt die fachliche Seite nicht. Das lässt sich einfach nicht durch Code erreichen. Beispiele kann ich nicht bringen, weil das außerdem bei mir schon über 12 Jahre her ist und ich keine Codeschnipsel aus der Zeit aufgehoben habe.

    Ich sehe auch vor allem keinen Sinn darin, Variablennamen zu schreiben, die den Umfang einer Kurzgeschichte haben. Da ist ein Kommentar mit Sicherheit sinnvoller und übersichtlicher.

    Das andere Extrem wären Variablennamen, die grundsätzlich nur ein oder zwei Zeichen lang sind. Das ist meistens auch Käse.

    Ein ehemaliger Kollege hat immer gesagt: "Man kann Kompetenz nicht durch Regeln ersetzen."... ;)

    Schlimmer: Man kann Inkompetenz nicht durch Regeln ausgleichen! (Das versuchen aber Bürokraten andauernd ... mit entsprechend nervtötenden Resultaten.)

    “64k should be enough for everybody.” (nicht Bill Gates)

    “Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.” (Medieval Aphorism)

    “It's never the PLA!” (Dr. House?)

  • Schlimmer: Man kann Inkompetenz nicht durch Regeln ausgleichen! (Das versuchen aber Bürokraten andauernd ... mit entsprechend nervtötenden Resultaten.)

    Das unterschreibe ich blind. 99% von dem, was einem als "Agile" reingedrückt wird, ist das genaue Gegenteil davon. Regeln noch und nöcher, und wenn es wie erwartet mal wieder vor die Wand läuft, "dann hat man es falsch gemacht".

    Bisher habe ich noch kein "richtiges" Projekt damit gesehen.

    Mac Bacon Pass bloss auf du, ich pack gleich Tabs vs. Spaces aus!

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • 99% von dem, was einem als "Agile" reingedrückt wird, ist das genaue Gegenteil davon. Regeln noch und nöcher, und wenn es wie erwartet mal wieder vor die Wand läuft, "dann hat man es falsch gemacht".

    Huch, das deckt sich gar nicht mit meiner Erfahrung. Mein Arbeitgeber hat vor etwa 10 Jahren begonnen, auf Agile umzustellen (und auch heute kann man sicher noch vieles besser machen), und es sind wirklich alle happy damit (und das schließt explizit die Entwickler mit ein). Die meisten Teams machen Scrum, die anderen Kanban, nur die Researcher haben keinen Bock drauf (und ich glaube zu recht). Die Regeln braucht man eigentlich nur am Anfang, später ergeben sie oder Abweichungen davon sich ganz von alleine.

    Ach so: Ich glaube, ihr macht es falsch :pumpkin:.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Ach so: Ich glaube, ihr macht es falsch :pumpkin:.

    Kann mir nicht passieren. Ich habe eben in meinem Projekt eine DO/LOOP Schleife eingebaut. :Peace

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom: