Comment On Vari-Post 2000

PRIVATE FUNCTION IsNothing(Obj)
  IF Obj Is Nothing THEN
    IsNothing = TRUE
  ELSE
    IsNothing = FALSE
  END IF
END FUNCTION

I never get tired of these.

Oh if only it was as easy as typing "// handle errors". How much easier would my life be?

.plabel

{

    white-space: nowrap;

}

a wrapping CSS class that doesn't wrap, and a non wrapping one that wraps !

Pure genius !

As a side note, i think that the last one had already been posted here

"Brillant!"[;)]

Alex Papadimoulis:

And finally we have Shane Courtrille,
who demonstrates that higly-paid consultants do actually provide value.
Note how much easier this is to use than typing "(myObject Is Nothing)"
...

PRIVATE FUNCTION IsNothing(Obj)
  IF Obj Is Nothing THEN
    IsNothing = TRUE

  ELSE

    IsNothing = FALSE
  END IF
END FUNCTION

This isn't necessarily superfluous. Can't you call a function by reference in VB?

Alex Papadimoulis:

Then there's Andy Korth who couldn't quite figure out what was so important with June 7th ...

If CDate(BeginDate) = CDate("6/7/1") Then

    BeginDate = BeginDate

End If

Obviously because it was my son's second birthday.  Duh!

Ah, the empty catch block...the C# version of VB's On Error Resume Next...

Alex Papadimoulis:

Christopher Sawyer is fortunate
to work with a pretty extensive transaction monitoring system. It does
all sorts of things from live charting to predictive analysis. Like
anything else, it does have a few weak points ... one being the
difficulty in determing whether a transaction was successful or not
....

Maybe Status == Success means it successfully failed...

i've actually seen a 53 line java switch statement along those lines back in college (i call it the 'corpulent' toInt method).  it was a junior-level class, however, so it was just kind of sad and pathetic.  i didn't feel like explaining basic concepts, so i just commented out the switch and replaced with the one-liner and a comment that was like: // <initals>: we fixed the glitch!  i really wish i could remember what his default case was.  i think it was just to return the value that A or Z was supposed to have.

Anonymous:

Oh if only it was as easy as typing "// handle errors". How much easier would my life be?

Possibly negatively so.



Your Manager: Mr. Anonymous, we have a program that can do what you do, so we no longer require your services.



Sincerely,



Gene Wirchenko

Ytram:

PRIVATE FUNCTION IsNothing(Obj)
  IF Obj Is Nothing THEN
    IsNothing = TRUE
  ELSE
    IsNothing = FALSE
  END IF
END FUNCTION

I never get tired of these.

encapsulation: it's not just for ravers anymore.  [<:o)]

Alex Papadimoulis:

Yes, that's right, I wrote "Vari-Post 2000."

Should you really have a hyphen when using bicapitalisation?

First up is a submission from Andrew Vos. I generally
do my best to conceal the author of code posted here, but our submitter
did take blame for this snippet. Note that he actually make it all the
way to "Z" before shaking his, saying "WTF!", and starting over ...

Private Function GetLetter(ByVal Index As Integer) As String 
  Select Case Index 
    Case 0 Return "a" 
    Case 1 Return "b" 
    'SNIP: ... all the way to "Z"

  End Select 
End Function 

If you are concerned about different character sets and wish a general solution, this would be the way to go.

Christopher Sawyer is fortunate to work with a pretty
extensive transaction monitoring system. It does all sorts of things
from live charting to predictive analysis. Like anything else, it does
have a few weak points ... one being the difficulty in determing
whether a transaction was successful or not ....

Obviously, the answer is both!

Sincerely,



Gene Wirchenko

Alex Papadimoulis:

Then there's Andy Korth who couldn't quite figure out what was so important with June 7th ...

If CDate(BeginDate) = CDate("6/7/1") Then

    BeginDate = BeginDate

End If

It's probably debugging code that didn't get removed.  I've done
this kind of thing before, you notice that something goes wrong in the
middle of a long loop when you hit a certain value and need a statement
on which to set a breakpoint.

