|
Another magnificent specimen for my scrapbook of SQL horrors!!
Why create new rows for an event when you can create a whole new database?
|
|
|
|
|
Yikes!! The wrongness of that approach is almost awe-inspiring!
I'll add it to my scrapbook of SQL horrors.
|
|
|
|
|
I'm re-writing a legacy ASP application. There's an expensive call to an external webservice and a database to determine a calculated setting specific to the person logged in.
On the first page this calculation is done and the result is stored in a session variable.
On every subsequent page the session variable is ignore, the value is recalculated and then stored in the session variable again!
Some days I don't know if to laugh or cry.
|
|
|
|
|
Sometimes, you just want to go into a code review with a baseball bat and a spiked glove... 
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Cool, who ever wrote the code invented the write-only variable.. What shall we call it? "Wrariable"?
|
|
|
|
|
That kind of innovation must be why this guy is now a manager. My only solace in that is that he's no longer writing "code".
|
|
|
|
|
He's a manager now? Well, that explains a lot. I know quite some managers who also write (or wrote) code, and that was among the most horrible code I've ever seen. Think you still might find examples here in TWATW.
|
|
|
|
|
imagiro wrote: He's a manager now? Well, that explains a lot. I know quite some managers who also write (or wrote) code, and that was among the most horrible code I've ever seen. Think you still might find examples here in TWATW. |
Remember the old saying: "Those that can't do, manage!"
Update: LOL ... Isfeasachme, whoever that is, just posted a flaming reply to my message. Listen sport, I have been writing code probably since you were born, enough with the sanctimony. I've seen plenty of inept management in my days and very frequently they were coder's who couldn't hack it (no pun intended). As sharp as you are, you couldn't refrain from a flame which was copied to my inbox before you removed same. Chill out man! 
|
|
|
|
|
AnalogNerd wrote: My only solace in that is that he's no longer writing "code".
I had the same feelings about my former Bitch Supervisor From Helltm.
She barely understood coding concepts and management recognized that she knew enough to be dangerous and she was good at cracking the whip, so she was promoted to supervisor.
She was terribly insecure and terrified that I wanted her job (I didn't) and compensated by being a total control freak.
Those of us on her team have hours of stories we could tell about her incompetence.
I always said that if her manager had ever come to an abrupt halt, they'd need an emergency room proctologist to save her.
Instead she was eventually promoted to be the assistant to the new technology vice-president.
However after the company realized he was only a hot bag of buzzwords and equally incompetent, he was given the boot and she was out the door shortly after.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
There are millions of write only variables in code is use daily. I bet you have some in your own code right now.
For the database problem, someone intended to use the variable, but either forgot it was there or it was unknown to next programmer in line.
|
|
|
|
|
Think the write only variable is probably related to 'Planck's variable constant' - something that that we used to make physics experiments work during school labs!
|
|
|
|
|
Yeah, I work with a guy who puts whole serialized datasets in session variables.
And I can't even complain about it to the big boss, because they are kinda buddies.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
You never know, maybe the external system changed its mind after the first call to it... 
|
|
|
|
|
I am relatively new to this sort of thing and I currently use a different language but reading this thread makes me wonder if there is an issue with using session variables?
I am upgrading a program that currently uses POST method to transfer small portions of data between screens and I want to reduce the number of screens and to do this I need to transfer larger data sets. Using Session variables seem like a better idea since they are more persistent and are there through the whole session.
For the original poster it would seem that it would be easy to check the session variable to see if it exists and if it doesn't then calculate it otherwise use the session variable and continue? Seems like a simple bug to fix to me. But I only have experience with PHP with this at this point and am still learning. I have not even attempted to learn ASP.
|
|
|
|
|
What you say is what should have been done. The code should check the session variable, if it is null then go to the database and 3rd party API and calculate the value needed, and store it in the session variable for later use. In this way it's basically using the session variable for caching a value that is expensive to calculate and doesn't change often.
I posted this because what the person who actually wrote this did was kind of a face-palm moment. They write the value into the session variable and then never read from the session variable again. Every time this value was needed they calculated it, then wrote the calculated value into the session variable only to never retreive it and do anything with it.
|
|
|
|
|
Our finance folks were a bit annoyed by one of our web pages, where it occasionally rounded the final total to the nearest dime. While troubleshooting a former colleague's JavaScript code that added 2% to the amount entered by the user, I found this gem. His intention, at least, was obvious by the function name.
function CurrencyFormatted(amount) {
var i = parseFloat(amount);
if (isNaN(i)) { i = 0.00; }
var minus = '';
if (i < 0) { minus = '-'; }
i = Math.abs(i);
i = parseInt((i + .005) * 100);
i = i / 100;
s = new String(i);
if (s.indexOf('.') < 0) { s += '.00'; }
if (s.indexOf('.') == (s.length - 2)) { s += '0'; }
s = minus + s;
return s;
}
Isn't that brilliant? I mean, why use the simple, single-line solution isFixed(2) when you can do the same thing in 9 lines? 
If you think 'goto' is evil, try writing an Assembly program without JMP.
modified 17-Jun-13 16:15pm.
|
|
|
|
|
Perhaps he didn't know isFixed exists
.-.
|o,o|
,| _\=/_ .-""-.
||/_/_\_\ /[] _ _\
|_/|(_)|\\ _|_o_LII|_
\._. |\_/|"` |_| ==== |_|
|_|_| ||" || ||
|-|-| ||LI o ||
|_|_| ||'----'||
/_/ \_\ /__| |__\
|
|
|
|
|
Well, perhaps toFixed doesn't work the way he wanted?
Does it handle NaN?
Does it do rounding?
Does it round the absolute value of the value (which would always round up, right?)
Goofing around with the W3School's Try It[^] feature (snazzy) I think everything works correctly except the NaN handling.
Marc
|
|
|
|
|
Marc Clifton wrote: Does it handle NaN?
I don't think NaN will ever arise while currency formatting (going as per method name), without exceptions. He's not doing tan 90 anywhere is he?
|
|
|
|
|
You have a good point there. 
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
The second line handles NaN.
How extensive were your tests in W3Schools Try It? The code in question ran in production for a few years, and it runs flawlessly 99.99% of the time. But that 0.01% where it didn't is why I was looking into it.
My point is this: the amount of time needed to write and test that convoluted mass of spaghetti, and to understand and troubleshoot it later, is unacceptable when a simple solution is built-in and readily available.
If he didn't know about toFixed() is not much of an excuse; one should know your tools, or at least know how Google works.
You still need a solution that catches NaN, so it makes sense to wrap isFixed in a function:
function CurrencyFormatted(amount) {
var i = parseFloat(amount);
if (isNaN(i)) { i = 0.00; }
return i.toFixed(2);
}
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Presume they are paid by the line!
|
|
|
|
|
 My exact thoughts when I saw that. But no, much as I'd like it, we're salaried here.
This fellow doesn't work here any more, and as I've gone back to maintain his code I can see that we should kick ourselves in the arse for not holding code reviews when he was here. I could teach a full semester class on Programming Best Practices and use only his code for examples of what not to do.
Not that my code is perfect, but ...
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
GregorianCalendar date = new GregorianCalendar(1888, 0, 1, 0, 0, 0);
SimpleDateFormat sdf = new SimpleDateFormat("YYYY");
String convertedstring = sdf.format(date.getTime());
System.out.println(convertedstring);
output: 1887 (on my laptop anayway)
GregorianCalendar date = new GregorianCalendar(1888, 0, 1, 0, 0, 0);
SimpleDateFormat sdf = new SimpleDateFormat("yyyy");
String convertedstring = sdf.format(date.getTime());
System.out.println(convertedstring);
output: 1888
For those who didn't notice, in sample 1 I put "YYYY", in sample 2 "yyyy".
I couldn’t immediately find something in the docs or google explaining this…
|
|
|
|
|
"YYYY" means week years.
Quote: A week year is in sync with a WEEK_OF_YEAR cycle. All weeks between the first and last weeks (inclusive) have the same week year value. Therefore, the first and last days of a week year may have different calendar year values.
For example, January 1, 1998 is a Thursday. If getFirstDayOfWeek() is MONDAY and getMinimalDaysInFirstWeek() is 4 (ISO 8601 standard compatible setting), then week 1 of 1998 starts on December 29, 1997, and ends on January 4, 1998. The week year is 1998 for the last three days of calendar year 1997. If, however, getFirstDayOfWeek() is SUNDAY, then week 1 of 1998 starts on January 4, 1998, and ends on January 10, 1998; the first three days of 1998 then are part of week 53 of 1997 and their week year is 1997
SimpleDateFormat[^]
GregorianCalendar[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
