- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
And this is really bad news:
if ever we need to compare two enums, we should just do this:
Admin
You mean: "if ever we need to compare two enums, we shouldn't never just do this: "
Admin
// Shouldn't not never happen
Admin
Kinda makes you wonder how much of the code calling this requires comparison between integers and enums. Truly awful.
Admin
Admin
Of course, Java is TRWTF.
Admin
9 to 5 programmers, you gotta lov'em
Admin
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; }
Admin
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.
Admin
Admin
Admin
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.
Admin
Ya, people with lives outside of work SUCK!
Admin
Wawity misspelled "bwillant".
Admin
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!
Admin
Damn, life must suck if you're chief architect for a language -- nay, a lifestyle -- you hate...
Admin
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.
Admin
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
Admin
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
Admin
Admin
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.
Admin
Just for reference, how could be rewritten it in a single line:
Yoda is writing for DailyWTF now?
Admin
The real WTF is using the ordinal method itself, it provides very little value IMO
Admin
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.
Admin
Atmycompany,wearehavingsemepolicyregardingwhitespece.
Admin
inter()ed Strings are fast to compare with ==
Admin
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()
Admin
Admin
Whoever wrote this, clearly didn't understand OO. Rewritten code should be
Admin
Admin
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.
Admin
Of course, until someone calls the function with a null argument. Hello, NPE.
Admin
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()'.
Admin
Admin
Admin
Admin
I'm asking me what this method actually "checks"?
Admin
You mean:
Writing for DailyWTF Yoda now is.
Admin
Admin
Admin
Like this: http://dilbert.com/strips/comic/1992-09-08/
Admin
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".
Admin
The amount of misinformation in this thread is making me angry.
Admin
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.
Admin
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).
Admin
Admin
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?
Admin
Oh they introduced it?
In 1.4 which I'm using there is no StringBuffer
Admin
You need a manual for that?