Scott B.:

Alex Papadimoulis:

Then there's Andy Korth who couldn't quite figure out what was so important with June 7th ...

If CDate(BeginDate) = CDate("6/7/1") Then

    BeginDate = BeginDate

End If

It's probably debugging code that didn't get removed.  I've done this kind of thing before, you notice that something goes wrong in the middle of a long loop when you hit a certain value and need a statement on which to set a breakpoint.

Don't debuggers usually have conditional breakpoints?

How is BeginDate = BeginDate going to set a breakpoint?

Richard Nixon:

How is BeginDate = BeginDate going to set a breakpoint?

I think he's referring to placing a breakpoint inside of a conditional statement that coincides with when he wants to break.



A simplistic example would be



if(debugCondition)

{

    // you could put a breakpoint here so that it breaks only when the debug condition is met

    DoSomething(); 

}



It would be easier than placing a breakpoint on something that gets hit
everytime.  As far as conditional breakpoints, I've never seen
them in Visual Studio .NET, but I wouldn't be surprised if they
exist.  Other IDEs I would have no clue about.

Gene Wirchenko:

Christopher Sawyer is fortunate to work with a pretty
extensive transaction monitoring system. It does all sorts of things
from live charting to predictive analysis. Like anything else, it does
have a few weak points ... one being the difficulty in determing
whether a transaction was successful or not ....

Obviously, the answer is both!

Sincerely,



Gene Wirchenko

Only if you put it in a box and don't look at it.

Yes, but I usually slap

a=1

in there and tell it to break
on that line, then step through the rest of the code with an immediate
window open.

John Smallberries:

Alex Papadimoulis:

Christopher Sawyer is fortunate
to work with a pretty extensive transaction monitoring system. It does
all sorts of things from live charting to predictive analysis. Like
anything else, it does have a few weak points ... one being the
difficulty in determing whether a transaction was successful or not
....

Maybe Status == Success means it successfully failed...

No, no, no.  Of course the value of "Status" tells you where to go
to find out if it was successful.  It's the column name!

(java usage supplied)

String where = rs.getString("Status");

//where = "Success"

String successOrFail = rs.getString(where);

dubwai:

Don't debuggers usually have conditional breakpoints?

Sure, and usually they can't evaluate much more than built-in types, or
have interfaces that are harder to use than typing 3 lines of code.

I do that from time to time and I even checked one in so I could be the
other of this WTF.  And the reason is to avoid conditional
breakpoints.  Conditional breakpoints really slows down the
program so recompiling with the condition in the code can be faster.

Ytram:

Richard Nixon:

How is BeginDate = BeginDate going to set a breakpoint?

I think he's referring to placing a breakpoint inside of a conditional statement that coincides with when he wants to break.



A simplistic example would be



if(debugCondition)

{

    // you could put a breakpoint here so that it breaks only when the debug condition is met

    DoSomething(); 

}



It would be easier than placing a breakpoint on something that gets hit
everytime.  As far as conditional breakpoints, I've never seen
them in Visual Studio .NET, but I wouldn't be surprised if they
exist.  Other IDEs I would have no clue about.

Ah, I see. Thanks for clearing that up for me.

Visual Studio v6 has conditional breakpoints so I assume VS .NET has
them too. They are not particularily easy to us in v6 however, and its
generally faster just to add an if block and set the breakpoint inside
it.

Anonymous:

I do that from time to time and I even checked
one in so I could be the author of this WTF.

Furthermore, anyone who's ever used a conditional breakpoint knows that they slow down the program tremendously, because what happens behind the scenes is this:

1. Debugger sets breakpoint
   
2. Debugger runs program and waits for breakpoint
   
3. Debugger tests for condition
   
4. If condition is NOT present, go to step 2.
   

If the particular code in question happens to be in a loop where it'll be passed by a few hundred thousand times before getting to the value in question (usually the point where it breaks), using a conditional breakpoint can mean waiting several minutes instead of several seconds.

