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

[Mike Schilling]

Not as clean as:

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

That doesn't let you break only on true (or only on false).

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

That's true only if you meaure cost solely by initial cash outlay. Even if
Eclipse or NetBreans will eventually be as productive as their current
debugger, there's the learning curve to consider.

And then there's the fact that conditional breakpoints can be annoyingly
slow. .If I want to break only on false, and false occurs once every 10,000
times through the code, it can take much longer for the debugger to get
control 10,000 times, evaluating my expression each time, and relinquishing
control back 9,999 times, than for the debugger to get control only once.

 

[Bent C Dalager]

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

I tend to avoid conditional breakpoints even when they are
supported. I like the simplicity of "if the line is red, the debugger
will break there" over "if the line is red, the debugger may stop
there sometimes and maybe I even got the conditional right".

Cheers
Bent D

 

[Chris Smith]

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.

Sort of. The difference is that in art, the appearance to the viewer is
all that matters, and it's better to produce nothing than to produce
something that people don't want to see. In software development, there
are all sorts of good reasons why something ugly happens, and it's often
better to have something ugly than something that cost too much, or
exceeded its schedule, or otherwise resulted in problems for the
employer.

If your contract/boss says you deliver by Friday afternoon, then you do
your best to deliver by Friday afternoon, no matter how terrible your
week was, or how bad the code is.

 

[Mike Schilling]

Sort of. The difference is that in art, the appearance to the viewer
is all that matters, and it's better to produce nothing than to
produce something that people don't want to see. In software
development, there are all sorts of good reasons why something ugly
happens, and it's often better to have something ugly than something
that cost too much, or exceeded its schedule, or otherwise resulted
in problems for the employer.

If your contract/boss says you deliver by Friday afternoon, then you
do your best to deliver by Friday afternoon, no matter how terrible
your week was, or how bad the code is.

It's code that's been made ugly in ways that can't possibly have any
mitigating advantages that seems so perverse. Then there's the fact that so
many "economies" are false ones, the most obvious being "There isn't time to
write unit tests". Perhaps a better analogy is that software development is
a learned skill like hitting a baseball, and too many people hold the bat
with their feet.

 

[bugbear]

Alexey wrote:
...
...

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

Heh. The voice of a real, experienced expert!!

BugBear

 

[bugbear]

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).

Or logging.

BugBear

 

[bugbear]

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).

It also helps logging.

BugBear

 

[Twisted]

It also helps logging.

BugBear

Do you see anything in that code that even is capable under the JLS of
having side effects, such as logging? I only see an if statement, a
return statement, a > operator expression (which in current Java
cannot be overloaded to have side effects), and boolean literals.

 

[Mike Schilling]

Do you see anything in that code that even is capable under the JLS of
having side effects, such as logging? I only see an if statement, a
return statement, a > operator expression (which in current Java
cannot be overloaded to have side effects), and boolean literals.

But it was loaded by a class.loader set up to recognize and instrument
if-then-else constructs with calls to a logger

 

[Twisted]

But it was loaded by a class.loader set up to recognize and instrument
if-then-else constructs with calls to a logger

A contrived, Rube-Goldbergian example. And if you're doing that, why
not have it log any occasion where a nonliteral boolean-valued
expression is evaluated? (Cue even more contrived, Rube-Goldbergian
example.)

 

[Mike Schilling]

A contrived, Rube-Goldbergian example. And if you're doing that, why
not have it log any occasion where a nonliteral boolean-valued
expression is evaluated?

Now you're just being silly.

 

[bugbear]

Do you see anything in that code that even is capable under the JLS of
having side effects, such as logging? I only see an if statement, a
return statement, a > operator expression (which in current Java
cannot be overloaded to have side effects), and boolean literals.

I didn't say such a coding structure DID logging, I said
it HELPS logging.

To expand, one could put a logging statement in the "true" path.
Adding such (conditional) logging to the more compact
versions is less convenient.

BugBear

 

[Piotr Kobzda]

But it was loaded by a class.loader set up to recognize and instrument
if-then-else constructs with calls to a logger

There is no significant difference in generated bytecode between the
code quoted above, and the "clever" alternative.


For example, compile the following simple class:

