Comment On Enterprise Beautification

I am dum.  I dun get it.

I think the best part has to be the fact that the zeroes are appended to the number in a separate step from the decimal place.

Although the fact that they don't just use the single string builder means that they're not only the Vendors of the Core Enterprise Foundation, they're also Clients.

(Incidentally, Alex, the decimal place is missing.  Did you mis-anonymize this code?)

I'll hazard a guess that before obfuscation, this was an ordinary COBOL program.

 

Well that's great, that's just fuckin' great man. Now what the fuck are
we supposed to do? We're in some real pretty shit now man... That's it
man, game over man, game over! What the fuck are we gonna do now? What
are we gonna do?

Finally, another real coding WTF, and dear lord is it ever heinous.

I am more thankful every day mine is a small company.

>:3

So I would need to perform a string comparison to check for an invalid response?.. What if the number I passed in was -1?

Very enterprisey indeed.

  //throw exception if bad input
  if (field.Length == 0 | entity.Length == 0) return "-1";

Nice exception! And there was me thinking that in this situation a System.ArgumentOutOfRange exception would have been more appropriate

But, what if the user wanted $0.00 to show up for 0 cents?  Does
this mean I have to program an if statement to change "0" to "0.00"
whereever I want that "beautification"?



Also, would this really work in the first place anyway?

  //throw exception if bad input

  if (field.Length == 0 | entity.Length == 0) return "-1";

OK, see, that's not an exception.

Alex!  This is great!  ...a shining example of how really good marketing can overcome the WORST kind of software design.  Way to go.  Thanks for another good wtf.

Oh yeah, I think I like the Sumo Lounge girl even better than the Fooseball girl. 

I'm slightly confused... or maybe that's the point.  Unless there was a mixup during the typing/anonymization phase of writing this, doesn't this code simply prepend zeros to the number string?
Passing 120 into this function and getting places = 1 would return 00120.... wtf?

BRING BACK FOOSBALL GIRL!!!!!!!

Anonymous:

  //throw exception if bad input
  if (field.Length == 0 | entity.Length == 0) return "-1";

Nice exception! And there was me thinking that in this situation a System.ArgumentOutOfRange exception would have been more appropriate

Exceptions are not Enterprisey enough.

I mean, writing code specifically to create errors? Are you insane?

Anonymous:

  //throw exception if bad input
  if (field.Length == 0 | entity.Length == 0) return "-1";

Nice
exception! And there was me thinking that in this situation a
System.ArgumentOutOfRange exception would have been more appropriate

The CEF has removed all references to extraneous exceptions. The only
two exceptions used are System.YouDoneScrewedUpNowException and
System.TragicMisuseOfTechnologyException.

It's standard practice to represent floats/decimals in integer form. Otherwise you get funky rounding things happening when you multiply or divide. It's just a fact of life. It gets worse in finance, as some things go to 32'nds and beyond and you are using a large value to begin with.

Soo... typically you'd do everything in integer/long form and display it in float/decimal form to minimize the damage by using String manipulation.

No, finance people do not like it when numbers get botched out of their control. :)

Anonymous:

  //throw exception if bad input
  if (field.Length == 0 | entity.Length == 0) return "-1";

Nice exception! And there was me thinking that in this situation a System.ArgumentOutOfRange exception would have been more appropriate

Not to mention that if the 'number' parameter was -1, the caller checking the return value is going to be quite confused.

Wow.... that's quite definitely the most useful function ever written by anyone.... EVER!

I
want to test the function, so I'll call it with the number 75, and then
field and entity I don't know what I'll use, so I'll assume that the
only time they are used (int places = this._getDecimalPlaceForField(field,entity);) will assign... uh... lets say 4 to the value of places.

First, we build a string of zeros.... since places was 4, this string will have 5 elements....

quite simple loop, and when we are done, zeros is "00000".

now, lets make a string called value, and we'll set it equal to "00000" + "75". So in other words, value is not "0000075".

Finally,
we have to insert the decimal place. We do this by taking two
substrings of the value string. To make it easier to read, i'll point
out again:

value.Length == 7;
places == 5;

our first substring starts at the first character, and is (value.Length - places) in length (2). The first string is "00".

