|
Why would you assume that?
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
Can't you see the really GOOD think this solution is?
If the string is not a number you will also get the right message. It can't be simple, can it?
Hahahahaha
|
|
|
|
|
Well...that's the beauty of that Snippet.
Moim Hossain
R&D Project Manager
BlueCielo ECM Solutions BV
|
|
|
|
|
Finally, a usage of exceptions that I whole-heartedly support!
--Mike--
|
|
|
|
|
|
This is too unreal, you must have posted it in DotNetKick yourself to get a good line here.
|
|
|
|
|
People wouldn't really write code which is that bad in a production environment would they?
Between the idea
And the reality
Between the motion
And the act
Falls the Shadow
|
|
|
|
|
|
Oh they would. And the worst thing is it (almost) works, so unless someone reviews the code they'll never learn.
|
|
|
|
|
That is probably the most insane piece of coding I've seen in all my years of programming.
I might print it out and make a poster of it, to serve as a warning to our junior programmers
There are three kinds of people in the world - those who can count and those who can't...
|
|
|
|
|
Next interview question, if the candidate does not fall off the chair laughing don't hire him/her
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
I had to work with a state machine library that was somewhat similar. Worker threads would change states by throwing an exception. It was the most ridiculous stuff I have ever had to deal with but, of course, customers are always right and they wrote it.
|
|
|
|
|
Just WTF is that supposed to achieve?
You really gotta try harder to keep up with everyone that's not on the short bus with you.
- John Simmons / outlaw programmer.
|
|
|
|
|
Exception-driven development, my dear Brady!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah Himango
|
|
|
|
|
Exception-driving development, my dear Brady!
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah Himango
|
|
|
|
|
It is just a JIT compiler test. A "good" compiler would deduce the intent and eliminate all of the excess excpetion handling and place optimized code inline on the first pass. This eliminates the need for the programmer to think because the compiler has implemented the new DWIM (Do what I mean) facility.
Seriously in MVS Assembler it would be
XR R0,R0
L R1,VALUE
D R0,=A(2)
JZ EVEN
process odd number
J M_010
EVEN DS 0H
process even number
M_010 DS 0H
.
.
.
Sam
|
|
|
|
|
0. This code is in the region of 10 years old and I only had VB (probably 5 at that point) to work with.
1. What the code does is, I think sound.
In each class these variables are defined:
Private mlErrNumber As Long '** Standard Variable for Error Trapping **
Private msErrDescription As String '** Standard Variable for Error Trapping **
Private msErrSource As String '** Standard Variable for Error Trapping **
Then in any function or sub mlErrNumber = 0 clears the error state.
Not bad so far, slightly ott, but not bad.
So when an error occured, this was called to persist the error state to be used by any calling classes:
Private Sub SetError(ByVal alNumber As Long, _
ByVal asDescription As String, _
ByVal asSource As String, _
ByVal asLocation As String)
'================================================================================================
' Sub : SetError
' Arguments : alNumber Number of the error
' asDescription Description of the error
' asSource Source of the original error (Added 1.00.0001)
' asLocation Location of the error
'------------------------------------------------------------------------------------------------
' About : Sets the current error.
' If mlErrNumber is already set, it just appends to the location
'================================================================================================
On Local Error Resume Next
If mlErrNumber = 0 Then
mlErrNumber = alNumber
msErrDescription = asDescription
If asSource = APP_TITLE Or _
asSource = asLocation Or _
asSource = "" Then
msErrSource = ""
Else
'It's someone else's error, record where it came from
msErrSource = " " & asSource
End If
Call gObjCommon.SendToLog("E", mlErrNumber, 1, CLASS_NAME, asLocation, _
msErrDescription & IIf(msErrSource = "", "", " [Occured in" & msErrSource & "]"))
End If
If asLocation <> "" Then
msErrSource = "." & asLocation & msErrSource
End If
End Sub
The horror?
Appart from the language, why didn't I see this as being repeated? It's in ~50 seperate classes!
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
VB kind of forced all of us to a number of little implementation horrors, what with fake OOP and all.
I had my share of VB back in the day, and I'm happy it's over! When I have to maintain some of my old code from the 90's I still shiver at some horrors I see. It sure was partly my fault, but I'm convinced VB did its part.
We will probably enter yet another phylosophical/religious debate if we start arguing about goods and bads in old VB, but I think (hope) everybody will agree that even if it did have a sense in its day, it was just EVIL.
2+2=5 for very large amounts of 2
(always loved that one hehe!)
|
|
|
|
|
I have a little timer class that i use in optimizing code. It's a simple thing:
class CISTimer
{
public:
CISTimer() {m_p = NULL; m_t = GetTickCount();}
CISTimer(const char *p) {m_p = p; m_t = GetTickCount();}
~CISTimer()
{
DWORD d = GetTickCount() - m_t;
char buf[30];
_snprintf(buf, 29, "%4.2f (%d)\n", (double)(d) / 1000.0, d);
if (m_p) {OutputDebugString(m_p);}
OutputDebugString(buf);
}
protected:
const char *m_p;
DWORD m_t;
};
grabs the time when it's created and outputs the elapsed time when it's destructed.
so, i'm working on a new project and want to see how long certain chunks of code are taking. i put the function calls inside curly braces, and drop some counters in:
{
CISTimer("Func1");
Func1(...);
}
...
{
CISTimer("Func2");
Func2(...);
}
so the counters will print their elapsed time when they go out of scope, thus telling me how long the function took, so i'll know where to start optimization.
but they're all coming up with an elapsed time of 0. that can't be true.
so i switch from GetTickCount to QueryPerformanceCounter. but, all those come up with 15 ticks - far too fast. the calls should be in the .25 second range.
so, i step through the code. the breakpoint gets to the counter instantiation, i step over it, and the timer immediately destructs - before going out of scope. did i break C++'s deterministic destruction?
after much head-scratching, i realized that i forgot to give names to those CISTimer objects. they were anonymous, and so they disappeared as soon as they were created. duh.
this is an unpleasant feature of C++.
|
|
|
|
|
Why do you classify this as a coding horror?
I would say this is more like a subtle bug...
|
|
|
|
|
there is no "subtle bug" forum. but the intro text of this forum includes the category "embarrasing mistakes" (which, amusingly, is a spelling mistake).
|
|
|
|
|
Chris Losinger wrote: there is no "subtle bug" forum
There is such a forum. It was called 'subtle bugs' for a long time and was just recently renamed to 'Wicked Code'. See here: http://www.codeproject.com/Feature/WickedCode.aspx.
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Programmer - an organism that turns coffee into software.
|
|
|
|
|
again, the intro text to this forum reads:
We all come across code that simply boggles the mind. Lazy kludges, embarrasing mistakes, horrid workarounds and developers just not quite getting it.
if you feel that is in error, there is a Suggestions forum, too.
modified on Monday, June 1, 2009 7:11 AM
|
|
|
|
|