public class DetectIfThenElse {

public static boolean sillyCheck(int a, int b) {
if( a > b ) {
return true;
} else {
return false;
}
}

public static boolean cleverCheck(int a, int b) {
return a > b;
}
}

And then, run javap run with -c option on the bytecode generated by the
compiler.

The result printed out in my environment is:

Compiled from "DetectIfThenElse.java"
public class DetectIfThenElse extends java.lang.Object{
public DetectIfThenElse();
Code:
0: aload_0
1: invokespecial #8; //Method java/lang/Object."<init>")V
4: return

public static boolean sillyCheck(int, int);
Code:
0: iload_0
1: iload_1
2: if_icmple 7
5: iconst_1
6: ireturn
7: iconst_0
8: ireturn

public static boolean cleverCheck(int, int);
Code:
0: iload_0
1: iload_1
2: if_icmple 7
5: iconst_1
6: ireturn
7: iconst_0
8: ireturn

}


Having the above example, how would the instrumenting code distinguish,
which method uses the "if-then-else" construct?


piotr

 

[Ingo Menger]

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 ...

Nice rant! But, to be sure, applying regexp's is better than just
another 3+ page spaghetti method with lots of references to
String#charAt and the like.

Just because 90% of the java community is too ... hmmm, mentally
different? ... to understand regular expressions doesn't mean they are
a bad thing.

 

[Lew]

There is no significant difference in generated bytecode between the
code quoted above, and the "clever" alternative.


For example, compile the following simple class:

public class DetectIfThenElse {

public static boolean sillyCheck(int a, int b) {
if( a > b ) {
return true;
} else {
return false;
}
}

public static boolean cleverCheck(int a, int b) {
return a > b;
}
}

And then, run javap run with -c option on the bytecode generated by the
compiler.

The result printed out in my environment is:

Compiled from "DetectIfThenElse.java"
public class DetectIfThenElse extends java.lang.Object{
public DetectIfThenElse();
Code:
0: aload_0
1: invokespecial #8; //Method java/lang/Object."<init>")V
4: return

public static boolean sillyCheck(int, int);
Code:
0: iload_0
1: iload_1
2: if_icmple 7
5: iconst_1
6: ireturn
7: iconst_0
8: ireturn

public static boolean cleverCheck(int, int);
Code:
0: iload_0
1: iload_1
2: if_icmple 7
5: iconst_1
6: ireturn
7: iconst_0
8: ireturn

}


Having the above example, how would the instrumenting code distinguish,
which method uses the "if-then-else" construct?

Therefore, use the "clever" alternative because the "silly" one offers no
advantage, and the "clever" one is better at the source-code level. Since we
generally don't look at the bytecode, the cleaner source code must win.

 

[Wojtek]

Ingo Menger wrote :

Just because 90% of the java community is too ... hmmm, mentally
different? ... to understand regular expressions doesn't mean they are
a bad thing.

My, that is a broad brush you are using...

I have learned over 15 languages over my career. Both by self-learning
and formal courses. Not to mention mark-up syntax (*ML).

I do use regex, where it is appropriate.

The more languages and methodologies you know, the better you can
determine the right one for THIS job. And each language has some sort
of unique way of "doing things" which can be applied elsewhere.

 

[kaldrenon]

Now you're just being silly.

He's good at that. =P

Twisted - given that we're talking about examples of fairly ugly code
and looking at possible reasons for it, don't you think it's fair to
consider fairly ugly reasons, along with good ones? They may not
actually justify the ugliness, but it could make the ugliness more
understandable/forgivable.

 

[Tris Orendorff]

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

Oops! Missed that.

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.

Agreed! Also, if there's no version control or code review, there's a 99% chance of haivng no automated unit
tests either. I'd be very wary about touching that code without a good reason.

 

[Mike Schilling]

Oops! Missed that.


Agreed! Also, if there's no version control or code review, there's
a 99% chance of haivng no automated unit tests either. I'd be very
wary about touching that code without a good reason.

The ugliest part of a situation like this is not knowing whuch version of
the source is actually running. Java makes this a bit easier, since you can
decompile the running .classes and compare them to the possible source
files. (Unless they've been obfuscated, of course. In that case, say that
you're going out to get coffee and never come back.)