our second substring starts at (value.Length - places) and goes for places length. The second string is "00075".

So
now, FINALLY, the decimal is inserted when the strings are added
together and returned when value gets it's final assignment, and thus
equates to "0000075".

BRILLANT!!!

I wonder what their system does for dates?

Makes me wonder what the ReturnBooleanResult() method looks like.

No! Wait! I was only kidding.

Yes, doing math in cents for money (other than for things like corporate profits and government budgets) eliminates lots of round-off errors.  It's actually much better for calculation of sales tax and that sort of thing.  Don't sneer at money math in cents--it's what's for dinner!

gmerideth:

So I would need to perform a string comparison to check for an invalid response?.. What if the number I passed in was -1?

Now before you go and say, wait a minute, money can be negative in the real-world, let me tell you that's just not true. Negative money is simply positive money that you owe to somebody else. There's probably another function to return (1.00) or something like that to indicate this "reverse-postive-beautified-integer."

I guess booleans and datetimes are just for suckers. I mean who would ever want to subtract or add dates, or set a series of properties to the same boolean value....

Gotta wonder how far it went, were enum's banned? Structures?

You also gotta wonder how they enforced this pile of steaming waste, it's not like you can just remove standard value types from .Net....

-Me

I am a fan of the CEF because I have always hated decimal numbers.

 

DOWN WITH PI!!!!

 

haha captcha = STFU

Anonymous:

Anonymous:

  //throw exception if bad input
  if (field.Length == 0 | entity.Length == 0) return "-1";

Nice exception! And there was me thinking that in this situation a System.ArgumentOutOfRange exception would have been more appropriate

Not to mention that if the 'number' parameter was -1, the caller checking the return value is going to be quite confused.

Don't think negative numbers exist in enterprise...

Taevin:

I'm slightly confused... or maybe that's the point.  Unless there was a mixup during the typing/anonymization phase of writing this, doesn't this code simply prepend zeros to the number string?
Passing 120 into this function and getting places = 1 would return 00120.... wtf?

I wonder what substring would do when asked to return the substrign starting at index 2 and proceddign to index 1?

If the number you submitted was 1222 and you wanted 2 decimal places, the return should be 0000

Is function is pretty messed up in so many places...

Soooo...instead of storing all numbers as decimals and just tuncating 0 to n characters after the decimal based on how the user wanted to display the number, they decide to complicate this by making everything integers, not to mention that one can no longer have large decimal places (i.e. .4294967297 can not exist) and they've only added to the complexity by stating that you have to take an ordinary integer value and add a decimal to it, instead of saying it's a number, just tell us how many places after the decimal you want to see...

I just wonder what the function would look like to add 0.0234 + 1.0417.....or even worse, division...

 I got totally confused trying to anonymize this; the original was much harder to follow. Passing in 120 with places=1 should return 12.0, Passing in 2 with places=3 should return 0.002; who knows if the revised one still does that.

The "throw exception" returning a "-1" was in the original code.

gmerideth:

So I would need to perform a string comparison to check for an invalid response?.. What if the number I passed in was -1?

Very enterprisey indeed.

You're not thinking enterprisey-enough. There are no negative numbers. Only integers >= Zero are "real" numbers. If you want to use negative numbers, you have to use the NegativeNumber wrapper object, with it's all-XML implementation:

 

<NegativeNumber>

  <SIGN>-</SIGN>

  <DIGIT>1</DIGIT>

  <DIGIT>2</DIGIT>

  <...>

</NegativeNumber>

Anonymous:

Taevin:

I'm slightly confused... or maybe that's the point.  Unless there was a mixup during the typing/anonymization phase of writing this, doesn't this code simply prepend zeros to the number string?
Passing 120 into this function and getting places = 1 would return 00120.... wtf?

I wonder what substring would do when asked to return the substrign starting at index 2 and proceddign to index 1?

If the number you submitted was 1222 and you wanted 2 decimal places, the return should be 0000

Is function is pretty messed up in so many places...

No, all the function does (assuming Alex got it right - sorry Alex, this is just such a bizarre function it seems like the laws of physics demand that it was a mistake on your part :D) is prepend places + 1 zeros in front of the number string.  If the number is 1222 and places = 2, you get 0001222.

