Software Gore

1181 readers

1 users here now

A community for posting software malfunctions

Deliberately bad software or bad design is not software gore, it must be something unintentional

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient and shear it

founded 2 years ago

MODERATORS

irelephant@programming.dev

139

pretty small subtotal. (infosec.pub)

submitted 2 weeks ago by irelephant@programming.dev to c/software_gore@programming.dev

20 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] Revan343@lemmy.ca 5 points 1 week ago (1 children)

best practice is to store the "imprecise" amount next to it as whatever the database supports. That way, you have the auditable real value ($4.00) stored for use on reports and taxes, and the imprecise ($3.99999999898998888181)

Lol, that feels exactly like writing 'four (4)' in a sentence, I love it

[–] scrubbles@poptalk.scrubbles.tech 4 points 1 week ago

It feels weird at first, but it really is the best safest way to store the auditable amount, and really most of the time with currency you don't need to ever mutate it at the DB level, so why introduce the possibility at all of a precision error. One thing that is common is that you do a order by of your transactions, which is why the imprecise is useful, but then you display the string version to the user. It also keeps the precision rather than truncating the precision off (with money the .00 is important, most banks require exact precision to know that you didn't accidentally have a rounding/truncation error)