rant These are the sort of programmers I have to deal with

[jevansio]

The code looks like it's trying to turn an int (the percentage payout - I'm guessing intended to be between 72 and 98) into an enum.

 

Becuase the enum is non-typed, the underlying implementation actually generates ints starting at 0 to represent the enumeration. The rewrite is taking advantage of this fact by implementing the conversion as a mathematical algorithm:

 

(PercentagePoint - 72) divided by two, rounded down.

 

(use of the bitshift is a fast way of doing divide by two, round down).

 

To me - the bitwise shift is non-obvious, the ab(use) of the fact that the enum is actually an int is risky, and the edge/error cases (PercentagePoint98) are now handled differently, but the new implementation will be a lot quicker.

It's a decision for absolute performance vs. defensive coding and maintainability, IMO

Sorry I should have read your first post as it pretty much sums up my thoughts/feelings on the code snippet

[BazzaAlpine]

looks like the sort of code I'd do but then I'm a QA'er not a programer.

[Nodalmighty]

Percentage Payout can only be 72 to 98 percent. That is hard coded in the shell as it's HMRC law for AWP. I work in games, where code speed above and beyond is the order of the day. Engine management code requires the same level of optimisation. I know what assembler the complier will produce from the C code, that is why giving it a helping hand makes for better underlying machine code. The enum is only used within this function so changing it would not effect any other code.

 

I don't know what's more worrying, That people found my 1 line of code difficult to read or the fact someone tried to justify 13 nested if else statements as good coding practice.

[kjgreen3]

10 Bad Programmer

20 Goto 10

 

[caseys]

http://www.pbm.com/~lindahl/mel.html

 

Now that's programming.

 

EDIT :

 

[MrRalphMan]

I think I see what's wrong here, there are comments. Urrgh.