[RiderOfGiraffes]

I disagree. Just because it's unfamiliar and hence "jarring" does not, of itself, means it's obfuscating.

I agree that code should be written at the highest level possible to express the intent, but sometimes that's not possible. In this case it's likely that performance wasn't an issue, and this particular idiom is actually of no value, but I contend that the principle remains: an idiom need not immediately be clear, and yet can still sometimes be the right thing to do/use.

Your last point is simply acknowledging that this is an idiom - what you say is characterising what an idiom, as opposed to an expression, is. It's not what you might expect, it's short, it accomplishes its purpose.

Finally, and again, I say that this particular example may not be a good one, but I say again that sometimes idioms are appropriate. You may disagree, but you haven't persuaded me. Our experiences no doubt differ, and may be the root cause.

[jacobolus]

I don’t understand why you’re making this an argument over the precise definition of “obfuscate” and “idiom”.

It’s clear that using the bitwise or operator adds some bit of mental overhead, at least the first few times the reader looks at it, while floor is completely obvious and clear to the average novice programmer. This mental overhead slows the reader down, and makes the code harder to understand. If it’s just one line like that every few hundred lines, or some optimization in an inner loop that is clearly commented, that’s not a problem. But code written by someone who has decided that all of their tricky lines that first look like one thing but actually do something unexpected are actually wonderful “idioms”, is code that can become a serious pain in the ass for whatever poor sap has to build on top of it or fix its bugs.

[RiderOfGiraffes]

I'm trying to explain that the words "obfuscate" and "idiom" have meanings that aren't actually "OH GOD - DON'T DO THAT!!!"

Well, "obfuscate" does, but "idiom" doesn't.

Consider. I've dealt with people who were considered above average programmers and yet for whom "floor" wasn't obvious. They needed to look it up, and then they needed to look it up again when they saw it the second, and sometimes the third time. It cost them mental overhead because it was something they didn't know immediately, it's in a library, they needed to find it, and it's not actually part of the language.

The bitwise operators, however, they knew immediately. They were part of the library, they could immediately deduce what was happening, because it was part of the language. They were glad that someone didn't use some library call that they'd have to look up, and instead used the actual language itself, the built-in operators. And it was clear from the context that the desired result was an int that was close to, and preferably smaller than, the float they started with.

So there's an alternative viewpoint, and one from my direct personal experience. I agree entirely that code should express the intent of the programmer, and it should be clear, and that future maintenance is critical.

I'm not for a moment advocated that every clever, unobvious, difficult to disentangle trick you know should be used. Of course it shouldn't. Code should be clear, concise, and express its purpose.

But it should, above all, be maintainable. And sometimes an idiom is short, precise, unambiguous and does what is needed, and sometimes it's easier to simply regard it as an idiom of the language and get on with it.

Sometimes idiomatic code is, well, OK.

And I'll stop there. Feel free to disagree, feel free to dismiss my experience, thoughts and comments with an airy "no - it's not maintainable - it's not instantly readable - it's not possible for a programmer with no experience to modify effortlessly." It's not fashionable to expect maintenance programmers to have brains and skills.

Sorry. </rant>