rant: why is it acceptable to be this... lazy?

[Alexey]

So I've been working at a company that shall remain unnamed for the
time being for almost 3 months now. In that time, I've taken over for
a developer that was leaving, as well as started some brand new
projects from scratch. The brand new stuff has been fairly uneventful
and successful. I'm not trying to toot my own horn, I admit that the
new projects have been quite limited in scope and requirements.

I was warned that the legacy stuff can be rather tough to get a handle
on right away. Boy, was that an understatement. I can understand
when something is written with sparse documentation or somewhat
inconsistent API or patterns due to lack of time, changing
requirements, or who knows what else. When I got here, there was no
version control in use whatsoever. Deployments were made by carefully
moving specific binaries (class files) from environment to another
because, as it turned out later, certain class files contained
hardcoded environment-specific configuration (can they even be called
that?) parameters. I was willing to go along with just about anything
and quietly implement all the necessary clean-ups. But every now and
then I find something that just stops me in my tracks and I can't help
but wonder what sort of hard drugs the person had to be on in order to
write something like this. Here's today's sample:

boolean debug = Boolean.valueOf("true").booleanValue();

WTF WTF WTF WTF WTF!!!!!!!

 

[Andrew Thompson]

Alexey wrote:
...

boolean debug = Boolean.valueOf("true").booleanValue();

a) is the hourly rate of pay worth it?
b) if so.. get over it. Sh*t code is bread and butter for a contrator.
c) if not.. get a different job, and stop stressing. I hear
McDonald's is hiring. (they don't offer you the big bucks
just because you can sling burgers, so expect a little less
stress)

WTF WTF WTF WTF WTF!!!!!!!

Yeah.. See the 'McDonalds' option. Or grow up and get
over it ( and add a 'premium rate' to the idiot customers
that make you feel that way .

 

[rpm.fl72]

Alexey wrote:

..


a) is the hourly rate of pay worth it?
b) if so.. get over it. Sh*t code is bread and butter for a contrator.
c) if not.. get a different job, and stop stressing. I hear
McDonald's is hiring. (they don't offer you the big bucks
just because you can sling burgers, so expect a little less
stress)


Yeah.. See the 'McDonalds' option. Or grow up and get
over it ( and add a 'premium rate' to the idiot customers
that make you feel that way .

He said it was a rant, so let him rant. As for me, I agree with the
original post. Software development is an art, and too many people
don't even know how to hold the brush.

 

[Patricia Shanahan]

Alexey wrote:
....

boolean debug = Boolean.valueOf("true").booleanValue();

....

That sort of thing can arise due to a series of changes, combined with a
possible intent to change back.

Suppose the original intent was to have a String, obtained e.g. from a
file, that says whether to enable debug:

boolean debug = Boolean.valueOf(enableDebug).booleanValue();

With 1.5 or later, it should be:

boolean debug = Boolean.parseBoolean(enableDebug);

but this is legacy code.

However, it may have seemed too much work to actually pass in a String,
and the code needed debugging all the time anyway...

Changing it to:

boolean debug = Boolean.TRUE;

would lose the place holder for where to put in a String indicating
whether debug is enabled.

Incidentally, in code written this way, I would treat turning debug off
as a separate, hopefully small, project in its own right, to be done
after you have revision control and regression testing in place. There
is a risk that functionally necessary code is being executed only if
debug is true, and that the debug false paths are under-tested.

Patricia

 

[Roedy Green]

Here's today's sample:

boolean debug = Boolean.valueOf("true").booleanValue();

See http://mindprod.com/jgloss/unmain.html for what he may be up to.

 

[Christopher Benson-Manica]

Alexey wrote:

A fine argument for getting oneself a quality IDE that can make
un-suckifying such code a breeze, as well as reduce the likelihood of
seeing it at all.

b) if so.. get over it. Sh*t code is bread and butter for a contrator.

Mostly true, although if one is looking for resume bullet points there
are better ways to spend one's time.

c) if not.. get a different job, and stop stressing. I hear
McDonald's is hiring. (they don't offer you the big bucks
just because you can sling burgers, so expect a little less
stress)

Having worked fast food, I can honestly say that flipping burgers
while simultaneously trying to put burgers on buns with the right
toppings and clean up day shift's crap is plenty stressful.

 

[Philipp Taprogge]

Hi!

Thus spake (e-mail address removed) on 07/27/2007 06:30 PM:

He said it was a rant, so let him rant. As for me, I agree with the
original post. Software development is an art, and too many people
don't even know how to hold the brush.

Amen, brother...
I guess most of us have had our share of code like this. But somehow you never
stop wondering how someone illiterate enough to write such stuff was able to
get the job in the first place...

Regards,

Phil

 

