Comment On It Depends on Your Definition of True

really puts the "enterprisey" in ERP.
also puts the "WTF" in ERP.

I guess enterprise systems are only truly "enterprise" if they are futureproofed against changes in "the truth".

Ha!! What's with the BASE_TRUE and BASE_FALSE?

Some sort of Boolean inheritance?

WTF?

If those values got flipped, then the file would have to be renamed to NonTruth.java

To be truly enterprisey you *have* to be able to redefine true.

DiamondDave:

Ha!! What's with the BASE_TRUE and BASE_FALSE?

Some sort of Boolean inheritance?

WTF?

If those values got flipped, then the file would have to be renamed to NonTruth.java

I prefer Lies.java.

"All your BASE_TRUE are belong to us."

Morpheus: "I didn't say it would be easy, Neo. I just said it would be the truth"....unless it's false

roflmao... I'm surprised they didn't use an integer type so that they could also define BASE_TRUE_AND_FALSE and BASE_NEITHER_TRUE_NOR_FALSE. Any BASE_TRUE enterprise system would have done it that way!

14 posts until file not found!

Alex.. did an enterprise rape your mother or something?  I mean, I know they are a good source of bad code, but they've been the subject of like the last fifteen daily wtfs...

THE_TRUTH is out there...



But seriously, why do people keep re-inventing the wheel???

Over-engineering at its purest.  I guess I should commend the author for at least giving the class a noun for a name.



How do we stop people from doing things like this?  How do we define the point at which one needs to stop abstracting?



My attempt at an answer would be, "If I can immediately understand
what's going on, no further abstraction is needed."  In this case,
I don't think



HasContent = Truth.ORG_HAS_CONTENT_FALSE



is clearer than



HasContent = false

DiamondDave:

Ha!! What's with the BASE_TRUE and BASE_FALSE?

Some sort of Boolean inheritance?

WTF?

If those values got flipped, then the file would have to be renamed to NonTruth.java

BASE_TRUE and BASE_FALSE or there so you CAN flip all the values. Whoa Dude! That's awesome!

Anonymous:

14 posts until file not found!

Well, now that you bring it up I don't see anyway to define values like
File Not Found or a Suffusion of Yellow.  This is obviously not
enterprise quality software.

A paragon of maintainable, easy-to-understand code -- at least, until someone errs on a copy/paste and you get:

  psf Boolean X_TRUE = BASE_TRUE;
  psf Boolean X_FALSE = BASE_TRUE;

That would be a fun little bug to track down. (Sadly, some ambitious IDE would probably give it away by displaying "Boolean.TRUE" when the debugging developer held the cursor over "X_FALSE.")

I have no idea what you are talking about, but can I sell it to someone?

VGR:

Over-engineering at its purest.  I guess I should commend the author for at least giving the class a noun for a name.



How do we stop people from doing things like this?  How do we define the point at which one needs to stop abstracting?



My attempt at an answer would be, "If I can immediately understand
what's going on, no further abstraction is needed."  In this case,
I don't think



HasContent = Truth.ORG_HAS_CONTENT_FALSE



is clearer than



HasContent = false

Well to be fair, since HasContent is a Boolean and not a boolean, it would have to be:

HasContent = Boolean.FALSE

Which is clearly significantly harder for the average enterprise programmer to comprehend.

PS- I know about autoboxing in Java 5.0, which I think would make "HasContent = false" work correctly...

Anonymous:

I have no idea what you are talking about, but can I sell it to someone?

After seeing the other stories on this site, you have to ask?

(With respect, the question marks you as a reasonably honest person -- many consultants featured in previous weeks would've pitched it without thinking twice. Or once.)

kipthegreat:

PS- I know about autoboxing in Java 5.0, which I think would make "HasContent = false" work correctly...

Or just:   ! HasContent

I actually worked with Mr. Buist in a former life.  I was the only person that he trusted to market his skills/abilities.  He reformed my vaporware bad habits and I am honest these days...and broke!  [*-)]

pinguis:

THE_TRUTH is out there...

But seriously, why do people keep re-inventing the wheel???