Gah. Who wrote this forum software? Don't they know that the point of a PREVIEW is to, well, take a look at what your post is going to look like when it's posted?

emptyset:

Ytram:

PRIVATE FUNCTION IsNothing(Obj)
  IF Obj Is Nothing THEN
    IsNothing = TRUE
  ELSE
    IsNothing = FALSE
  END IF
END FUNCTION

I never get tired of these.

encapsulation: it's not just for ravers anymore.  [<:o)]

 

Well of course!  What happens if MS decides to change the implementation of the Is Nothing command?  You wouldn't want to have to go back through all your code and change it, would you?

John Smallberries:

Alex Papadimoulis:

Christopher Sawyer is fortunate
to work with a pretty extensive transaction monitoring system. It does
all sorts of things from live charting to predictive analysis. Like
anything else, it does have a few weak points ... one being the
difficulty in determing whether a transaction was successful or not
....

Maybe Status == Success means it successfully failed...

The unix man page for the 'false' command simply says " false - do
nothing, unsuccessfully" and 'true' says "true - do nothing,
successfully"  which are both pretty hilarious.  Of course,
my real favorite is the message you get when you type "%blow" at a bash
prompt.

Alex Papadimoulis:

try

{

    System.Web.Mail.SmtpMail.Send(myMail);

} catch {

    // handle errors

}

This is the biggest, most common WTF ever.  I hate when people do this.

Alex Papadimoulis:

Then there's Andy Korth who couldn't quite figure out what was so important with June 7th ...

If CDate(BeginDate) = CDate("6/7/1") Then

    BeginDate = BeginDate

End If

Instead of setting a conditional break point, the programmer typed this statement and set the break point within the IF statement. That way, the debugger will stop at that point only when the value is equal to the one specified within the IF statement.
I used to do that when I was new, and still do that when I'm in a hurry or trying to prove a point to someone.

Ytram:

It would be easier than placing a breakpoint on something that gets hit
everytime.  As far as conditional breakpoints, I've never seen
them in Visual Studio .NET, but I wouldn't be surprised if they
exist.  Other IDEs I would have no clue about.

VS.NET 2003: Open Breakpoints window, select breakpoint, click on "Properties", click on "Condition", et voilà.



VS.NET 2005 Beta 2: Right-click on breakpoint marker, select "Condition".

.plabel
{
    PADDING-RIGHT: 5px;
    PADDING-LEFT: 5px;
    PADDING-BOTTOM: 0px;
    COLOR: black;
    PADDING-TOP: 3px;
    TEXT-ALIGN: left;
    white-space: nowrap;
}

.plabelnowrap
{
    PADDING-RIGHT: 5px;
    PADDING-LEFT: 5px;
    PADDING-BOTTOM: 0px;
    COLOR: black;
    PADDING-TOP: 3px;
    TEXT-ALIGN: left;
}


Which is why you NEVER EVER give CSS classes names that indicate their style.
Well, part of the reason, anyway.

Alex Papadimoulis:

Christopher Sawyer is fortunate to work with a pretty extensive transaction monitoring system. It does all sorts of things from live charting to predictive analysis. Like anything else, it does have a few weak points ... one being the difficulty in determing whether a transaction was successful or not ....

Maybe successful steps, failed transaction?  Un-normalized data?  Or maybe it's just software for "Opposite Bank Inc."

Anonymous:

Furthermore, anyone who's ever used a conditional breakpoint knows that they slow down the program tremendously, because what happens behind the scenes is this:

1. Debugger sets breakpoint
   
2. Debugger runs program and waits for breakpoint
   
3. Debugger tests for condition
   
4. If condition is NOT present, go to step 2.

If the particular code in question happens to be in a loop where it'll be passed by a few hundred thousand times before getting to the value in question (usually the point where it breaks), using a conditional breakpoint can mean waiting several minutes instead of several seconds.

I guess.  I don't really use debuggers much.  To me they are just a waste of time.  I've also had too many experiences where the debugger changes how the code executes.

dubwai:

I guess.  I don't really use debuggers
much.  To me they are just a waste of time.  I've also had
too many experiences where the debugger changes how the code executes.

