Comment On Bad News Enum

In fact, most people don't understand Java Enums. But that is not a reason to not use them, it is rather a reason to read the fucking manual.

And this is really bad news:

if (statusStr==Status.CREATED.name()||statusStr.equals(Status.CREATED.name())){

if ever we need to compare two enums, we should just do this:

if (status==Status.CREATED) {

You mean: "if ever we need to compare two enums, we shouldn't never just do this: "

// Shouldn't not never happen

Kinda makes you wonder how much of the code calling this requires comparison between integers and enums. Truly awful.

//Shouldn't never happen

Stupid typo, or effective use of obfuscation?

Of course, Java is TRWTF.

9 to 5 programmers, you gotta lov'em

TRWTF is the function itself, not the code within it. The enum is defined without specific integer values so converting it to an integer is the WTF, since you're "guessing" what the values are.. and anything like this immediately breaks the code!

public enum Status {
FileNotFound,
CREATED
OPEN
CLOSE
TERMINATED;
}

Half the time hate is caused by not understanding. The other half by understanding all too well. I wonder if there's a sweet spot between the two where one can actually be content with working in this business...? Never been in it but I live in hope.

Quango:

TRWTF is the function itself, not the code within it. The enum is defined without specific integer values so converting it to an integer is the WTF, since you're "guessing" what the values are.. and anything like this immediately breaks the code!

public enum Status {
FileNotFound,
CREATED
OPEN
CLOSE
TERMINATED;
}

FileNotFound triggers the shouldn't never happen part, so it actually doesn't break the code. It just shouldn't never happen.

TheRider:

And this is really bad news:

if (statusStr==Status.CREATED.name()||statusStr.equals(Status.CREATED.name())){

if ever we need to compare two enums, we should just do this:

if (status==Status.CREATED) {

Note that enums are the only objects that ought to be compared via ==; good discussion here.

And, of course, it highlights the lack of operator overloading and stupid null semantics in Java that make a great language good.

Iscu:

9 to 5 programmers, you gotta lov'em

Ya, people with lives outside of work SUCK!

Wawity misspelled "bwillant".

Meep:

it highlights the lack of operator overloading and stupid null semantics in Java that make a great language good.

You like operator overloading, I call it 'bait for obscure coding'.

And I see nothing stupid about null semantics in Java, it is plain obvious if you keep in mind that it does not compare contents. Most of this distaste I'd dare say it is because of people that get too used to auto boxing/unboxing and compare two Integer objects with == .

Don't blame the language for your lack of knowledge of it, your lack of interest to understand it or your personal crush on some other language. If you find yourself saying 'C was way better, and I could do pointer arithmetic' or anything like it, then... f*ck, go find a C job and make everybody happy, you and those that listen to your whining!

Damn, life must suck if you're chief architect for a language -- nay, a lifestyle -- you hate...

The poop of DOOM:

Quango:

TRWTF is the function itself, not the code within it. The enum is defined without specific integer values so converting it to an integer is the WTF, since you're "guessing" what the values are.. and anything like this immediately breaks the code!

public enum Status {
FileNotFound,
CREATED
OPEN
CLOSE
TERMINATED;
}

FileNotFound triggers the shouldn't never happen part, so it actually doesn't break the code. It just shouldn't never happen.

Actually, it changes the ordinal values of every enum value after it. So, for example getStatus(CREATED) returns 0 without FileNotFound and 1 with it.

This is why I don't understand why anybody would want to use the ordinal value except maybe for implementing enum-related utility classes. Also, I don't really get how anyone who has coded C for 20 years without realizing that it has enums has made it into manager position.

steenbergh:

Damn, life must suck if you're chief architect for a language -- nay, a lifestyle -- you hate...

Life does suck, often and hard.
Case in point: Hey, Guido, I know you've been looking to move up, and there's good news and bad news. We need a chief architect for this new project. You'll get a (mumble)% raise and this, that, and the other thing, and life will be grand.
The bad news is, it's a Java project.

Suppose you're Guido. Let's say you have a few days to mull it over. What do you do?

a) say "no thanks, I'll stick with my old salary and responsibilities and the language I prefer"
b) say "yes, lovely, I'll take the raise and suck up the Java"
c) quit and look for another job
d) (a) or (b) and look for another job
e) say "Okay, great, I can do that" and give up on your self-indulgent 'hatred' of Java, which after all is just another programming language with some nice safety features making it easier to manage large projects and some aggravating quirks which, as the architect, you won't be dealing with, they're mostly a problem for the programmer
f) something else

People sorta said it, but here goes.

