Currency oder Double

[Dejan Vu]

Erstmal richtig: Auskennen muss man sich.

Bei Double wird aus klaren Anweisungen dann leider idiotischer und unverständlicher Code.
Beispiel:
Vorgabe: Abheben darf ich einen Betrag X, wenn der auf dem Konto verbleibende Betrag nicht kleiner als der Dispo ist. Oder einfacher: Die Bedingung lautet 'Betrag - X >= Dispo'. Das möchten wir bitte so im Code umsetzen. Aber was muss ich stattdessen machen? 'Abs(Betrag - X - Dispo) >= Epsilon'! WTF?

[bernau]

Zitat von Dejan Vu:

Erstmal richtig: Auskennen muss man sich.

Bei Double wird aus klaren Anweisungen dann leider idiotischer und unverständlicher Code.
Beispiel:
Vorgabe: Abheben darf ich einen Betrag X, wenn der auf dem Konto verbleibende Betrag nicht kleiner als der Dispo ist. Oder einfacher: Die Bedingung lautet 'Betrag - X >= Dispo'. Das möchten wir bitte so im Code umsetzen. Aber was muss ich stattdessen machen? 'Abs(Betrag - X - Dispo) >= Epsilon'! WTF?

Dafür kann man sich schöne sprechende Funktionen schreiben

[Dejan Vu]

Zitat von bernau:

Dafür kann man sich schöne sprechende Funktionen schreiben

If IsLessThan(X-Y,Z) then ist ja auch viel besser lesbar als If X-Y<Z then .. oder war das doch anders herum?

Ach ja, und immer (auf)runden. Und aufpassen. Immer aufpassen. Und hier noch ein Runden und da noch eins.

Also ich nehm lieber den einfachen Weg und nimm kein Double.

[BUG]

Man könnte sein Double (oder was auch immer) auch in einen eigenen Typ (record) packen und dessen Operatoren so definieren wie man es braucht.
Genauso lesbar, aber etwas flexibler

[Dejan Vu]

Die Operatorenüberladen hatte ich ü-ber-haupt-nicht auf dem Schirm Das wäre der geeignete Workarund.

Wobei -zumindest aus meiner Erfahrung her- immernoch die blöden, teilweise unmotivierten Rundungen kommen.

Ich würde Currency für eine Währung nehmen und jede Umrechnung (Steuer, Abschlag, Währung etc.) über eine wohldefinierte Funktion abbilden. Denn diese sind bis auf den Cent definiert und über Unittests abbildbar.

Aber egal. Das Thema ist durch.