[dasil003]

There's another code smell that every programming whiz kid produces at some point: over-engineered.

All code has a cost, primitives have a lower base cost because they are universal in the language and thus every programmer will automatically know how to use them. Before introducing a custom object with yet another API to be learned, you need justification.

> Implement Money class if you need to deal with money, it’s much better than using floats all over the place. Don’t use Hash for configuration objects, use a custom Configuration class instead.

Let's pretend he said integer since floats for money is outright broken. Yes, Money is a clearcut case where having a money-specific API is both intuitive and immediately useful.

Configuration on the other hand is debatable. If you're just doing things a hash does then it's fine. If you find yourself with lots of helper methods or repeating the same transformations over and over then that's when you have a code smell that may warrant lifting configuration to its own level.

But the critical thing is to remember that there's a non-trivial cost to creating domain-specific objects.

[wglb]

Now that is in interesting proposition: Let's pretend he said integer since floats for money is outright broken. On my 32 bit machine, enquire.c tells me that long integers have 32 bits of unsigned value. It also says that doubles have 53 bits of precision. So if you decide to use floats for money, you get bigger numbers than if you use long.

Oh, and might I suggest that you consider doing it in pennies rather than fractional dollars? It will work out better.

Better to understand the underlying territory, I think. That would not be over-engineering.

[nwmcsween]

The justification is simple, to allow for testing concerns the code uses. I see domain specific objects the same way I see domain specific languages - if I cannot grasp it by looking at it then it's broken, meaning I should not have to read documentation but simply understand the domain the object / language represents e.g sinatra get()... etc.

[dasil003]

You state that as if it's a universal justification, but the same standard applies. If your code enough is simple enough to use primitives, then you're unit tests are testing the next higher level of abstraction. If the complexity rises to the level of justifying it's own class, then you should probably have unit test coverage on that.

Also, regarding DSLs, there is a tradeoff there that's worth commenting as well. A DSL pays the most dividends when the domain is understood (such as HTTP in the case of Sinatra), but if it's custom business logic than there may not be enough common business understanding for a DSL to be intuitive, and in that case it's just another layer of indirection to follow through as you inspect the code to figure out what it's actually doing. Half-baked DSLs are harmful IMO.

[tzs]

> Let's pretend he said integer since floats for money is outright broken.

This reminds me of a story I read on Reddit that someone told about his dog. The first time his dog saw a horse, the dog was excited, and ran up to sniff the horse through the fence.

It was an electric fence, and the dog touched it with his nose. The dog found this extremely unpleasant.

Now the dog is deathly afraid of horses, and runs and hides whenever he sees a horse.

[dasil003]

You're being obtuse. What's your use case for money as floats?

[tzs]

On some 32-bit machines, a double precision float often exactly represent a larger range of integers than the integer types can, which makes it easier to avoid overflow problems you can get if you work in integers.

Of course, one might argue that the programmer using integers should be aware of this, and code accordingly, or else he shouldn't be writing code dealing with money (or any other thing were failure can have serious consequences).

However, the same applies to floating point. Floating point is not magic. A programmer who understands it can safely use it.

Many programmers seem to get burned early in their careers by using floating point without understanding how it differs from real numbers. Then, like the dog concluding that the horse, rather than the fence, was the problem, these programmers conclude that it is not safe to use floating point instead of properly concluding that they should not use tools they don't understand.

[Negitivefrags]

I think his point is that the OP got burned using floats for money. He thought the lesson was to use a custom class for money every time, but the actual lesson could have just been to use integers instead.

[tzs]

Actually, the point was don't blame your tools.

If you understand how floating point works, you can deal with the rounding and truncation errors, and get accurate results for monetary calculations.

[dasil003]

Ah right, that makes sense.

[yummyfajitas]

Realtime trading systems.

If your system is slow, you lose money. If your trading system says you earned $1,523,374.54, but your accounting system says you only earned $1,523,374.26, you don't care much.

[CodeMage]

I'm genuinely curious here: why would using integers be slower than using floats? I thought floating point operations were always more expensive than handling ints.

[yummyfajitas]

For simple accounting, it wouldn't be slower. The issue is analytical code, e.g.:

    int price = getPrice(symbol);
    double signal = exp(...) * ((double)price);
    if (signal > threshold) {
        buy(symbol);
    }

The point is to avoid converting from int to double every single time you need to do a calculation.