I use a debugger (Eclipse) all the time and have never had this
happen.  Plus, hot swap of deployed code is a huge time saver.

.plabel
{
    PADDING-RIGHT: 5px;
    PADDING-LEFT: 5px;
    PADDING-BOTTOM: 0px;
    COLOR: black;
    PADDING-TOP: 3px;
    TEXT-ALIGN: left;
    white-space: nowrap;
}

.plabelnowrap
{
    PADDING-RIGHT: 5px;
    PADDING-LEFT: 5px;
    PADDING-BOTTOM: 0px;
    COLOR: black;
    PADDING-TOP: 3px;
    TEXT-ALIGN: left;
}

Aw geez.

Mung Kee:

dubwai:

I guess.  I don't really use debuggers much.  To me they are just a waste of time.  I've also had too many experiences where the debugger changes how the code executes.

I use a debugger (Eclipse) all the time and have never had this happen.  Plus, hot swap of deployed code is a huge time saver.

I had a co-worker arguing with me about the value of debuggers once.  Then he came to me and told me my code wasn't working.  After about 30 minutes for me and hours for him we determined the debugger was causing the problem.

Personally, I prefer good logging.  Debuggers are almost useless with multithreading bugs and don't help with production issues.  If the logging doesn't give enough info to solve the problem, then the logging needs to be improved anyway.  Debuggers encourage laziness.  The only time I use them is when I'm having a brain-fart and need a sanity check.

dubwai:

Debuggers encourage laziness.

So do text editors.  Real programmers use cat.

Maurits:

dubwai:

Debuggers encourage laziness.

So do text editors.  Real programmers use cat.

I never suggested 'real programmers' don't use debuggers.  I just personally find that I can solve more problems faster with good log/debug statements.  I used to use debuggers a lot but I don't even think about it anymore.  I any event, when the code is running in production, I don't have the option of opening up a debugger anyway.

dubwai:

Maurits:

dubwai:

Debuggers encourage laziness.

So do text editors.  Real programmers use cat.

I never suggested 'real programmers' don't use debuggers.  I
just personally find that I can solve more problems faster with good
log/debug statements.  I used to use debuggers a lot but I don't
even think about it anymore.  I any event, when the code is
running in production, I don't have the option of opening up a debugger
anyway.

Who says you can't have both?

Mung Kee:

dubwai:

Maurits:

dubwai:

Debuggers encourage laziness.

So do text editors.  Real programmers use cat.

I never suggested 'real programmers' don't use debuggers.  I
just personally find that I can solve more problems faster with good
log/debug statements.  I used to use debuggers a lot but I don't
even think about it anymore.  I any event, when the code is
running in production, I don't have the option of opening up a debugger
anyway.

Who says you can't have both?

I'm just not a fan of continually bouncing an app server for trivial code changes.

Mung Kee:

Mung Kee:

dubwai:

Maurits:

dubwai:

Debuggers encourage laziness.

So do text editors.  Real programmers use cat.

I never suggested 'real programmers' don't use debuggers.  I just personally find that I can solve more problems faster with good log/debug statements.  I used to use debuggers a lot but I don't even think about it anymore.  I any event, when the code is running in production, I don't have the option of opening up a debugger anyway.

Who says you can't have both?

I'm just not a fan of continually bouncing an app server for trivial code changes.

You just mentioned hot-swapping.  Generally, I would try to debug on my desktop if at all possible.  What I've found is that developers that use debuggers tend to put substantially less debug statements and comments in their code than those who don't.  It's purely anecdotal but I think there's a reasonable causality there.

One question, though, are you suggesting that you run a debugger on code in the app server?

What I've found is that developers that use
debuggers tend to put substantially less debug statements and comments
in their code than those who don't.

This is definitely true, but I'm not
one them.  I have a habit of writing substantial comments and
logging everything.  Many of my colleagues don't have such habits.

One question, though, are you suggesting that you run a debugger on code in the app server?

Not just suggesting...declaring.

