Double, double, toil and trouble ...

zelmak

I'm really tired of crap like this (Java):

Map prefs = new HashMap();
.
. // about 10 lines of intervening code
.
.
.
try { 

  prefs = loadPreferences();  // load preferences from db

  pref1 = Double.parseDouble(prefs.get("key1").toString());
  pref2 = Double.parseDouble(prefs.get("key2").toString());

} catch (Exception err) {

  System.err.println("could not load prefs: " + err);

}

Written in 2007 with Java 1.6 as the baseline.
Didn't use generics. But other parts of this subsystem did.

What type(s) are the keys in the Map? (duh! String! See? We used a hard-coded String as a key value!)
What type(s) are the values in the Map? (doesn't matter, we force it toString() before we parse it as Double. Note, the ACTUAL underlying value from the DB is a numeric type.)
Besides, it's more flexible this way; we don't need to know the type that loadPreferences() is returning!
What's the point of initializing an empty map in the declaration? No null checking is done anyhow. If the value at "key1" is null? NPE. If prefs somehow gets a null Map from the loadPreferences() call? NPE.
Double conversion from double to string to double.

zelmak

I'm spelunking around in this hodge-podge of what one would charitably be called "code" so that I can describe how it works to the stakeholders so they can write a spec for it. Or make sure that it does what they want it to do. Or something.

Parts of this are nicely coded. Others are sneaky (i.e., an if-statement using short-circuit logic so as to only build output when the first plugin generates output -- blew my mind when I found it -- then I wondered: did they do it on purpose with "malice aforethought" or did they just happen upon it?)

I'm trying to turn this bit into a service, but the calculation part of this has TONS of internal state during the calculation (not only "cached" -- that is, loaded once at startup -- database tables so they can be "queried" with for-loops in code, but also temporary storage for candidates for further processing.)

Untyped maps and vectors and lists (oh my!) making me whimper, chains of processing (processThis() which calls processThat() which calls continueProcessingThat() which returns its value which is then passed back up the chain), methods with multiple in/out arguments (I think you're trying to do too much in this one method, good sirs), PreparedStatements with string-concatenated arguments (they ALMOST got it), JDBC/SQL calls embedded in directly in actionPerformed() anonymous handlers ...

I think I may be going mad ... or at least getting mad.

esoterik

This can only be the result of a special kind of stupid born of extreme stubborness. The mentatily is that if your first approach doesn't work, keep trying until it does; the perpetrator of this code never stopped to think if there was another way or if their efforts were misguided. I think this kind of code is what results when a complete fraud actually gets hired, i.e. they lied when they put Java and software engineer on their resume!

esoterik

@zelmak said:

so that I can describe how it works to the stakeholders

you're so fucked