Comment On The Most Thought Out Enumeration

I suppose N_NO_code and FALSE_code are both "N", so you could "cast" between YesNoIndDomain and TrueFalseIndDomain...

I'd still use plain booleans, though...

He should be happy that here is no IntegerClass. And when he finds one he should be happy that the size of an integer is limited...

public final static String INT_0 = "0";
public final static String INT_1 = "1";
public final static String INT_2 = "2";
public final static String INT_3 = "3";
....
....

A lot of Java enterprish developers will tell you that this is "best practise" - I also wonder what the BaseDomain class does.

Obviously, the real wtf is that the true/false class doesn't include a FileNotFound option.

Yipes, just yipes.

Do you think they're cognizant of just how bad they've got it?

I hope not. Poor bastards

Could someone explain why this could be considered a "best practice"? I really just can't fathom the mindset.

The real WTF is the YesNo and TrueFalse classes not supporting multiple languages!

Crabs:

Could someone explain why this could be considered a "best practice"? I really just can't fathom the mindset.

I agree. Why on earth would NIHing right in front of the solution the framework already gave you (boolean) be "best practices"?

"N_NO_code" and "N_NO_decode"?
Does the compiler have a stuttering problem?

At my previous job (developing the web part of an online gaming portal) the user could chose between "Male" and "Female" during registration. In the backend the application looked at the string and decided which the gender was. Worked fine. Until further languages were added. "Herr" doesn't quite look like "Male", must be female. Well, no one noticed for about a year. No one noticed that every new (not english) customer was female (those german girls seem to like gambling a lot!).

Fix was done in a minute, but who will fix the database? *sigh*

ParkinT:

"N_NO_code" and "N_NO_decode"?
Does the compiler have a stuttering problem?

N_code and N_decode were used in another method. And since no one has heard of local scope but every one knows that compilers are evil they went with the save method.

Grovesy:

Though, again we could add more extensibilty with an xml defenition document and another xml mapping document...

XML. Now that would make it very enterprisey!

Grovesy:

public final static Int INT_one = 1;

public final static Int INT_code = "1";

public final static String INT_one_decode_English = "One";

public final static String INT_one_decode_French = "un";

public final static String INT_two_decode_English = "Two";

public final static String INT_two_decode_French = "deux";

Though, again we could add more extensibilty with an xml defenition document and another xml mapping document...

Your solution is messy and after all this is not enterprise

I don't like all the statics and so on, what about making everything depending on a manager, and of course it would have a factory and the factory would fetch the right values depending

Then afterward, you can define accessors like Get_Int_ZERO_French_Decode() through a GeneralValueManager

But dont forget to make GeneralValueManager a singleton

Jimjim:

I don't like all the statics and so on, what about making everything depending on a manager, and of course it would have a factory and the factory would fetch the right values depending

depending localization, sorry

N_NO_code?
Sweet baby Jesus, this really hurts!

I guess they defined a domain that holds DB oriented values (think no booleans in Oracle...)
Sucks anyway.

Vollhorst:

... further languages were added. "Herr" doesn't quite look like "Male", must be female. ...

And this is why you should always validate your input properly. So, where can I get my medal for stating the blindingly obvious?

The worst thing is that once one gets to be an architect, such person is always right and even being the only one sane engineer in the company you have no hope in changing stuff. This is the THE ARCHITECTS made it right, so it is right! Much love to all architects!

Grovesy:

Vollhorst:

He should be happy that here is no IntegerClass. And when he finds one he should be happy that the size of an integer is limited...

public final static String INT_0 = "0";
public final static String INT_1 = "1";
public final static String INT_2 = "2";
public final static String INT_3 = "3";
....
....

Clearly not extensible enough

public final static Int INT_0 = 0;

public final static String INT_0_Code = "0";

public final static String INT_0_decode = "Zero";

Now the problem is, that just isn't extensible enough either.. consider

public final static Int INT_one = 1;

public final static Int INT_code = "1";

public final static String INT_one_decode_English = "One";

public final static String INT_one_decode_French = "un";

