• Ytram (cs)

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



    I never get tired of these.
  • boohiss (unregistered)

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

  • Masklinn (unregistered)
    .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

  • Ken Nipper (cs) in reply to Masklinn

    "Brillant!"[;)]

  • Synonymous Coward (unregistered)
    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?
  • Matt (unregistered)
    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!
  • frank rizzo (unregistered) in reply to boohiss

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

  • John Smallberries (cs)
    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 ....

    [image]


    Maybe Status == Success means it successfully failed...
  • emptyset (cs)

    <FONT face="Courier New" size=2>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.</FONT>

  • Gene Wirchenko (cs) in reply to boohiss
    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

  • emptyset (cs) in reply to Ytram
    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.

    <FONT face="Courier New" size=2>encapsulation: it's not just for ravers anymore.  [<:o)]</FONT>

  • Gene Wirchenko (cs)
    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 ....

    [image]


    Obviously, the answer is both!

    Sincerely,

    Gene Wirchenko

  • Scott B. (cs)
    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.
  • dubwai (cs) in reply to Scott B.
    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?

  • Richard Nixon (cs) in reply to Scott B.

    How is BeginDate = BeginDate going to set a breakpoint?

  • Ytram (cs) in reply to Richard Nixon
    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.
  • OmnipotentEntity (cs) in reply to Gene Wirchenko
    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 ....

    [image]


    Obviously, the answer is both!

    Sincerely,

    Gene Wirchenko



    Only if you put it in a box and don't look at it.
  • Tom (unregistered) in reply to dubwai

    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.

  • Mung Kee (cs) in reply to John Smallberries
    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 ....

    [image]


    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);
  • Scott B. (cs) in reply to dubwai
    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.
  • Benoit (unregistered) in reply to Ytram

    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.

  • Richard Nixon (cs) in reply to Ytram
    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.
  • Daveh (unregistered)

    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.

  • Benoit (unregistered) in reply to Benoit
    Anonymous:
    I do that from time to time and I even checked one in so I could be the author of this WTF.
  • Oliver Klozoff (unregistered) in reply to Scott B.

    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.

  • Oliver Klozoff (unregistered) in reply to Oliver Klozoff

    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?

  • David (unregistered) in reply to emptyset
    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.

    <FONT face="Courier New" size=2>encapsulation: it's not just for ravers anymore.  [<:o)]</FONT>

     

    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?

  • Baron (unregistered) in reply to John Smallberries
    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 ....

    [image]


    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.
  • JohnO (cs)
    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.

  • PhoenixPo (unregistered)
    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.
  • Suomynona (unregistered) in reply to Ytram
    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".

  • CornedBee (cs)

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

  • Jehos (cs) in reply to 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 ....

    [image]


    Maybe successful steps, failed transaction?  Un-normalized data?  Or maybe it's just software for "Opposite Bank Inc."
  • dubwai (cs) in reply to Oliver Klozoff
    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.

  • Mung Kee (cs) in reply to dubwai
    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.
  • dhromed (cs)

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

  • dubwai (cs) in reply to Mung Kee
    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.

  • Maurits (cs) in reply to dubwai
    dubwai:
    Debuggers encourage laziness.


    So do text editors.  Real programmers use cat.
  • dubwai (cs) in reply to Maurits

    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.

  • Mung Kee (cs) in reply to dubwai
    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 (cs) in reply to 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.
  • dubwai (cs) in reply to Mung Kee
    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?

  • Mung Kee (cs) in reply to dubwai

    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. <o:p></o:p>

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

  • brazzy (cs) in reply to dubwai
    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.
  • Billy Conn (unregistered) in reply to JohnO
    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.

  • Maurits (cs) in reply to Billy Conn
    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.
  • John Smallberries (cs) in reply to Mung Kee
    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 ....

    [image]


    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?
  • John Smallberries (cs) in reply to Maurits
    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.
  • WIldpeaks (cs) in reply to Ken Nipper

    --quote--

    "Brillant!"

    --/quote--

    That was my line lol [:D]

  • Kazrael (cs) in reply to Mung Kee
    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. <o:p></o:p>

    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. 


Leave a comment on “Vari-Post 2000”

Log In or post as a guest

Replying to comment #:

« Return to Article