Programmierstil - Grundsatzfrage



  • ohdochdiegibtes schrieb:

    Ohne Xing erfolgreich schrieb:

    hustbaer schrieb:

    SeppJ schrieb:

    Aber es gibt in den modernen Sprachen keine Ausrede mehr, nicht das Idealbild des selbsterklärenden Codes anzustreben. Es ist nicht schwer. Wenn man es nicht schafft, dann programmiert man nicht gut genug.

    Doch, leider gibt es eine Ausrede: man muss wissen wie man das macht, worauf man acht geben muss etc. Und leider bringt das den Schülern/Studenten keiner bei. Vermutlich weil viele Lektoren/Dozenten/... selbst nicht sauber programmieren können.

    Bzw. vielleicht auch weil das alles sehr subjektiv ist, und daher schwer zu benoten.

    Kein Dozent/Lektor schaut sich an, wie die Studenten programmieren, das Programm muss nur laufen und tun was die Aufgabenstellung verlangt hat.

    Der Code kann wie Kraut und Rüben aussehen. Darauf achtet leider keiner und ich fand das übrigens sehr schade und denke, dass das auch heute noch so ist.
    Denn Code anzuschauen, das dürfte wahrscheinlich zu personalintensiv sein.

    Der gute Herr Breymann (doziert an der HS Bremen) (http://www.amazon.de/Einführung-professionelle-Programmierung-Ulrich-Breymann/dp/3446410236) tut dies sehr wohl. Er schaut genau hin, sehr genau sogar. Wir nannten ihn den "menschlichen Compiler".

    Wann immer etwas falsch, umständlich, unklar oder inperformant war, hat er es auch bemängelt. Alles in allem: Guter Dozent!

    Dann bist du zu beneiden.
    Aber den Herrn kenne ich vom Namen, ich habe mir sein Buch "C++ Der Programmierer" gekauft.



  • GUEST99 schrieb:

    Wenn ihr MISRA-Conformance braucht müsst ihr MISRA-Conformance vorschreiben. Was den Preis vermutlich massiv in die Höhe treiben wird.

    Ist mir schon klar.
    Ist auch ausgeschrieben.
    Dennoch haben beide die angegebenen Argumente.

    Nebenbei, bzgl. höherer Preis:
    Stundensatz ist bei 75-92 EUR/Std.

    Ist das realistisch, dass die sich an MISRA Regeln halten oder ist das zu billig?

    Es wird wohl weniger den Stundensatz beeinflussen als die Stundenanzahl.

    Ohne Xing erfolgreich schrieb:

    Es gibt Programme, die Tools auf MISRA-* Konformität testen.

    Ihr könntet die zwei Codeschnipsel, die ihr von den beiden Programmierern erhalten habt, mit diesen Tools testen, dann wisst ihr auch, wer MISRA konform programmieren kann.

    Was ich über MISRA gelesen habe dürften da einige Regeln dabei sein die man maschinell nicht bzw. nicht sinnvoll prüfen kann.
    Ein "sicher konform" kann man von den Tools also vermutlich nicht bekommen.
    Ein "sicher nicht konform" sollte aber natürlich drin sein.



  • "Selbsterklärender Code" ist kein eindeutiger Anspruch. Aus meiner Sicht gehört (natürlich Übung damit und) vor allem auch Professionalität und Virtuosität dazu.
    Für die einen sind selbsterklärende Variablennamen wichtig, für die anderen eher a,b,c (bzw. i++). Das ist aber letztlich auch eine Frage der Codegestaltung selber.

    Ein komplexer Algorithmus oder eine Funktion mit Schleifenverschachtelung und Variablenverschattung muß nicht gerade sehr übersichtlich sein.

    Bei vielen Funktionen können alle Module einzeln getestet werden und auch woanders weiterverwendet, und so in den tieferen oder höheren Codezeilen kurz dokumentiert.

    Bei Haskell gibt es viele interessante, aber (weil experimentell?) undokumentierte Funktionssammlungen. Das ist die reinste Pest, erschwert das schnelle Einarbeiten oder Überblicken und mindert generell den Bibliotheksstandard. Die Strategie ist dann, dass man eher nach Typen schaut (die ordentlich coden und dokumentieren) als nach Funktionen/Programmen. Die schlechte Übersicht mindert allein nicht den professionellen Anspruch, aber sie ist wichtiger Teil des Problems.



  • 92 schrieb:

    Für die einen sind selbsterklärende Variablennamen wichtig, für die anderen eher a,b,c (bzw. i++). Das ist aber letztlich auch eine Frage der Codegestaltung selber.

    Was bitte könnte jemals das Argument für Bezeichner wie "a,b,c" sein? WTF? Natürlich sind sprechende Namen wichtig -- ganz egal ob Variablennamen oder sonstige Bezeichner.
    i als Schleifenzähler bzw. allgemein anerkannte und verstandene Kurzform von "Index" ist OK. Ist aber auch so ziemlich der einzige 1-Buchstabenname der OK ist.

    92 schrieb:

    Ein komplexer Algorithmus oder eine Funktion mit Schleifenverschachtelung und Variablenverschattung muß nicht gerade sehr übersichtlich sein.

    Weswegen tief verschachtelte Schleifen in einem vernünftigen Programm auch nix verloren haben. Kann man ja schliesslich leicht vermeiden.
    Und auch komplexe Algorithmen kann man meist so implementieren dass zumindest jemand der den Algorithmus kennt und verstanden hat das Programm relativ leicht lesen kann. Und dass jemand der den Algorithmus und nicht versteht zumindest immer noch weiss was abgeht, welcher Algorithmus überhaupt verwendet wird und wo die Implementierung dieses Algorithmus anfängt und aufhört.



  • hustbaer schrieb:

    Ist aber auch so ziemlich der einzige 1-Buchstabenname der OK ist.

    Was ist mit x, y?



  • Mechanics schrieb:

    hustbaer schrieb:

    Ist aber auch so ziemlich der einzige 1-Buchstabenname der OK ist.

    Was ist mit x, y?

    Du hast z vergessen.



  • z ist schon deutlich seltener. Ich hab schon viele Funktionen gesehen, die nichts mit Kooordinaten zu tun haben, bei denen die Parameter aber x und y heißen.



  • Ja, gut.
    x, y, z sind OK.
    Zumindest wenn es wirklich Koordinaten sind und aus dem Kontext sofort klar ist um welches X, Y und Z es sich dabei handelt.

    Bei Vergleichsfunktionen ist auch OK x und y zu nehmen oder auch a und b.

    Viel mehr fällt mir dann aber wirklich nicht mehr ein.



  • hustbaer schrieb:

    Bei Vergleichsfunktionen ist auch OK x und y zu nehmen oder auch a und b.

    Für Vergleichsfunktionen verwendet man lhs und rhs (lihnks und rechts).



  • @lihnks
    Ja.
    Wenn man Pedant und/oder doof ist.
    Realistischerweise muss man aber sagen: lhs und rhs sind optisch VIEL zu ähnlich und daher schlecht.
    a und b ist besser.



  • Hier ist Code von der neuen haskell.org Eingangsseite:

    primes = filterPrime [2..] 
      where filterPrime (p:xs) = 
              p : filterPrime [x | x <- xs, x `mod` p /= 0]
    

    Man sieht sowohl ausgeschriebenes wie auch Kürzel. Da der Code nicht erklärt wird, ist eher vermutlich selbsterklärend genug. Es kommt wie gesagt (genau wie in gesprochenen Sprachen) auf den Zusammenhang an (wie z.B. auch Schreib- oder zur Thematik generell): Lesefaulheit. Wenn man alles und jedes ausschreibt, kann das in gewissen Kreisen oder Programmteilen wie Obfuscation wirken.



  • Ohne Xing erfolgreich schrieb:

    Mechanics schrieb:

    hustbaer schrieb:

    Ist aber auch so ziemlich der einzige 1-Buchstabenname der OK ist.

    Was ist mit x, y?

    Du hast z vergessen.

    und:
    r, g, b, a (selbsterklärend),
    n, m (Matrixdimensionen),
    i, j (Matrix zeilen/Spaltenindex),
    r (Radius),
    t (Zeit),
    c (char),

    es gibt eigentlich eine ganze Reihe 1-buchstabiger Variablennamen, die verstanden werden.

    Daß ein ideales C/C++ Programm so selbsterklärend wie möglich sein sollte, stimmt zwar. Bei Programmiersprachen wie TeX oder apl kann das aber anders aussehen. Da wäre ein unkommentiertes Programm nicht immer ideal.



  • großbuchstaben schrieb:

    und:
    r, g, b, a (selbsterklärend),
    n, m (Matrixdimensionen),
    i, j (Matrix zeilen/Spaltenindex),
    r (Radius),
    t (Zeit),
    c (char),

    es gibt eigentlich eine ganze Reihe 1-buchstabiger Variablennamen, die verstanden werden.

    Ich freue mich immer über so kurze Variablennamen, wenn ich mal keine IDE zur Verfügung habe sondern nur einen einfachen Editor und dann nach diesen Variablen suche. 🤡



  • Gregor schrieb:

    Ich freue mich immer über so kurze Variablennamen, wenn ich mal keine IDE zur Verfügung habe sondern nur einen einfachen Editor und dann nach diesen Variablen suche. 🤡

    Diese Variablen leben sowieso nur höchstens 5 Zeilen, von daher tritt das Problem nicht auf.


  • Mod

    flotterfuenfer schrieb:

    Gregor schrieb:

    Ich freue mich immer über so kurze Variablennamen, wenn ich mal keine IDE zur Verfügung habe sondern nur einen einfachen Editor und dann nach diesen Variablen suche. 🤡

    Diese Variablen leben sowieso nur höchstens 5 Zeilen, von daher tritt das Problem nicht auf.

    Nicht r, g, b, a, r (fällt dir was auf?) oder t, oft auch n und m.



  • SeppJ schrieb:

    flotterfuenfer schrieb:

    Diese Variablen leben sowieso nur höchstens 5 Zeilen, von daher tritt das Problem nicht auf.

    Nicht r, g, b, a, r (fällt dir was auf?) oder t, oft auch n und m.

    Doch, auch die. r, g, b, a als struct-Member sind extrem unhandlich. Die speichert man vielleicht als

    struct color { array<uint8_t, 4> rgba; };
    

    oder als

    using color = math::vector<float, 4>;
    

    t habe ich noch nicht so häufig in einer Klasse gesehen, denn t ist normalerweise das, was sich verändert und das ist dann ein Parameter einer Funktion. Als solche können auch r, g, b, a vorkommen (oder z.B. Konstruktor). Aber dann leben sie auch kurz. Wenn t dann doch mal in einer Klasse vorkommt, kann man auch time schreiben, aber meistens passt dan ein anderer Name besser.

    Genauso ist es mit n und m. Man braucht gar nicht erst beide speichern.

    r (klar habe ich das gemerkt, sie stehen ja nahe beieinander) habe ich lieber als radius, weil ich lokal dann auch oft gerne ein r hätte, und so vermeide ich eine Namenskollision.


  • Mod

    Also kurz: Je kleiner der Gültigkeitsbereich einer Variablen ist, desto lässiger kann man bei der Namensgebung vorgehen. Aber umgekehrt bitte bloß nichts mit nur ein oder zwei Buchstaben und einem Gültigkeitsbereich, der über eine einzelne (Member-)Funktion hinaus geht! Egal für wie einleuchtend man "m" als Bezeichnung für die Spaltenanzahl empfindet.


Anmelden zum Antworten