public final static String INT_two_decode_English = "Two";

public final static String INT_two_decode_French = "deux";

Though, again we could add more extensibilty with an xml defenition document and another xml mapping document...

I would laugh if I hadn't seen too many depressing pieces of software that did precisely the kind of thing you're describing here :/

I don't see what the big deal is. Everyone knows that truth is relative.

I bet they took the old C++ code, reverse engineered it with a CASE tool, moved/added/removed/renamed packages/classes/attributes/links, and finally generated it back into Java.

Why waste time when Friday beer is around the corner? :D

My eyes! My eyes! It burns!

This is the kind of code that scares the crap out of me. Just thinking about being a junior dev with "senior" developers who put out this shit and won't listen to a thing I say...

Is there any hope?

enum HowDumb
{
Dumb,
Dumber,
Dumbest
};

Vollhorst:

At my previous job (developing the web part of an online gaming portal) the user could chose between "Male" and "Female" during registration. In the backend the application looked at the string and decided which the gender was. Worked fine. Until further languages were added. "Herr" doesn't quite look like "Male", must be female. Well, no one noticed for about a year. No one noticed that every new (not english) customer was female (those german girls seem to like gambling a lot!).

Fix was done in a minute, but who will fix the database? *sigh*

Gender confusion on the online gambling site, not a big deal. Confusion on an online dating site...BFD!

Any chance to turn those "architects" into "expert consultants"?

The real WTF is that Chris expected, or even hoped for, improvement. If people write code like that in C++, they will write such code even in Python. It's a way of thinking (or maybe not thinking). They are enterprisey people. If they are particularly disinterested, they might even be simply translating the thing.

ParkinT:

"N_NO_code" and "N_NO_decode"?
Does the compiler have a stuttering problem?

I think the idea is that they encode and decode between "N" and "NO". Course that doesn't explain the lack of Y_YES_code

I am planning to create containers for ints, strings, etc... for PHP.

So doing $price->qHTML(), or $price->qMysql() or $price->qJS() ...is feasible.

I am tired of this:

$price_s = mysql_escape_real_string($price);
$sql = "SELECT id FROM products WHERE price='$price_s' and name like '%$substrings_s%'";

and this

$price_h = htmlentities($price);
echo "<div>Price: $price_h </div>";

a fully OOP version will be better, but I doubt PHP4 support enough syntax sugar to try it in a sane way...

CAPTCHA: SINO (yes/no and "fate" in spanish)

note: This captcha prove I am not a robot.

How many "Architects" are out there? Geez, it seems like everyone is a frickin architect these days.

WARNING: The Basemaster General Has Determined That Coffee Is Good For Your Health.

Jimjim:

Grovesy:

public final static Int INT_one = 1;

public final static Int INT_code = "1";

public final static String INT_one_decode_English = "One";

public final static String INT_one_decode_French = "un";

public final static String INT_two_decode_English = "Two";

public final static String INT_two_decode_French = "deux";

Though, again we could add more extensibilty with an xml defenition document and another xml mapping document...

Your solution is messy and after all this is not enterprise

I don't like all the statics and so on, what about making everything depending on a manager, and of course it would have a factory and the factory would fetch the right values depending

Then afterward, you can define accessors like Get_Int_ZERO_French_Decode() through a GeneralValueManager

But dont forget to make GeneralValueManager a singleton

You're almost there. Use a dispatch table pointing to dynamically generated (and memoized) anonymous methods and you won't have to worry about enumerating all |N| cases. Lazy evaluation ftw.

Now if you want to programmatically enumerate over all the natural numbers, you're committing a pretty big wtf.

I'm no expert in Java, but can YesNo.java contain a class named YesNoIndDomain, as opposed to YesNo? Maybe it was a nested class? Even then, horrors.

If there was a CAPTCHA, it would be: sanitarium.

NO no NO!:

The worst thing is that once one gets to be an architect, such person is always right and even being the only one sane engineer in the company you have no hope in changing stuff. This is the THE ARCHITECTS made it right, so it is right! Much love to all architects!