Because Those Other Guys simply don't understand the principles of Transportation Abstraction as it applies to Wheel Reuse, so their design is flawed. In fact, no one to date has designed a sufficiently portable wheel, so it's up to Us to design it The Right Way! We are the only ones who truly appreciate the finer details of Design For The Wheel World, and we must bring this understanding to the unwashed masses! Yes, they may mock us at first, but only because they haven't Seen the Truth.LIGHT_TRUE of The Plan.

Barkeep! More NyQuil! And keep it coming!

Perhaps they were trying to use it to define the spin of an electron?

Good grief.



At least in C there's a (lame) excuse for not understanding boolean values. This is Java, dammit!

The real WTF here is that the system is missing BASE_FILENOTFOUND completely.

Alex Papadimoulis:

evtProvider.VerifyTransaction = Truth.EVT_VERIFY_TRANSACTION_TRUE;

transOrg.HasContent = Truth.ORG_HAS_CONTENT_FALSE;

Aren't properties/members/objects in Java supposed to be named with initial lowercase letters, while classes and the like are named with initial uppercase letters? (By convention, not compiler rule.) So if this was an attempt at making code somehow more "readable", it completely missed the basic rules of Java readability.

I've submitted something similar to this (the irrational use of constants) and was pointing it out to someone how retarded it was to have these constants like that and they actually defended the practice.

Brendan Kidwell:

Alex Papadimoulis:

evtProvider.VerifyTransaction = Truth.EVT_VERIFY_TRANSACTION_TRUE;

transOrg.HasContent = Truth.ORG_HAS_CONTENT_FALSE;

Aren't properties/members/objects in Java supposed to be named with initial lowercase letters, while classes and the like are named with initial uppercase letters? (By convention, not compiler rule.) So if this was an attempt at making code somehow more "readable", it completely missed the basic rules of Java readability.

Public constants are all upper case, separated by underscores -- Integer.MIN_VALUE, etc.

You want the Truth.java?!  You can't handle the Truth.java!

I've submitted something similar to this (the irrational use of constants) and was pointing it out to someone how retarded it was to have these constants like that and they actually defended the practice.

Im curious to hear the argument they gave

JBL:

Brendan Kidwell:

Alex Papadimoulis:

evtProvider.VerifyTransaction = Truth.EVT_VERIFY_TRANSACTION_TRUE;

transOrg.HasContent = Truth.ORG_HAS_CONTENT_FALSE;

Aren't properties/members/objects in Java supposed to be named with initial lowercase letters, while classes and the like are named with initial uppercase letters? (By convention, not compiler rule.) So if this was an attempt at making code somehow more "readable", it completely missed the basic rules of Java readability.

Public constants are all upper case, separated by underscores -- Integer.MIN_VALUE, etc.

...not that I'm defending transOrg.HasContent.  (Microsoft contamination, I fear.)

JBL:

kipthegreat:

PS- I know about autoboxing in Java 5.0, which I think would make "HasContent = false" work correctly...

Or just:   ! HasContent

That can actually be a pretty bad idea.  There are cases where you would want to be setting the value to false.  You don't know what the current state is, and code like the following is pretty stupid:

[code]
if(HasContent){
  HasContent = false;
}

GoatCheez:

roflmao... I'm surprised they didn't use an integer type so that they could also define BASE_TRUE_AND_FALSE and BASE_NEITHER_TRUE_NOR_FALSE. Any BASE_TRUE enterprise system would have done it that way!

They could have gotten away with one more value using Booleans:

public static final Boolean BASE_NEITHER_TRUE_NOR_FALSE = null;

smbell:

JBL:

kipthegreat:

PS- I know about autoboxing in Java 5.0, which I think would make "HasContent = false" work correctly...

Or just:   ! HasContent

That can actually be a pretty bad idea.  There are cases where you would want to be setting the value to false.  You don't know what the current state is, and code like the following is pretty stupid:

[code]
if(HasContent){
  HasContent = false;
}

Concur. My bad, I've got my monitor set to a bad setting for dev purposes and the = looked wider than it is. Setting the value and testing it are two entirely different things (usually).

JBL:

BrendanKidwell:

Aren't properties/members/objects in Java supposed to be named
with initial lowercase letters, while classes and the like are named
with initial uppercase letters? (By convention, not compiler rule.) So
if this was an attempt at making code somehow more "readable", it
completely missed the basic rules of Java readability.

Public constants are all upper case, separated by underscores -- Integer.MIN_VALUE, etc.



...not that I'm defending transOrg.HasContent.  (Microsoft contamination, I fear.)

Remember also that Alex routinely changes the language in order to
protect the submitter (and, I suppose, to protect the guilty). 
The original WTF code may well be in VB or C#.

kipthegreat:

GoatCheez:

roflmao... I'm surprised they didn't use an integer type so that they could also define BASE_TRUE_AND_FALSE and BASE_NEITHER_TRUE_NOR_FALSE. Any BASE_TRUE enterprise system would have done it that way!

They could have gotten away with one more value using Booleans:

public static final Boolean BASE_NEITHER_TRUE_NOR_FALSE = null;

That's why I read this site: the creativity here is amazing, and a surprising fraction of the "creative" responses will probably be things I hunt down in (hopefully not my own) production code someday.

//audit transactions cannot be verified
if (isAuditType(transCode))
{
	evtProvider.VerifyTransaction = Truth.EVT_VERIFY_TRANSACTION_TRUE;
}

But, but, "audit transactions cannot be verified", and VerifyTransaction is True?

paid per LOC, i assume?

Alex Papadimoulis:

public static final Boolean BASE_TRUE = Boolean.FALSE;

public static final Boolean BASE_FALSE = Boolean.TRUE;

This little change would make this application compatible with Bizarro world.  I thought everyone knew that Bizarro world compliance is mandatory for all enterprise applications.

All your BASE_TRUE may or may not belong to us.

I always hate it when I can see some usefulness in a WTF. This is real remote tho.

Its kind of like an enumeration turned inside out... You could have lots of subtypes of true and false, with constructors that take multiple other subtypes of true and false and perform boolean logic on them. In this manner you can embed the semantics of the logic in the class hierarchy, and have the compiler checking your logic at compile time, or even at runtime in a runtime type safe language like java.

this.isJust(Boolean.DUMB_TRUE);

Anonymous:

All your BASE_TRUE may or may not belong to us.

ha!

The only usefulness that comes out of this is that it makes the the truth of WHAT the booleans are representing stand out as obvious.  Of course, since they're just integer constants and not actual enumeration constants, Java will happily let you set "Customer.Order_Shipped" to ACCOUNT_INVALID_TRUE.  Even if they were typesafe, it's still an awesomely stupid idea.

A BASE_TRUE and BASE_FALSE is just the pinnacle of WTF though.  At least they're final.

Well, if this scheme is strictly implemented without errors and
ommission, it makes it relatively easy to find all places in the code
where evtVerifyTransaction is set to true - just grep for
EVT_VERIFY_TRANSACTION_TRUE...



But then, so much pain for so little gain...

JBL:

A paragon of maintainable, easy-to-understand code -- at least, until someone errs on a copy/paste and you get:

  psf Boolean X_TRUE = BASE_TRUE;
  psf Boolean X_FALSE = BASE_TRUE;

That would be a fun little bug to track down. (Sadly, some ambitious IDE would probably give it away by displaying "Boolean.TRUE" when the debugging developer held the cursor over "X_FALSE.")

Who would look?  "Obviously", the value is false.  (Yes, I hope people would get suspicious, but sometimes, that just does not happen.)

Sincerely,

Gene Wirchenko

What a wonderful way to state that truth is beauty and beauty is truth!

public static final boolean TRUTH = public static final boolean BEAUTY = true;

pinguis:

But seriously, why do people keep re-inventing the wheel???

Perhaps you meant "reinventing a dead horse."

Yeah! I am a beginer in the enterprise world. My fisrt thought would be to grep evtVerifyTransaction.

Pilate said to him: “What is Truth.BASE_TRUE?”
And after saying this, he went out again to the management and said to them: “I find no fault in this code.”

- John 18:38, Enterprise Version

This is either fake or however wrote this code was bored and trying to look busy, or maybe they just smoke a lot of crack.

The real point of this, as always, is that the programmer wrote a lot of code. Ergo, he must be a good programmer.

Next!!