TRWTF is not how the function is implemented, it is that it's there at all. Not, as some tried to point out, because the enum might, one day, change, but because, in all likelihood, the function is there to support a broken "enum is integer" semantic that is irrelevant for Java to begin with.

So, unless this function is only called to serialize the class, it is broken. If this function is called to serialize the class, it is still broken, because then you'd want the enum's NAME to be used.

Shachar

OJ:

Also, I don't really get how anyone who has coded C for 20 years without realizing that it has enums has made it into manager position.

He'll probably do less damage when further removed from a keyboard.

OJ:

The poop of DOOM:

Quango:

TRWTF is the function itself, not the code within it. The enum is defined without specific integer values so converting it to an integer is the WTF, since you're "guessing" what the values are.. and anything like this immediately breaks the code!

public enum Status {
FileNotFound,
CREATED
OPEN
CLOSE
TERMINATED;
}

FileNotFound triggers the shouldn't never happen part, so it actually doesn't break the code. It just shouldn't never happen.

Actually, it changes the ordinal values of every enum value after it. So, for example getStatus(CREATED) returns 0 without FileNotFound and 1 with it.

This is why I don't understand why anybody would want to use the ordinal value except maybe for implementing enum-related utility classes. Also, I don't really get how anyone who has coded C for 20 years without realizing that it has enums has made it into manager position.

Oh, didn't know that (Not a Java person, and my language of choice doesn't have enums). Thanks for clarifying it!

How that guy made it into manager position's easy, though. They just promoted an incompetent fool out of the way so he wouldn't be able to do any harm anymore. Happens alot.

Just for reference, how could be rewritten it in a single line:

Yoda is writing for DailyWTF now?

The real WTF is using the ordinal method itself, it provides very little value IMO

Shachar:

People sorta said it, but here goes.

TRWTF is not how the function is implemented, it is that it's there at all. Not, as some tried to point out, because the enum might, one day, change, but because, in all likelihood, the function is there to support a broken "enum is integer" semantic that is irrelevant for Java to begin with.

Totally agree. In most cases, the true integer value of an enum should not be of any relevance (the major exception being storing to a database). If it is, make sure you have a good reason. Since this function gets the integer value of an enum, its existence points to a bigger possible problem with the program architecture. As a long time C++ programmer, I understand how easy it is to think of enums as integers and it is one of the things I always hated about the language.

Atmycompany,wearehavingsemepolicyregardingwhitespece.

Meep:

TheRider:

And this is really bad news:

