What's wrong with code above is 1) it does a conditional branch (meaning if.. then... else...) which is unneeded. 2) The "then clause" does an absolute value which is a waste of a function call. 3) The "else clause" does `d = d - (2 * d)` which is a waste of a multiplication 4) possibly with an overflow risk and/or floating point estimation risk.
That said, it's admittedly possible that the programming language above, or the number representation in that code above, have some highly atypical needs that we here on HN don't understand.
Even when these code snippets are cherry-picked they tell enough about their review practices.
>have some highly atypical needs that we here on HN don't understand.
Somebody else checked in another thread. You can use unary minus in VBA.
[1] >One member of the development team, David McDonnell, who had worked on the Epos system side of the project, told the inquiry that “of eight [people] in the development team, two were very good, another two were mediocre but we could work with them, and then there were probably three or four who just weren’t up to it and weren’t capable of producing professional code”.
Also I think the code could just multiply d by -1 which would "reverse the sign".
Even that has some edge cases that should be handled around the maximum value of an integer.
But the main thing to me is that as written this code is confusing and overcomplicating the easy part of the problem.