Speaking of Architects, I met a woman the other night who met an Architect through a dating service. She was incredulous and angry when she found out that her date didn't make bridges or buildings, but was a 'Network Architect'. I had to explain to her that her date wasn't a liar, just a snob.

Very funny.

Though, again we could add more extensibilty with an xml defenition document and another xml mapping document...

Oh, gosh. Think of the maintenance issues! Better make it a XML/SOAP service.

Vollhorst:

At my previous job (developing the web part of an online gaming portal) the user could chose between "Male" and "Female" during registration. In the backend the application looked at the string and decided which the gender was. Worked fine. Until further languages were added. "Herr" doesn't quite look like "Male", must be female. Well, no one noticed for about a year. No one noticed that every new (not english) customer was female (those german girls seem to like gambling a lot!).

Fix was done in a minute, but who will fix the database? *sigh*

Why in god's name would you examine a string to determine gender? Won't boolean do it? Or do they have more than two choices there?

enum gender
{
male,
female,
other
}

Addendum (2007-12-17 13:33):
I screwed that up. Should be:

enum gender
{
male,
female,
other,
fileNotFound
}

tray:

Any chance to turn those "architects" into "expert consultants"?

Yeh, that's easy. All you need to do to turn them into "expert consultants" is to remove their 1) backbones 2) balls 3) brains.

Bonus points for using a rusty blunt spoon to do so, of course...

DaveK:

tray:

Any chance to turn those "architects" into "expert consultants"?

Yeh, that's easy. All you need to do to turn them into "expert consultants" is to remove their 1) backbones 2) balls 3) brains.

Bonus points for using a rusty blunt spoon to do so, of course...

Double points for using number one to remove 2 and 3.
Triple points for realizing that 2 and 3 are one and the same.

Vollhorst:

No one noticed that every new (not english) customer was female (those german girls seem to like gambling a lot!).

Fix was done in a minute, but who will fix the database? *sigh*

UPDATE users SET GENDER="Male" WHERE TITLE="Herr"

That'll be $6000 please.

public final static Int INT_one = 1;

public final static Int INT_code = "1";

public final static String INT_one_decode_English = "One";

public final static String INT_one_decode_French = "un";

public final static String INT_two_decode_English = "Two";

public final static String INT_two_decode_French = "deux";

It needs more...

public final static String INT_one_decode_Japanese_LongObjects = "ichicho";

public final static String INT_one_decode_Japanese_Paragraphs  = "ichidanraku";

public final static String INT_one_decode_Japanese_BrushStrokes = "hitofude";

public final static String INT_one_decode_Japanese_Months = "ichigatsu";

public final static String INT_one_decode_Japanese_SmallAnimals = "ichihiki";

public final static String INT_one_decode_Japanese_FlowerPetals = "hitohira";

public final static String INT_one_decode_Japanese_LongCylindricalObjects = "ippon";



... and so on for 500 or so more cases.

Just because something has only 2 states (and will always have only 2 states) doesn't automatically make a 2-state enum a WTF. For example, what if you had a function like:

public void addPersion(String name, boolean gender) {...}

If you want to add a woman, do you pass in true or false? Having an enum here makes it immediately obvious which one to use without having to read the docs (if there are any!).

That being said, having an enum for something like Yes/No is pretty stupid.

FredSaw:

Vollhorst:

At my previous job (developing the web part of an online gaming portal) the user could chose between "Male" and "Female" during registration. In the backend the application looked at the string and decided which the gender was. Worked fine. Until further languages were added. "Herr" doesn't quite look like "Male", must be female. Well, no one noticed for about a year. No one noticed that every new (not english) customer was female (those german girls seem to like gambling a lot!).

Fix was done in a minute, but who will fix the database? *sigh*

Why in god's name would you examine a string to determine gender? Won't boolean do it? Or do they have more than two choices there?

enum gender
{
male,
female,
other
}

Addendum (2007-12-17 13:33):
I screwed that up. Should be:

enum gender
{
male,
female,
other,
fileNotFound
}