if (statusStr==Status.CREATED.name()||statusStr.equals(Status.CREATED.name())){

if ever we need to compare two enums, we should just do this:

if (status==Status.CREATED) {

Note that enums are the only objects that ought to be compared via ==; good discussion here.

And, of course, it highlights the lack of operator overloading and stupid null semantics in Java that make a great language good.

inter()ed Strings are fast to compare with ==

Agreed, creating a new function to do nothing but use a Java framework method to convert to int is a total waste and is overkill! Calling code only needs the following if it's really necessary to get the integer value:

status.ordinal()

Nagesh:

Shachar:

People sorta said it, but here goes.

TRWTF is not how the function is implemented, it is that it's there at all. Not, as some tried to point out, because the enum might, one day, change, but because, in all likelihood, the function is there to support a broken "enum is integer" semantic that is irrelevant for Java to begin with.

Totally agree. In most cases, the true integer value of an enum should not be of any relevance (the major exception being storing to a database). If it is, make sure you have a good reason. Since this function gets the integer value of an enum, its existence points to a bigger possible problem with the program architecture. As a long time C++ programmer, I understand how easy it is to think of enums as integers and it is one of the things I always hated about the language.

Big faker, I am programming in Java only, Mordorchod!

Whoever wrote this, clearly didn't understand OO. Rewritten code should be

public enum Status {

    CREATED,

    OPEN,

    CLOSE,

    TERMINATED;

    

    Integer status;



    private Status() {

       status = ordinal();

    }



    public Integer checkStatus() {

        return status;

    }

}

Baboon:

The real WTF is using the ordinal method itself, it provides very little value IMO

My only guess at the reason would be so that you could use the enum in a switch statement before Java 7.

This is a perfect example of why so many applications written in Java (and other high-level programming languages) are terribly inefficient. Most developers who have learned and written only in Java (or C#, etc.) don't have a basic understanding of what actually happens when their code is run. All programmers, regardless of the language they use, need to be aware of what the processor is doing when it executes an 'if' statement, or a 'switch', or when a function is called, etc.

Just for reference, how could be rewritten it in a single line:

public Integer checkStatus(Status status){
return status.ordinal();
}

Of course, until someone calls the function with a null argument. Hello, NPE.

YF:

Meep:

it highlights the lack of operator overloading and stupid null semantics in Java that make a great language good.

You like operator overloading, I call it 'bait for obscure coding'.

And I see nothing stupid about null semantics in Java, it is plain obvious if you keep in mind that it does not compare contents. Most of this distaste I'd dare say it is because of people that get too used to auto boxing/unboxing and compare two Integer objects with == .

Don't blame the language for your lack of knowledge of it, your lack of interest to understand it or your personal crush on some other language. If you find yourself saying 'C was way better, and I could do pointer arithmetic' or anything like it, then... f*ck, go find a C job and make everybody happy, you and those that listen to your whining!

So you could actually tell from that sentence whether he liked Java or not? I couldn't, the sentence is just too confusing.

A programmer writing unclearly, however, is a red flag in my book.

Anyway, Java does have operator overloading with the '+' operator, where 'a + b' is short for 'new StringBuffer(a).append(b).toString()'.

Iceman:

Just for reference, how could be rewritten it in a single line:

public Integer checkStatus(Status status){
return status.ordinal();
}

Of course, until someone calls the function with a null argument. Hello, NPE.

But that shouldn't never happen.

Jim Fell:

This is a perfect example of why so many applications written in Java (and other high-level programming languages) are terribly inefficient. Most developers who have learned and written only in Java (or C#, etc.) don't have a basic understanding of what actually happens when their code is run. All programmers, regardless of the language they use, need to be aware of what the processor is doing when it executes an 'if' statement, or a 'switch', or when a function is called, etc.

So you're saying each programmer needs to mentally break down all control structures to LABEL and GOTO statements? Or did you mean to push it further, down to ASM level? Or yet further, to the electrical pulses running through the machine?

Severity One:

A programmer writing unclearly, however, is a red flag in my book.

Don't jump to conclusions with that flag. He might as well have spent the entire day writing some pretty damn good code, but kinda fried his brain and simply needs a break (which, of course, means that the code he writes between the frying and that break, would be absolute dogpoop and he'll spend twice the time on fixing it once his brain's cooled down)

I'm asking me what this method actually "checks"?

Zylon:

Just for reference, how could be rewritten it in a single line:

Yoda is writing for DailyWTF now?

You mean:

Writing for DailyWTF Yoda now is.

Sock Puppet 5:

Baboon:

The real WTF is using the ordinal method itself, it provides very little value IMO

My only guess at the reason would be so that you could use the enum in a switch statement before Java 7.

Except that you could already use enums in a switch statement since enums were introduced in java 1.5 - not that this guy would have known that with his hatred for java and enums.

public Integer checkStatus(Status status){

    Integer checkedStatus=null;



    switch (status)

    {

        case CREATED:

            checkedStatus=Status.CREATED.ordinal();

            break;

        case OPEN:

            checkedStatus=Status.OPEN.ordinal();

            break;

        case CLOSE:

            checkedStatus=Status.CLOSE.ordinal();

            break;

        case TERMINATED:

            checkedStatus=Status.TERMINATED.ordinal();

            break;

    }

    

    if(checkedStatus==null){

        return null; //Shouldn't never happen

    }else{

        return checkedStatus;

    }

}

The poop of DOOM:

Jim Fell:

This is a perfect example of why so many applications written in Java (and other high-level programming languages) are terribly inefficient. Most developers who have learned and written only in Java (or C#, etc.) don't have a basic understanding of what actually happens when their code is run. All programmers, regardless of the language they use, need to be aware of what the processor is doing when it executes an 'if' statement, or a 'switch', or when a function is called, etc.

So you're saying each programmer needs to mentally break down all control structures to LABEL and GOTO statements? Or did you mean to push it further, down to ASM level? Or yet further, to the electrical pulses running through the machine?

Knowledge of assembly is helpful, but not necessary. For example, when writing an 'if' statement a programmer should know that when the processor executes that statement it will do a compare of the two operands in the 'if' statement, and, based on which compare operator s/he used, a particular conditional-jump command will be used. This is the difference between knowing the final result of your code and knowing how it got there.

The poop of DOOM:

Jim Fell:

This is a perfect example of why so many applications written in Java (and other high-level programming languages) are terribly inefficient. Most developers who have learned and written only in Java (or C#, etc.) don't have a basic understanding of what actually happens when their code is run. All programmers, regardless of the language they use, need to be aware of what the processor is doing when it executes an 'if' statement, or a 'switch', or when a function is called, etc.

So you're saying each programmer needs to mentally break down all control structures to LABEL and GOTO statements? Or did you mean to push it further, down to ASM level? Or yet further, to the electrical pulses running through the machine?

Like this:
http://dilbert.com/strips/comic/1992-09-08/

The poop of DOOM:

So you're saying each programmer needs to mentally break down all control structures to LABEL and GOTO statements? Or did you mean to push it further, down to ASM level? Or yet further, to the electrical pulses running through the machine?

Of course not, but if you've learned the language well, you should be able to do this for anything you write. And if you've got a reasonable interest in programming, you'll have looked to see what's actually happening.
If you write a while loop in a Java program, you don't need to mentally expand it into the jvm code to understand what's happening - that's the point of a high level language - but you should be able to sketch it out on demand. It's not like it's a difficult thing:

jump to CONDITION
START
// loop body
CONDITION:
evaluate the loop condition
if true, jump to START

(sorry, I don't have the jvm instruction set in my head)

If you don't understand how this stuff works, you can still write good code, but it seems to me that good programmers seek this stuff out. It's part of what makes a good programmer: you're interested in neat stuff, like how the language works.

However, I don't agree with Jim Fell's assertion that "high level languages produce inefficient code". That's off base two ways. First, modern language design is pretty good at making the obvious choice the right one. (except for occasional facepalms like overloading + for inefficient string concatenation in Java, that is)
Second, and this is so obvious it hardly needs to be said, developer time is a part of "efficiency".

The amount of misinformation in this thread is making me angry.

The poop of DOOM:

Jim Fell:

This is a perfect example of why so many applications written in Java (and other high-level programming languages) are terribly inefficient. Most developers who have learned and written only in Java (or C#, etc.) don't have a basic understanding of what actually happens when their code is run. All programmers, regardless of the language they use, need to be aware of what the processor is doing when it executes an 'if' statement, or a 'switch', or when a function is called, etc.

So you're saying each programmer needs to mentally break down all control structures to LABEL and GOTO statements? Or did you mean to push it further, down to ASM level? Or yet further, to the electrical pulses running through the machine?

He's saying that you should have a loose estimate of what a given piece of code is going to turn into after it's compiled (or what the interpreter will do when it runs into it, if applicable).

Which is true.

The problem probably is that he doesn't know what Java bytecode looks like, or what the guts of the Python interpreter does when you do a function call, and so he assumes that people who use these languages every day don't know either. Which is idiotic; of course I know what it's doing under the hood. I've got a better grasp on how Python figures out what type an object is than I do of where the entry point of a C++ program is when you have global variables with non-trivial constructors, for example.

trtrwtf:

However, I don't agree with Jim Fell's assertion that "high level languages produce inefficient code". That's off base two ways. First, modern language design is pretty good at making the obvious choice the right one. (except for occasional facepalms like overloading + for inefficient string concatenation in Java, that is)
Second, and this is so obvious it hardly needs to be said, developer time is a part of "efficiency".

I wasn't saying that high level languages produce inefficient code. (Btw, I don't appreciate the misquote.) I was saying that high level languages more easily lend themselves to inefficient code for those programmers who don't understand what's actually happening when their code executes. That's not to say that that low-level languages can't be written inefficiently. In fact, they often are, but doing is usually less consequential (i.e. the inefficient construct is more efficient because a low-level language is used) or more disastrous (i.e. the code crashes or has other obvious run-time problems).

Jim Fell:

This is a perfect example of why so many applications written in Java (and other high-level programming languages) are terribly inefficient. Most developers who have learned and written only in Java (or C#, etc.) don't have a basic understanding of what actually happens when their code is run. All programmers, regardless of the language they use, need to be aware of what the processor is doing when it executes an 'if' statement, or a 'switch', or when a function is called, etc.

Actually, I love to not know. It almost always doesn't matter.

Jim Fell:

I wasn't saying that high level languages produce inefficient code. ... (i.e. the inefficient construct is more efficient because a low-level language is used)

(Btw, I don't appreciate the misquote.)

I'm sorry, but is it still a misquote? If an inefficient construct is more efficient simply by virtue of being written in a low-level language, then clearly it's less efficient simply by virtue of being written in a high-level language, so what are you complaining about?

Severity One:

Anyway, Java does have operator overloading with the '+' operator, where 'a + b' is short for 'new StringBuffer(a).append(b).toString()'.

Oh they introduced it?

In 1.4 which I'm using there is no StringBuffer

TheRider:

... a reason to read the fucking manual.

You need a manual for that?