Gruselige FOR-Schleifen

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

  • Ich hab letztens noch C#-Code im Stil alter C-Programme oder Basic 2.0 gesehen: Unterprogramme hatten keine Rückgaben, sondern haben globale Variablen gefüllt. Das weckt ein "gewisses" Verständnis dafür, warum man "altmodisch und Hinterwäldlerisch" meiden sollte.

    Das kommt natürlich auch wieder darauf. Innerhalb einer überschaubaren Klasse ist das völlig ok. Denn nach Clean-Code-Vorgaben soll man die Anzahl der Funktionsparameter möglichst klein halten. Es macht keinen Sinn, lokale Klassenvariablen ständig durch alle Methoden durchzureichen.

    Clean-Code sagt aber eben auch, man soll die Klassen klein und überschaubar halten (jede Klasse nur eine Aufabe, keine Sammelklassen).

  • Clean-Code ist doch diese Akademiker-Grütze:

    Die Schreibweise ist falsch! (Abkürzungen schreibe ich nun mal groß)

    Die Funktion ist zu komplex/passt nicht auf einen Bildschirm (Ja, ich zerreisse die auf einen Blick zusammenhängende Logik und verteile die kreuz und quer in der Landschaft, weil irgendwelche Deppen nicht drei IFs hintereinander verstehen)

    Je nach Jahreslage Immer schön this vorne dran, oder immer schön this vorne weg

    So einen Schwachsinn deaktiviere ich inzwischen.

    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.

  • Nicht alles an Clean Code ist falsch, aber ein paar Aussagen von Martin sind schon krass.

    Methoden immer kurz halten (5-10 Zeilen sagt er glaube ich)? Kommt doch ganz auf das an, was man macht. Mehrstufige Algorithmen z.B. sind in winzige Funktionen zerpflückt nicht immer besser zu verstehen als einfach runtergeschrieben, selbst wenn die dann auch mal 100 Zeilen lang sind.

    Oder seine Aussage, dass Kommentare vermieden werden sollten. Total weltfremd, und offensichtlich hat er noch nie was von Annotationen für JavaDoc oder PyDoc und Konsorten gehört und vermutlich auch noch nie eine REST-API geschrieben (bei denen die im Moment üblichen Bibliotheken die HTML-Dokumentation automatisch aus Kommentaren/Annotationen generieren, siehe OpenAPI und Swagger und Co).

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

  • In allen modernen (etwas größeren) Software-Projekten läuft diese "Akademiker-Grütze" zum Beispiel als ESLint oder Sonarqube.

    Bei Verstößen gegen bestimmte Regeln (zum Beispiel Code-Complexity) wird der Commit auf dem Versionsserver nicht akteptiert.

    Findet ihr es nicht ein klein wenig arrogant, alles was im Bereich der professionellen Softwareentwicklung inzwischen Standard ist, als Akademiker-Grütze abzutun?

    Oder seine Aussage, dass Kommentare vermieden werden sollten. Total weltfremd, und offensichtlich hat er noch nie was von Annotationen für JavaDoc oder PyDoc und Konsorten gehört

    Scheint ja hier einige Stammtischsoftwareprojektleiter zu geben, die alles besser wissen. :D

    Möglichst wenig Kommentare heisst einfach nur, dass der Code selbst so verständlich sein soll, dass man nichts kommentieren muss. Aber man kann natürlich auch einfach pauschal alles ablehnen ohne es zu verstehen oder gar mal ausprobiert zu haben.

    Man weiss doch genau, wie solche typische JavaDoc Kommentare aussehen: Eine einfache Wiederholung der Parametername, also genau das was JavaDoc erzeugt. Mit aussagekräftigen Funktionsnamen und Bezeichnern braucht man keinen Kommentar.

    So sieht das doch meistens aus. Braucht kein Mensch, aber Hauptsache dokumentiert.

    Code
    /**
    * Get the name.
    *
    * @return The name.
    */
    public String getName() {
        return name;
    }

    Bitte melde dich an, um diesen Link zu sehen.

    6 Mal editiert, zuletzt von detlef (9. Juni 2022 um 19:50)

  • Mit aussagekräftigen Funktionsnamen und Bezeichnern braucht man keinen Kommentar.

    Das kann man so nicht pauschalisieren und hängt von weiteren Einflüssen ab, wie Projektgröße oder den Fähigkeiten des Programmierers.

    Ich bin mir sicher das bei einem Riesenprojekt wie Linux oder Windows mehr als nur aussagekräftige Funktionsnamen verwendet werden.

    Bei den Fähigkeiten des Programmierers denke ich besonders an meine Person. Da reichen oft keine aussagekräftige Funktionsnamen.

    Vorallem wenn ich mit dem Debugger arbeite und mir vor lauter Klassen der Kopf brummt, dann verwende ich sogar Kommentare direkt im

    Code.

    Public Class TestKlasse

    Public WichtígeVariable As Integer

    #If DEBUG Then

    Public WichtígeVariableStr As String = "Dies ist eine ausführliche Erklärung"

    #End If

    End Class

    Entscheident ist ob der eine oder andere Trick ein Projekt weiterbringt oder nicht.

    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:

  • Mit aussagekräftigen Funktionsnamen und Bezeichnern braucht man keinen Kommentar.

    Entscheident ist ob der eine oder andere Trick ein Projekt weiterbringt oder nicht.

    Ganz genau. :thumbup:

    Deswegen argumentiere ich ja gegen die pauschale Ablehung bestimmter Methoden. Ich habe übrigens gar nichts gegen Kommentare. Ich habe nur sehr viele schlechte Erfahrungen mit überflüssigen Kommentaren gemacht. Und ganz übel: Der Code wird geändert und der alte Kommentar bleibt stehen.

    Einfach beim Kommentieren mal kurz nachdenken, ob eine Änderung des Codes den Kommentar nicht vielleicht überflüssig machen könnte. Um nichts anderes geht es bei Clean-Code.

  • Scheint ja hier einige Stammtischsoftwareprojektleiter zu geben, die alles besser wissen. :D

    Wow, so als Einstieg Ad Hominem...

    Zitat

    Man weiss doch genau, wie solche typische JavaDoc Kommentare aussehen

    ...und dann direkt mit einem Strohmannargument weiter. Muss sowas sein?

    Ich hatte in #143 ziemlich genau dargelegt, warum ich Teil(!)aussagen von Martin für Unsinn halte. Schau nochmal in das Buch von ihm rein! Der hat echt keine Ahnung, was die Tools können, z.B. kennt er keine Postfix-Kommentarnotation und nimmt als Beispiel dafür, dass "Kommentare sehr raumgreifend sind", genau diese hirnverbrannten Beispiele mit JavaDoc-Trivialkommentaren, dazu noch in der raumgreifendsten JavaDoc-Syntax-Variante. Klar bringen die niemandem was! (und dass seine ganze Welt nur Java zu sein scheint, mal ganz außen vor)

    Aber lange Variablennamen etc. bringen nunmal keinen Überblick über z.B. das Zusammenspiel von verschiedenen Code-Teilen; sie erklären nicht, wieso dieser-und-jener vermeintlich hässliche Code nun doch sein muss (Edge Cases); sie erzählen nichts über Lifecycles und so weiter. (und darauf geht er nur mit einem Halbsatz ein, ohne Beispiele zu bringen, wenn ich mich recht erinnere)

    Auf jeden Fall hatte ich beim Lesen des Buches massiv den Eindruck, dass der liebe Mensch nur triviale CRUD-Anwendungen zusammenklöppelt.

    Wenn bei euren Projekten massenweise Trivialkommentare in der Codebasis sind/waren, habt ihr vermutlich nicht funktionierendes Code/PR Review. Das muss man halt den Leuten einmal beibringen, und dann passt das. Linter etc. helfen da nicht weiter bzw. lösen andere Probleme.

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

  • SonarQube benutzen wir auch. Ist ja lustig, und ab und zu findet das sogar etwas, aber das ist dann eine Meldung unter 1000 (!). Das ist ein Problem.

    Die übliche Lösung ist dann, dass man dann anfangen darf, herumzukonfigurieren; den Code also in Regeln nochmal im nächsten Tool nachstellt, damit die Luft-Warnungen nicht auftreten. Bis zur nächsten Code-Änderung.

    Ich mag gerne Tools, wenn die mir helfen, dann müssen die aber auch mit allen Code-Varianten funktionieren. Ich bewege mich mit C/C++ auf Mainframes und C++/C# auf Windows und Linux. Das kann keines dieser Tools abdecken.

    Bei den Kommentaren sehe ich das so, man kommentiert das nicht Offensichtliche (warum wird etwas so gemacht, nicht was).

    Und diese überflüssigen Kommentare, wie du aufführst, die kommen doch genau durch solche Grütze zustande: Es wird erzwungen, dass sämtliche Methoden Kommentare bekommen. Auch bei völlig eindeutigen Einzeilern.

    javaDoc-Kommentare (und Doxygen) sind IMHO schlecht, weil die /* - */ - Kommentare verwenden und die nicht verschachtelt werden können. Kommentiere mal ein paar Funktionen am Stück aus. Da ziehe ich die XML-Doc-Variante von C# vor (/// vorne dran).

    Variablennamen sind bei mir gerne mal ein bisschen länger, ich habe sie lieber eindeutig und aussagekräftig, als dass da irgendwo ein paar Buchstaben weniger zu tippen sind und man nicht immer ganz sicher ist, was die Variable beinhaltet. Für die Länge gibt es seit Jahrzehnten Autovervollständigungen in jeder IDE und besserem Texteditor.

    Wichtiger finde ich, dass bei bestimmten Variablen die Einheit mit im Namen steht. Ich liebe solche Funktionsdeklaration wie Sleep( int Timeout ).
    Ja, was ist denn die Einheit? Sekunden? Minuten? Millisekunden? Dann lieber Sleep( int TimeoutMS )


    Ich bilde mir ein, halbwegs lesbaren Code zu schreiben. Mir ist wichtig, dass man dem Code den Ablauf ansehen kann. IF-Zeilen werden so umformatiert, dass nur eine Bedingung pro Zeile zu sehen ist. Schachtelung von && und || werden durch Einrückungen sichtbar gemacht:

    Code
    if ( ( ( Bedingung1 )
    &&     ( Bedingung2 ) )
    ||   ( Bedingung3 ) )
    {
      // tu was...
    }

    Ich finde zum Beispiel das in letzter Zeit vermehrt verwendete Dependy-Injection viel schlimmer. Man sieht auf einen Blick nicht mehr, welche Klasse tatsächlich verwendet wird. Und man kann nicht in das Programm durch-steppen, weil das Dependency-Injection-Zeug dazwischen hockt.

    Am besten verpackt man das auch noch in eine Factory, weil man könnte ja irgendwann, vielleicht, aber nicht in diesem Zyklus eine zweite Klasse bauen. YAGNI.

    Hatten wir in einem anderen Projekt. Diverse Nachrichten werden in verschiedenen Varianten befüllt. Jeweils Konstruktor aufrufen und Members direkt befüllen. Nein, da musste extra ein MessageBuilder gebaut werden, wo am Ende das Befüllen genau gleich viel Platz verwendet, aber man zusätzlich noch diese olle Klasse hat. Negativer Gewinn IMHO.

    So, genug ausgekotzt :)

    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.

    Einmal editiert, zuletzt von Endurion (10. Juni 2022 um 07:27)

  • Aber lange Variablennamen etc. bringen nunmal keinen Überblick über z.B. das Zusammenspiel von verschiedenen Code-Teilen; sie erklären nicht, wieso dieser-und-jener vermeintlich hässliche Code nun doch sein muss (Edge Cases); sie erzählen nichts über Lifecycles und so weiter. (und darauf geht er nur mit einem Halbsatz ein, ohne Beispiele zu bringen, wenn ich mich recht erinnere)

    Ich kenne das Buch nicht (oder den Autor), muss ich zu meiner Schande (?) gestehen. Ich greife auch nur diesen Punkt heraus, weil der genau in meine Kerbe schlägt.

    Vorausschickend: Persönlich halte ich Kommentare in Programmen für sehr wichtig. Ich denke nicht, dass auch die aussagekräftigste Bezeichnung einer Methode/Prozedur/Funktion/Variable einen Kommentar ersetzen kann. Aber ...

    ... und das passt jetzt zu dem Zitat oben, insbes., weil der Punkt ja schon drin steht: das steht das Wort „wieso“. Meiner Erfahrung nach werden Kommentare häufig suboptimal genutzt und das liegt aus meiner Erfahrung wiederum daran, dass es schlecht erklärt wird, wofür Kommentare eigentlich da sind.

    Was steht häufig in Kommentaren: Entweder „was“ der nachfolgende Code tut, oder „wie“ der nachfolgende Code es tut. Das ist natürlich tatsächlich unnötig, denn das ist ja nur der Code in Prosa erklärt. Das bringt einen anderen Entwickler natürlich nicht weiter.

    Die Frage ist ja nicht: Brauche ich einen Kommentar, um c = a + b nochmal in Prosa zu erzählen? Ich brauche einen Kommentar, der mir sagt: „Das muss c = a + b heißen, weil ...“, denn es könnte syntaktisch auch c = a - b sein. Das ist die Frage: „Ist der Code fachlich/inhaltlich richtig?“ Und das kann der Code alleine nicht erklären. Dafür braucht man einen Kommentar, der erklärt -- z.B. in diesem Fall -- warum es c = a + b heißen muss. (Und Entschuldigung für das super-billige Beispiel.) Die Fragen „Was?“ und „Wie?“ werden durch den Code erklärt, aber die Antwort auf die Frage „Warum?“ steckt nicht drin und dafür braucht man den Kommentar in Wirklichkeit. Finde ich zumindest. Man räumt Zweifel aus und zwar zu einem Zeitpunkt, an dem man als Entwickler noch genau weiß, warum man das so gemacht hat (da ist sie wieder, diese Frage). Zweifel an der fachlichen Korrektheit des Codes auszuräumen, finde ich gut.

    (Man könnte die Idee weiterspinnen und sagen, das dieses „Warum?“ die eigentliche Frage nach der Korrektheit des Codes ist.)

    “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?)

  • Man kann sich natürlich auch auf den Standpunkt stellen, wenn es etwas nicht-offensichtliches gibt, das man kommentieren muss, dann kann man auch versuchen es so umzuschreiben, dass es nichts nicht-offensichtliches mehr gibt ;)

    Ich denke es geht einfach darum, welche Richtung man generell verfolgt. Im Idealfall kann man wirklich alles so schreiben dass es sich selbst erklärt, Ausnahmen wirds aber trotzdem immer geben, dann muss da halt ein Kommentar hin.

    APIs sind ein Sonderfall, die sollten natürlich vollständig dokumentiert sein.

    Von solchen "Lintern" halte ich persönlich aber auch nix, weil die meist doof konfiguriert sind und eben nichts über den Code wissen sondern nur Formalitäten abprüfen können. Solange man das nur als Indiz verwendet, meinetwegen, aber wenn das einen daran hindert, etwas ins Repo einzuchecken, dann finde ich das auch sehr hinderlich und eher kontraproduktiv.

    - 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.

  • Ein stückweit hängt es aber auch davon ab, in welcher Sprache man codet. Assembler ohne Kommentare ist meiner Meinung nach ein Ding der Unmöglichkeit. Weil da der Code eben stark von dem entfernt ist, was man eigentlich tun möchte, und dementsprechend vieles unter "nicht offensichtlich" fällt, egal wie gut die Variablennamen auch sein mögen. Aber da gibts bestimmt auch welche, die das anders sehen.

    - 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.

  • Man kann sich natürlich auch auf den Standpunkt stellen, wenn es etwas nicht-offensichtliches gibt, das man kommentieren muss, dann kann man auch versuchen es so umzuschreiben, dass es nichts nicht-offensichtliches mehr gibt ;)

    und

    Im Idealfall kann man wirklich alles so schreiben dass es sich selbst erklärt

    Ich habe Zweifel daran, dass das immer möglich ist. Wie will man eine fachliche Anforderung und die Erklärung dafür direkt im Code unterbringen? Aber wenn es dafür einen Weg gibt, ich lerne gerne was dazu. Meiner Erfahrung nach funktioniert das nicht und zwar weil die Erklärung dafür, warum (fachlich!) ein Stück Programmcode so aussehen muss, nicht Teil einer syntaktischen oder semantischen Beschreibung sein kann. Die fachliche Anforderung steht ja außerhalb des Programmcodes.

    Leider finde ich momentan keine anderen Worte dafür. Ich möchte nur sagen, ich habe meine Zweifel daran, dass das möglich ist, was Du sagst.

    Ich möchte das gerne auf der Ebene einer großen Applikation für Verwaltungen oder auch Versicherungen sehen.

    “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?)

  • Z.B. externe Libs sind auch so ein Ding: Es ist z.B. völlig unmöglich, OpenSSL zu benutzen und dabei ohne Kommentare lesbaren Code zu erzeugen, weil man haufenweise Ausnahmen und Workarounds einfach benutzen MUSS, weil die API, äh, nicht optimal ist (aber halt außerhalb des eigenen Einflussbereichs liegt) und in dem Umfeld einfach eine Menge teilweise sehr schräge Edge Cases auftreten und behandelt werden wollen. Das gilt ebenso für so ziemlich alle hardwarenahen oder gut abgehangenen betriebssystemnahen Bibliotheken.

    Man kann natürlich einfach den ganzen Code ohne Kommentare schreiben. Hat man halt unsicheren/unwartbaren Code geschrieben und legt den Grundstein dafür, dass die nächste Person, die dieses eine "unnötige" if(a==null) entfernt, eine fette Sicherheitslücke ins Produkt eingebaut hat.

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

  • Aber da gibts bestimmt auch welche, die das anders sehen.

    Ja, Cracker z. B :D

    Viele Grüße,
    GI-Joe
    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. * Bitte melde dich an, um diesen Link zu sehen. * Bitte melde dich an, um diesen Link zu sehen.

  • Wichtiger finde ich, dass bei bestimmten Variablen die Einheit mit im Namen steht. Ich liebe solche Funktionsdeklaration wie Sleep( int Timeout ).
    Ja, was ist denn die Einheit? Sekunden? Minuten? Millisekunden? Dann lieber Sleep( int TimeoutMS )

    In Datenbanken und Schnittstellen verlange ich auch Einheiten, entweder gleich im Feldnamen, oder halt als eigenes Feld, selbst wenn man sich dann fix auf eine Einheit einigt und dort nur eine Konstante einträgt.

    Bringt bloß nix.

    Nicht nur, dass trotzdem cm in mm-Felder geschrieben werden... Anschließend wird sogar noch drüber diskutiert, warum der Maßstab falsch ist.

    Und anderswo bekomme ich Abmessungen in Stück.

    die Antwort auf die Frage „Warum?“ steckt nicht drin und dafür braucht man den Kommentar in Wirklichkeit. Finde ich zumindest. Man räumt Zweifel aus und zwar zu einem Zeitpunkt, an dem man als Entwickler noch genau weiß, warum man das so gemacht hat (da ist sie wieder, diese Frage). Zweifel an der fachlichen Korrektheit des Codes auszuräumen, finde ich gut.

    Ja.

    Im besten Falle beantwortet ein Kommentar die Frage "Bug oder Feature".

    Anforderungen sind unvollständig.

    Fragen werden nicht beantwortet, Absprachen nicht eingehalten, es gibt Termindruck, fehlendes Verstehen, Missverständnisse, unterschiedlich benutzte Begriffe, manche Leute machen es sich leicht oder machen Spielchen, Leute verlassen die Firma, gehen in Rente, sterben...

    Laufen muss es trotzdem.

    Also werden Entscheidungen getroffen, die manchmal äußerst nach Bug aussehen, und im Code kommentiert.

    Später kommen Änderungen, und dann kommen Datum, wer es angefordert hat, was das Problem war usw. hinzu.

    In der Regel lasse ich auch alten Code auskommentiert stehen, bis der alte Krempel irgendwann mehr stört als nützlich ist.

    Und auch "schlichte" Kommentare können zur Orientierung hilfreich sein.

    Excelsheet erzeugen - Kopfdaten - Inhalt - Excel speichern... Das ist alles im Prinzip selbst erklärend. Aber es hilft bei der Orientierung ungemein, weil man nicht den ganzen Quelltext lesen und verstehen muss, sondern nur die paar Kommentarzeilen, um die passende Stelle zu finden.

  • Excelsheet erzeugen - Kopfdaten - Inhalt - Excel speichern... Das ist alles im Prinzip selbst erklärend. Aber es hilft bei der Orientierung ungemein, weil man nicht den ganzen Quelltext lesen und verstehen muss, sondern nur die paar Kommentarzeilen, um die passende Stelle zu finden.

    Das wäre allerdings auch genau etwas, bei dem Martin sagen würde, dass die Strukturierung durch Einteilen in Funktionen passieren sollte und Kommentare schlecht sind.

    Kann man aber meiner Meinung nach immer noch drüber streiten: Werden solche linearen Prozesse in Funktionen aufgebrochen (die aber jeweils nur von einer einzigen Stelle aus angesprungen werden), wird der eigentlich lineare Ablauf vermeintlich nichtlinear und der Betrachter des Codes ggf. verwirrt (wird die Funktion jetzt noch von woanders aufgerufen oder nicht?); die Sache wird unnötig kompliziert (Parameterübergabe nötig); es liest sich einfach schlechter (da Umherspringen im Code nötig).

    Speziell mit Syntaxhighlighting sehen vernünftige Inline-Kommentare häufig besser aus und sind übersichtlicher - ganz wie Du sagst.

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

  • Deshalb schrieb ich "im Idealfall". Ich schrieb auch, Ausnahmen wird es immer geben.

    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.

    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" ;)

    - 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.

  • 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...

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

    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.

  • Wichtiger finde ich, dass bei bestimmten Variablen die Einheit mit im Namen steht. Ich liebe solche Funktionsdeklaration wie Sleep( int Timeout ).
    Ja, was ist denn die Einheit? Sekunden? Minuten? Millisekunden? Dann lieber Sleep( int TimeoutMS )

    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).

    Ich bilde mir ein, halbwegs lesbaren Code zu schreiben. Mir ist wichtig, dass man dem Code den Ablauf ansehen kann. IF-Zeilen werden so umformatiert, dass nur eine Bedingung pro Zeile zu sehen ist. Schachtelung von && und || werden durch Einrückungen sichtbar gemacht:

    Code
    if ( ( ( Bedingung1 )
    &&     ( Bedingung2 ) )
    ||   ( Bedingung3 ) )
    {
      // tu was...
    }

    "||" und "&&" in der gleichen Spalte? Da muss man ja die Klammern parsen, um die Schachtelung zu verstehen. Ich würde das so formatieren:

    Code
    if (((Bedingung1) && (Bedingung2))
    || (Bedingung3)) {
      // tu was...
    }

    Wo ist das Popcorn? :D

    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..

  • 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.

    EDIT:
    Ach so, jett hab ich es verstanden...

    Das _ms in den Namen der Funktion aufnehmen.

    Another workaround? Stay a while... STAY FOREVER!!

    Einmal editiert, zuletzt von Hoogo (10. Juni 2022 um 17:30)