Alex Papadimoulis:

The "throw exception" returning a "-1" was in the original code.

...and that's the most delightful part.

Jesus Christ:

>:3

God damnit, we've been 4chan'd.  Get in the car.

Alex Papadimoulis:

 I got totally confused trying to anonymize this; the original was much harder to follow. Passing in 120 with places=1 should return 12.0, Passing in 2 with places=3 should return 0.002; who knows if the revised one still does that.

My guess is that you forgot to add the decimal separator (if it is "." it is another WTF as every sensible culture uses "," for decimal separation) and strip any extra leading 0s...

Alex Papadimoulis:

 I got totally confused trying to anonymize this; the original was much harder to follow. Passing in 120 with places=1 should return 12.0, Passing in 2 with places=3 should return 0.002; who knows if the revised one still does that.

The "throw exception" returning a "-1" was in the original code.

The revised one doesn't really even come close Alex.... See my comment lol... Damnit....
<in jest>The TRUE wtf is that the revised code contains so many WTFs!!!! ;-P</in jest>

I just love the enterprisey naming conventions of the private method:

_getDecimalPlaceForField

wtf? who starts a method name with an underscore ? - not forgetting the lack of pascal casing

Alex Papadimoulis:

 I got totally confused trying to anonymize this; the original was much harder to follow. Passing in 120 with places=1 should return 12.0, Passing in 2 with places=3 should return 0.002; who knows if the revised one still does that.

The "throw exception" returning a "-1" was in the original code.

Ah.  Yes, the current version you have posted simply prepends zeros to the number... now that I'm trying to think like the brillant genious that came up with this function does, it is probably intended functionality for that to happen.  Append as many zeros as you need to in case the length of the number is less than the number of places (in which case you'll have 0. and any number of further leading zeros) and then chop off all the leading zeros except for the last before the decimal point (although the current function doesn't add that important dot either :D).

Anonymous:

It's standard practice to represent floats/decimals in integer form. Otherwise you get funky rounding things happening when you multiply or divide. It's just a fact of life. It gets worse in finance, as some things go to 32'nds and beyond and you are using a large value to begin with.

Soo... typically you'd do everything in integer/long form and display it in float/decimal form to minimize the damage by using String manipulation.

No, finance people do not like it when numbers get botched out of their control. :)

I think finance people get more upset when their values get
truncated due to the maximum size of an integer. After factoring the
loss of 2 decimal places isn't the allowable range -21,474,836.48 to
+21,474,836.47???

I know those numbers are too small for the financial company that I work for.

Rick:

Anonymous:

It's standard practice to represent floats/decimals in integer form. Otherwise you get funky rounding things happening when you multiply or divide. It's just a fact of life. It gets worse in finance, as some things go to 32'nds and beyond and you are using a large value to begin with.

Soo... typically you'd do everything in integer/long form and display it in float/decimal form to minimize the damage by using String manipulation.

No, finance people do not like it when numbers get botched out of their control. :)

I think finance people get more upset when their values get
truncated due to the maximum size of an integer. After factoring the
loss of 2 decimal places isn't the allowable range -21,474,836.48 to
+21,474,836.47???

I know those numbers are too small for the financial company that I work for.

Maybe they should use unsigned long long(s)?

unsigned long long (64 bits) 0 to 18,446,744,073,709,551,615

If anyone or any company has that much money.... address and bank vault pass code please? :)

  //throw exception if bad input
  if (field.Length == 0 | entity.Length == 0) return "-1";

hmm... a bitwise OR of 2 boolean values, interesting  (logical OR is || in C#)

Pingmaster:

I just wonder what the function would look like to add 0.0234 + 1.0417.....or even worse, division...

And even better, if it saves everything as an integer, you'd have to add zeros to the END of the number the user typed in to make sure that your numbers look the same. Say I want to add 42 + .42... Would that be stored as 4200 + 42?

It's kind of like a Thermos... It keeps hot things hot and cold things cold. How does it know?

captcha = enterprisey

Rick:

I think finance people get more upset when their values get
truncated due to the maximum size of an integer. After factoring the
loss of 2 decimal places isn't the allowable range -21,474,836.48 to
+21,474,836.47???

I know those numbers are too small for the financial company that I work for.

Use a data type that's large enough to fit your data. Duh.

Taevin:

Rick:

Anonymous:

It's standard practice to represent floats/decimals in integer form. Otherwise you get funky rounding things happening when you multiply or divide. It's just a fact of life. It gets worse in finance, as some things go to 32'nds and beyond and you are using a large value to begin with.

Soo... typically you'd do everything in integer/long form and display it in float/decimal form to minimize the damage by using String manipulation.

No, finance people do not like it when numbers get botched out of their control. :)