This reminds of a class I came across in some code I'm using:

import java.util.List;

import java.util.ArrayList;



public class OurBoolean {

    public static final String TRUE_VALUE = "TRUE";

    public static final String FALSE_VALUE = "FALSE";

    private static List<String> list = null;

    public static List<String> getList() {

        if(list == null) {

            list = new ArrayList<String>();

            list.add(TRUE_VALUE);

            list.add(FALSE_VALUE);

        }

        return list;

    }

}

Note the performance and memory optimization in the lazy initialization of the list.

By the way, this is used wherever most people would use a boolean, using string comparison ... e.g. if (result.isTrue().toString().equals(OurBoolean.TRUE_VALUE)) where result.isTrue returns a Boolean. The getList method isn't used anywhere, but I think it was "designed" to populate a drop down list on a web page.

What's actually going on here, is that the code's author was attempting to create a view/model separation, and failed miserably. I know from experience that if you haven't seen it done properly, it's fairly difficult to do it from scratch. It's not something taught in any school as far as I know, it's certainly way too advanced to be a subject in any forum, including forums.java.sun.com.

Sadly, by far the most common misguided result is that the coder ends up doing exactly the opposite of what he set out to do: instead of decoupling the view and the data, the two are coupled together in one class. Some people would argue that this makes it the "controller" of a model-view-controller design, but the controller should not have any knowledge of the view.

The proper thing to do is to define the data values in a plain data class; if the value space is limited to "yes" and "no," boolean or Boolean is obviously adequate. Only the view (UI) should be translating these data values into user-presentable strings, and often the easiest way is with a simple Map. For instance:

private Map<Boolean, String> humanPresentableAnswers;

I once met an architect from Racine
Who spec'd all his enumerations in green,
But much to his horror
it all printed out in the wrong color
and now all his strings are obscene.

The Outlaw Programmer:

Just because something has only 2 states (and will always have only 2 states) doesn't automatically make a 2-state enum a WTF.

I'm not saying having a two-state enum is stupid. I'm saying using a string to indicate gender is stupid. The enum is fine; good idea. Doesn't matter whether 0 (false) means female or male, as long as the code knows; the enum is for us humans with our readability problems.

But, using a string to test for gender? WTF!

Vollhorst:

At my previous job (developing the web part of an online gaming portal) the user could chose between "Male" and "Female" during registration. In the backend the application looked at the string and decided which the gender was. Worked fine. Until further languages were added. "Herr" doesn't quite look like "Male", must be female. Well, no one noticed for about a year. No one noticed that every new (not english) customer was female (those german girls seem to like gambling a lot!).

Fix was done in a minute, but who will fix the database? *sigh*

The backend application *should not* look at a string to decide which gender to apply. By the time "gender" reaches the backend, it has to be a discrete value, e.g. M/F or true/false.

Leave the language rules to the human interface. In a well designed web page, the "gender" is a pull down menu (or radio buttons) mapping the words to the discrete values. It's much easier to create separate English and German, and other HTML forms than change the backend application each time.

Next, a web portal will use vision AI and a webcam to assign gender. Take care of that gynecomastia.

Rick:

NO no NO!:

The worst thing is that once one gets to be an architect, such person is always right and even being the only one sane engineer in the company you have no hope in changing stuff. This is the THE ARCHITECTS made it right, so it is right! Much love to all architects!

Speaking of Architects, I met a woman the other night who met an Architect through a dating service. She was incredulous and angry when she found out that her date didn't make bridges or buildings, but was a 'Network Architect'. I had to explain to her that her date wasn't a liar, just a snob.

Very funny.

Amazing the lengths we go to to hide the fact that we are nerds.

We came up with Developer but that was over fairly quickly so we moved to Analyst but they caught on quickly to that as well.

We then came up with Consultant, this has lasted quite a while but they're catching on. Now we are architects. Soon we will be Directors and so on...

N_NO_decode!!! N_NO_decode! I definitely do not belive it! Show me and I still won't believe it. None of it!