[kaddar]

Maintenance costs are one of the highest costs of software engineering, so when the idioms are very diverse, and you are presented with a new idiom, the best choice is to minimize idioms by only using behaviors which are expectable.

If performance is an issue, then use these obfuscating idioms, but only if you are able to abstract them well and maintain performance (as you suggest), or document them completely and concisely.

[RiderOfGiraffes]

I don't regard this idiom as being at all obfuscating. I agree that people who aren't comfortable in the language will find it jarring at first, and will slow them down, but I don't see this as a problematic example.

There is a balance to achieve. This is one example, and arguing the specifics of this one example is not as useful as being able to make judgement calls in the wild, for real, and get most of the close enough to right. It's not exact.

But idioms, per se, should not be rejected out of hand purely because they're unknown to you.

[kaddar]

Well, focus on writing code that maps to the english or pseudocode definition, and attempt to make the pseudocode definition as high level as possible, if your goal is to minimize maintenance costs.

This idiom obfuscates, as you state yourself, because people who aren't comfortable with the language will find it jarring at first. I understand where you are coming from: If everyone knew it, it wouldn't be obfuscating. But I argue that people forget idioms or never learn idioms that don't map to our human explanations rather quickly, so it increases maintenance costs.

I argue that in this case, it obfuscates simply because bitwise or'ing data is too low level and doesn't have a lot to do with rounding down without understanding the internal representation of the number.

[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>