[Christopher Benson-Manica]

Thus spake (e-mail address removed) on 07/27/2007 06:30 PM:

True enough, although the real problem is that, as with real art, the
people paying for it often wouldn't know it if it slapped them in the
face.

I guess most of us have had our share of code like this. But somehow you never
stop wondering how someone illiterate enough to write such stuff was able to
get the job in the first place...

See above.

 

[Crouchez]

So I've been working at a company that shall remain unnamed for the
time being for almost 3 months now. In that time, I've taken over for
a developer that was leaving, as well as started some brand new
projects from scratch. The brand new stuff has been fairly uneventful
and successful. I'm not trying to toot my own horn, I admit that the
new projects have been quite limited in scope and requirements.

I was warned that the legacy stuff can be rather tough to get a handle
on right away. Boy, was that an understatement. I can understand
when something is written with sparse documentation or somewhat
inconsistent API or patterns due to lack of time, changing
requirements, or who knows what else. When I got here, there was no
version control in use whatsoever. Deployments were made by carefully
moving specific binaries (class files) from environment to another
because, as it turned out later, certain class files contained
hardcoded environment-specific configuration (can they even be called
that?) parameters. I was willing to go along with just about anything
and quietly implement all the necessary clean-ups. But every now and
then I find something that just stops me in my tracks and I can't help
but wonder what sort of hard drugs the person had to be on in order to
write something like this. Here's today's sample:

boolean debug = Boolean.valueOf("true").booleanValue();

WTF WTF WTF WTF WTF!!!!!!!

that might be decompiled code

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I was warned that the legacy stuff can be rather tough to get a handle
on right away. Boy, was that an understatement. I can understand
when something is written with sparse documentation or somewhat
inconsistent API or patterns due to lack of time, changing
requirements, or who knows what else. When I got here, there was no
version control in use whatsoever. Deployments were made by carefully
moving specific binaries (class files) from environment to another
because, as it turned out later, certain class files contained
hardcoded environment-specific configuration (can they even be called
that?) parameters. I was willing to go along with just about anything
and quietly implement all the necessary clean-ups. But every now and
then I find something that just stops me in my tracks and I can't help
but wonder what sort of hard drugs the person had to be on in order to
write something like this. Here's today's sample:

boolean debug = Boolean.valueOf("true").booleanValue();

If you have a team of let us say 20 developers, then there
will be a blend of skills: some will be good, some will be
average and some will be not so good.

Even good programmers have bad days. They have hangovers
after drinking to 4AM or they had a horrible argument with
their wife or there are serious illness in the family etc.etc..

Sometimes some really bizarre code is produced. And it is
as natural as that the weather sometimes is bad.

When you have 20 years of experience, then nothing will
surprise you.

Arne

 

[~kurt]

I was warned that the legacy stuff can be rather tough to get a handle
on right away. Boy, was that an understatement. I can understand

Try working on a 20+ year old project with code that has roots going back
almost 50 years that has been rewritten from language to language and ported
from one platform to the next over the decades....

I know one guy who can write FORTRAN in *any* language.

- Kurt

 

[Twisted]

Try working on a 20+ year old project with code that has roots going back
almost 50 years that has been rewritten from language to language and ported
from one platform to the next over the decades....

I know one guy who can write FORTRAN in *any* language.

It's the ones that can write COBOL in any language that worry me. And
the rare one that can write perl in any language is downright scary.
I've also seen C++ code written in C (everything is bristling with
hooks like velcro, and there are several structs full of nothing but
function pointers), and of course there's the occasional wackjob that
codes Java, Ruby, or Eiffel that looks suspiciously like BASIC.
Sometimes with //100, //110, //120 at the end of every line.

It's always worst when the target language is C, because of the
preprocessor. No, it's second worst; worst is C++. Macros to "dim" an
array; #define BEGIN { and #define END } are almost staples; one nut
had a blank #define GOSUB and stuck GOSUB just before every freaking
function call. And of course no matter what ancient cruft they used to
code in there's one thing they still have in C++ that they just
loooove ... goto. Thank Christ Java frustrates their goto and macro
fetishes; the worst of them seem to avoid Java jobs like the plague,
and all I have to put up with there is spaghetti class dependencies (I
think this comes from certain pure-OO or pure-functional types), no
class dependencies at all (almost any procedural background),
convoluted method code (either, or FORTRAN), simple repetitive method
code that is verbose and eschews most higher forms of control
structure (FORTRAN or COBOL), tons of over-general types (especially
foobar (Object this, Object that, Object theother) throws Exception)
and anonymous inner classes and tangled flow paths with tons of method
calls and very little procedure at all (aha, a Smalltalker!), and
everyone's favorite since Java 5 came out, spaghetti type parameter
dependencies like Foo<X extends Y> extends Bar<Y, Z extends Quux, Foo,
P super Quux && extends Mumble<S extends SeriouslyFUBAR<String>>>. The
worst offenders here? Ex-C++ coders of course...

