Most Recent Articles
Common Sense Not Found
We're Not Gonna Pay It..Anymore
FAP it Good
You Will Be Admin-similated
Getting the Green Light
Stalled for Time
Most Recent Articles
A Shining Perl
When You Really Want to be Sure it's an INT
Images...Why Settle for Just One?
The Java Purist
Today is Special
Jack and the Beanstalk
Most Recent Articles
You Can't Beat This High Score
Flying is Easier than Math
For Those Who Insist on Zapping Their Tongues
Savings That You Wouldn't Believe
Everything Californian Be Found On The Internet
The World's Worst Battery
Metro Card Jackpot!!
Good Help is Hard to Find
Best of the Sidebar
Bring Your Own Code
Mandatory Fun Day
Tales from the Interview
If only Java supported XML ...
« Return to Article
Article Comments (Viewing 31 comments)
Wish I was a consultant...
I love how the variable VERSION contains the string "version".
The only thing I can really say for this one is: <br> <br>private static WOW = "wow"; <br><snip> <br>System.WriteLn(WOW); <br> <br>I guess that I am just shocked and amazed thsat some could be oblivious to the world. It is like he lived in some kind of cave or something. Maybe he's a PHB in disguise?
Ermm... Yea ignore my syntax errors :/
Hey, at least the guy almost has versioning support built-in :)
private static final char Q_MARK = "?"; <br> <br>I've heard the language committies are considering changing the question mark to &#8225; <br>so we better start coding around that.
Well, that didn't work. <br>
I'm just waiting for one that goes: <br>private static final char a = 'a'; <br>private static final char b = 'b'; <br>private static final char c = 'c'; <br>private static final char d = 'd'; <br>private static final char e = 'e'; <br>... <br> <br>System.out.println(h+e+l+l+o+comman+space+w+o+r+l+d);
I like the way he couldnt spell "APOSTROPHE"
Thats just sad?
Hehe. Apostrope. Wazzah?
I'm in awe of this guy... <br> <br>I'm not sure if I should feel scared or just laugh my ass off or both.
To be fair, JAXP was only added as a standard part of the Java platform in J2SE version 1.4.0, just a few years ago. I'd like to know how long ago this code was written. I've seen consultants that have a library of old code that they reuse on different projects.
I thought a bracket was [ or ] .... what does he call those characters when he needs them?
It's mnot a pelling mistake, i suspect the code comes from a french company
J Q Random
Except "apostrophe" in French is "apostrophe".
This code is absolute rubbish, and I can see no way to defend it...
A theme I've seen come up pretty often (like, twice?) in this blog is defining symbolic constants for literal constants that will not change anytime before armageddon. I don't see how anyone would get the idea that this is a good thing, except if they're paid by code volume and unscruplous. Any ideas?
But - does Java actually support XML ?
Of course it does -- <a target="_new" href="http://java.sun.com/xml/">http://java.sun.com/xml/</a>
whats wrong with writting portable code?
What's not portable about buffer.append("<?xml version=\"1.0\"?>"); ?
As a rule of thumb, you shouldn't have numeric constants in code (other than loop indices). I think this is an example of extending that rule to string and character constants.
I hate to say it, but there is some (perhaps minor) justification in Java to this bizarre-looking approach. It's not a perfect coding example -- but how often do we see those? <br> <br> <br>(1) Java, King of String <br> <br>Java has a fairly unusual approach to building strings, at least for those who code in C or C++. When you concatenate, say, a "*" to the end of the Java string str1 (quoting from Sun): <br> <br>Java strings are immutable, they don't change after they're created. What actually happens is that: <br> <br>A StringBuffer is set up <br> <br>str1 is copied to it <br> <br>The "*" is appended to the buffer <br> <br>The result is converted to a string <br> <br>The str1 reference is made to point at that string. <br> <br>The old string that str1 previously referenced is then made available for garbage collection. <br> <br> <br> <br>(2) Premature Optimization, Bane of the Young <br> <br>It's widely known that impressive performance problems in stock Java code come from string concatenation. In fact, in my tattered old copy of Dov Bulka's "Java Performance and Scalability, Volume 1", the very first optimization (pages 1 - 6) is the use of a string buffer instead of a "destination string" when building a longer string from component strings. There's a very impressive "before and after" performance bar graph, with the "before" bar reaching the top of the printed page and "after" being a thin horizontal line beside it - representing 2200 milliseconds for a naive string-to-string concatenation versus 8 milliseconds for the same operation using a string buffer. <br> <br>As a result, receptive young Java programmers are themselves programmed to avoid string concatenation at any cost. Their little buttocks are peppered with spanks if they concatenate more than (say) two strings together. So the spectacle in this example is far from rare. <br> <br> <br> <br>(3) We're Recycling to Reduce Our Re-Use <br> <br>Many of us would defend the use of constants rather than literals in places where the literal values might change over time. The example code we're excoriating is a bit extreme, but represents a form of good style -- as indicated by this entry from the New Hacker's Dictionary: <br> <br>"magic number": In source code, some non-obvious constant whose value is significant to the operation of a program and that is inserted inconspicuously in-line (hardcoded), rather than expanded in by a symbol set by a commented #define. Magic numbers in this sense are bad style. <br> <br>And we have to recommend the writer's close attention to constant naming as recommended in "The Elements of Java Style": <br> <br>[Dictum] 31: Use uppercase letters for each word and separate each pair of words with an underscore when naming constants. <br> <br> <br>However, we must wonder whether there's a little featherbedding going on. Constants - even long lists of obvious constants like we see here - are valuable if they can be used and reused throughout a system. If tomorrow the W3C changes the format of XML such that LEFT_BRACKET becomes, say, "[", an application using the writer's string constants would be easily updated. However, that can't work when the constants are hidden and private, as they are defined here. We can just imagine, scattered through this application, little private islands of single-use string constants bulking up the line count. <br> <br> <br> <br>(4) Diagnosis <br> <br>It looks like this writer adheres to the letter of the Java law, but has some problems stringing those letters together to make good sense. <br> <br> <br> <br>"If you want truly to understand something, try to change it." Kurt Lewin <br>
Enterprise beans are a laugh.
Also, shouldn't he be using single quotes on his chars? <br>private static final char LEFT_BRACKET = '<'; <br>// not ("<") <br> <br>Wouldn't you get: <br>Type mismatch: cannot convert from String to char
Matt, you are indeed correct, String and char are incompatible types for the assignment operator, and to the best of my knowledge, Java does not have operator overloading. Maybe this programmer is using a preprocessor.
I used to work in a Cold Fusion shop (am I allowed to post here?) and observed this little gem of css workaround: <br> <br><cfscript> <br>font = structNew(); <br>font.black = "black"; <br>font.white = "white"; <br>font.etc = "what a blow hole"; <br></cfscript> <br> <br>.... <br> <br><font color="<cfoutput>#font.black#</cfoutput>">
Could this be a case of imitating the spec a bit too closely? It kind of resembles <a target="_new" href="http://w3.org/TR/2004/REC-xml-20040204/#sec-prolog-dtd">http://w3.org/TR/2004/REC-xml-20040204/#sec-prolog-dtd</a> in a perverse way.
Hillarious...but one of the respondent's comments about using symbolic constants does make sense many times, albeit not in this example. <br> <br>It can be very useful to localize constant values that might be used in more than one location in the code later one. Say things like initial buffer sizes, attribute names that need to be located, etc. That way if the value ever changes in the future, you just change it in one place. <br> <br>Mind you, if you expect the change to happen, then making it a property or some such from a config file may make more sense. Using the constant only makes sense if you don't expect the value to change. <br> <br>
Someone who knows
That's Accenture code, I guarantee it. They ship us crap like this all the time.
« Return to Article