I think finance people get more upset when their values get
truncated due to the maximum size of an integer. After factoring the
loss of 2 decimal places isn't the allowable range -21,474,836.48 to
+21,474,836.47???

I know those numbers are too small for the financial company that I work for.

Maybe they should use unsigned long long(s)?

unsigned long long (64 bits) 0 to 18,446,744,073,709,551,615

If anyone or any company has that much money.... address and bank vault pass code please? :)

The old Vax CPUs had a built-in BCD datatype, that could be used for things like money without loss of precision.

The DB/language I regularly work with stores decimals internally as BCD numbers, with 50 significant digits and allows at least 10 decimal places--I forget the exact limit.

Pingmaster:

Soooo...instead of storing all numbers as decimals and just tuncating 0 to n characters after the decimal based on how the user wanted to display the number, they decide to complicate this by making everything integers, not to mention that one can no longer have large decimal places (i.e. .4294967297 can not exist) and they've only added to the complexity by stating that you have to take an ordinary integer value and add a decimal to it, instead of saying it's a number, just tell us how many places after the decimal you want to see...

I just wonder what the function would look like to add 0.0234 + 1.0417.....or even worse, division...

Once again the comments approach the level of WTF as the code example.  Storing numbers and decimal when dealing with money is unacceptable due to the imprecise nature of decimal numbers.  They are merely an approximation, not an exact value.

This obscures the fact that most modern languages (.NET included) have support for accurate decimal number representation in the form of some math library or class (I think in .NET it is BigDecimal?).  That is 'the real WTF'.

Anonymous:

I wonder what their system does for dates?

They don't, because software engineers can't get any!

mrprogguy:

Yes, doing math in cents for money (other than for things like corporate profits and government budgets) eliminates lots of round-off errors.  It's actually much better for calculation of sales tax and that sort of thing.  Don't sneer at money math in cents--it's what's for dinner!

Maybe someone could come up with a standard object to represent a number like this.  It'd take a big enterprise and a lot of coffee to write it, but I'll start the ball rolling and suggest a name for the object.  BigDecimal sounds good.

Alex Papadimoulis:

... designed to make programmers' lives easier ... 

Not good for job security ... or is it?

Alex Papadimoulis:

 by using only integer numbers.

We'll call it the 'abacus' tool.  The last few thousand years of mathematical development was a complete waste it seems.  Maybe the developers didn't make it past first grade to second grade when fractions are taught.

Alex Papadimoulis:

 "beautified" (as the CEF architects say) with a "dollar unit" and a decimal place. The same can be said about every other possible example that you or anyone else can ever think of, ever.

public string SetDecimalPlace(int number, string field, string entity)

{

  //throw exception if bad input

  if (field.Length == 0 | entity.Length == 0) return "-1";



  //easy return

  if (number == 0) return "0";



  //not so easy return 

  int places = this._getDecimalPlaceForField(field, entity);

PS. I'll miss you foosball girl

Anonymous:

I wonder what their system does for dates?

Probably uses the integer Unix time like everyone else...

It would be better just to add a new custom data-types for something such as currency. Then you mostly likely wouldn't ever need to access such a silly function directly...

The real WTF (tm) is that this is some of the best commented, clearest code that I have ever seen. Too bad it's just silly. That said, representing money as integers is not unusual.

Yes, I am the Simon that submitted this.  It looks like Alex got
confused when anonymizing the part at the end that actually does the
"math" (I did too, at first).  This is the actual algorithm:



Start with the string "1".

Append "0" to that string the appropriate number of times for the places from the metadata.

Convert that resulting string to a number, divide the parameter by it,
convert that floating-point number back to a string, then return that float-in-a-string.