dubwai:

Personally, I prefer good logging.  Debuggers
are almost useless with multithreading bugs and don't help with
production issues.  If the logging doesn't give enough info to
solve the problem, then the logging needs to be improved anyway. 
Debuggers encourage laziness.  The only time I use them is when
I'm having a brain-fart and need a sanity check.

I really can't fathom that point of view. Admittedly, if post-mortem
analysis of bugs (in a production environment, or with
hard-to-reproduce bugs) is required, logging is the only way. But in
any other case, a debugger IMO speeds up debugging by a factor of at
least 5 even if you have good logging. As for debuggers changing how
the code is executed - logging statements inserted while hunting a bug
do the same thing.

JohnO:

Alex Papadimoulis:

try

{

    System.Web.Mail.SmtpMail.Send(myMail);

} catch {
    // handle errors

}

This is the biggest, most common WTF ever.  I hate when people do this.

Question, then.  If I want to attempt to call a function, but
don't care if it throws an exception and fails, how SHOULD I do
it?  Admittedly, I'd prefer to see some logging done inside the
catch statement, but I have code that looks almost exactly like that:
it attempts to send out an email to our server team if certain errors
are thrown.  However, I don't really care if the email isn't sent,
and I don't want to propogate the email exception upwards, as I'm
already attempting to recover from another, more important type of
error, and I don't have much to do if the "I'm broke" email doesn't get
sent, other than what I was going to do in the first place.

Anonymous:

Question, then.  If I want to attempt to call a function, but
don't care if it throws an exception and fails, how SHOULD I do
it?

Easy... don't call the function at all.

Mung Kee:

John Smallberries:

Alex Papadimoulis:

Christopher Sawyer is fortunate
to work with a pretty extensive transaction monitoring system. It does
all sorts of things from live charting to predictive analysis. Like
anything else, it does have a few weak points ... one being the
difficulty in determing whether a transaction was successful or not
....

Maybe Status == Success means it successfully failed...

No, no, no.  Of course the value of "Status" tells you where to go
to find out if it was successful.  It's the column name!

(java usage supplied)

String where = rs.getString("Status");

//where = "Success"

String successOrFail = rs.getString(where);

Ahh...indirection. Very clever.

Too bad they couldn't abstract it so that a failure was reported as successful.



I have a confession to make: I work at the same company as the poster of this WTF.

In fact, it was my predecessor who coded this gem. I guess I have to fix it....but how?

Maurits:

Anonymous:

Question, then.  If I want to attempt to call a function, but
don't care if it throws an exception and fails, how SHOULD I do
it?

Easy... don't call the function at all.

LOL! Great response, Maurits.



The real answer is, of course, simply call it. Don't wrap it in try/catch at all.

When an exception is thrown, the stack is unwound until an appropriate catch block is found.

If one is never found, the app just crashes. So maybe "you" don't care
if it fails, but hopefully somewhere up the line, somebody does.

--quote--

"Brillant!"

--/quote--

That was my line lol [:D]

Mung Kee:

What I've found is that developers that use
debuggers tend to put substantially less debug statements and comments
in their code than those who don't.

This is definitely true, but I'm not
one them.  I have a habit of writing substantial comments and
logging everything.  Many of my colleagues don't have such habits.

One question, though, are you suggesting that you run a debugger on code in the app server?

Not just suggesting...declaring.

You should note that running in a debug mode on a production server is
a HUGE waste of resources.  All sorts of code checks and debug
methods are ADDED by whatever IDE you are using.  If you are
running debug modes on production clients you should be shot. 
Debuggers are for development purposes, not production bug
tracking.  Logging exists to help identify problems on production
apps. 



Now, logging is not meant to log every activity on
production; that is why plug-ins such as Apache's log4j have different
levels of logging.  You have debug logging for development issues,
then info/warn/error logging for production and live state
tracking.  Logging in production is supposed to give a general
idea of the flow/state of production app and give as much clue as
possible as where problems are arising.  I am not talking about
logging things that are used for business purposes of course, such as
credit card transaction logging.