Lately we're even seeing in this newsgroup a surge of people using
Java 6 regular expression stuff to do just about everything.
Integer.parseInt()? Never heard of it. DateFormat? Couldn't give a
shit. The existing XML-parsing feeping creature lurking in the SAX
part of the standard library? Where the **** is the fun in that --
time to roll our own! Who needs any of these when we can probably make
turing complete code out of nothing but calls to Pattern and Matcher
and a whole lot of string literals that look like line noise!

I think the vanguard of the invasion of the folks who can write perl
in any language has arrived in Javaland ...

 

[SadRed]

Alexey wrote:

...> boolean debug = Boolean.valueOf("true").booleanValue();

...

That sort of thing can arise due to a series of changes, combined with a
possible intent to change back.

Suppose the original intent was to have a String, obtained e.g. from a
file, that says whether to enable debug:

boolean debug = Boolean.valueOf(enableDebug).booleanValue();

With 1.5 or later, it should be:

boolean debug = Boolean.parseBoolean(enableDebug);

but this is legacy code.

However, it may have seemed too much work to actually pass in a String,
and the code needed debugging all the time anyway...

Changing it to:

boolean debug = Boolean.TRUE;

would lose the place holder for where to put in a String indicating
whether debug is enabled.

Incidentally, in code written this way, I would treat turning debug off
as a separate, hopefully small, project in its own right, to be done
after you have revision control and regression testing in place. There
is a risk that functionally necessary code is being executed only if
debug is true, and that the debug false paths are under-tested.

Patricia

Ms Patricia, I respect a person like you who know the reality of the
trench. Code can become any-kind dirty through quick'n dirty
revisions.

 

[Karl Uppiano]

The worst code I ever had to work on was something that was ported from ASM
to C, to C++ and then to Java. Ugh. Obviously, management told the
developers not to rewrite, but to port, because it was "cheaper and faster".
Yeah, right, if you can't see past the end of your own nose.

Still, my vote for all-time brain-dead code goes like this:

if( a > b ) {
return true;
} else {
return false;
}

I see that all the time, instead of simply

return a > b;

 

[Michael Jung]

Still, my vote for all-time brain-dead code goes like this:

if( a > b ) {
return true;
} else {
return false;
}

I see that all the time, instead of simply

return a > b;

Most of these things come into existence after optimzation. Imagine that
someone had computations in one of the clauses that later got washed away. If
you then don't optimize it to the end, such clauses tend to remain. My
favorite was

a=1;
Assert(a==1);
if (a==1) {
...
}

This must also have gone through some "optimization" when lines in between got
washed away. At the time we were writing high-availability software so we had
a few laughs on this over-zealous code.

Michael

 

[Bent C Dalager]

Still, my vote for all-time brain-dead code goes like this:

if( a > b ) {
return true;
} else {
return false;
}

This can easily arise from a desire to set breakpoints in one of the
cases without having to mess around with conditional breakpoints (if
the debugger even supports that).

Cheers
Bent D

 

[Tris Orendorff]

boolean debug = Boolean.valueOf("true").booleanValue();

Code like this would be eliminated by a code review so it follows that code is being checked in without a code
review, even for small changes. I would start doing more code reviews to eliminate bugs before testing picks
it up in the next build or worse yet, a customer finds it in the next release.

 

[Lew]

This can easily arise from a desire to set breakpoints in one of the
cases without having to mess around with conditional breakpoints (if
the debugger even supports that).

Not as clean as:

boolean forBreakpoint = (a > b);
return forBreakpoint;

And if their debugger doesn't support conditional breakpoints, they can switch
to either Eclipse or NetBeans for the right price.

 

[Patricia Shanahan]

Code like this would be eliminated by a code review so it follows
that code is being checked in without a code review, even for small
changes. I would start doing more code reviews to eliminate bugs
before testing picks it up in the next build or worse yet, a customer
finds it in the next release.

The OP said "When I got here, there was no version control in use
whatsoever.".

In that situation I would use the best known code, unmodified, as the
base revision. Yes, that involves checking-in unreviewed code with nasty
stuff in it, but I would not want to even start the clean-up process
without version control.

Patricia

 

[Karl Uppiano]

This can easily arise from a desire to set breakpoints in one of the
cases without having to mess around with conditional breakpoints (if
the debugger even supports that).

Ok, I'll give them the benefit of the doubt, but based on my own experience,
I think a legitimate use of that idiom is relatively rare in practice.