• Anonymous Coward (unregistered)

    bool confirm = true;

    DoFirstPost(confirm);

  • (cs)

    aww, i was only kidding when i called that method! this way i have a backup!

     

    its also nice how AccountNum is of type string....

  • (cs) in reply to pbounaix

    What about that cast to an integer of the confirm boolean?  I really tried to figure out what they were thinking when they coded this, but I just can't put myself in an 1d10ts mind.  Please someone help me understand why in the fu*k you would do this.

  • AnonymousCoder (unregistered)

    They forgot to utilize isTrue methods from previous WTFs.

    DeleteAccount("123", isTrue(true))

    It's more consice, 100% certainty that serius method can be executed.

  • TomA (unregistered)

    Hell, why not add an authetication scheme into your own program? Pseudo code:

    function Add( a, b, user, password ) { if user=='programmer' and password=='initech' return a + b else return 0 // unauthorized programmer, will get bad result } }

  • MrMe (unregistered) in reply to bugsRus

    They were probably confused because in SQL you cannot write "true" or "false" as you would in a lower level language

    i.e WHERE Confirmed = 1 instead of WHERE Confirmed = true

    hence, converting the boolean to an integer

  • (cs)

    This may their way of testing code coverage.  When the test is run, False is passed.  Still stupid though.

  • AnonymousCoder (unregistered) in reply to AnonymousCoder
    Anonymous:

    They forgot to utilize isTrue methods from previous WTFs.

    DeleteAccount("123", isTrue(true))

    It's more consice, 100% certainty that serius method can be executed.

    Or better yet:

    DeleteAccount("123", isSerious(true))

    Private Function isSerious(confirm as Boolean) as Boolean

       if confirm = true then

          isSerious = true

    else   

       isSerious = false

    end if

    End Function

     

  • (cs)

    Well, this approach is useless unless you carry it all the way up to the GUI level. You know, Javascript and such.

  • MrME (unregistered) in reply to Mung Kee

    They also pass the confirmed status to the stored proc... so that makes me assume the proc will also check for confirmation... this soulds like code bureaucracy

  • (cs) in reply to John Bigboote

    John Bigboote:
    Well, this approach is useless unless you carry it all the way up to the GUI level. You know, Javascript and such.

    No way, this is completely useful if you want to call a method but have it do nothing.

  • (cs)

    I'm not a VB expert, but short of quiting or while resume is under review elsewhere, can our poor friend extricate himself by

    Public
    Shadows Sub DeleteAccount(AccountNum As String)

      Dim cmd As New ADODB.Command
    With cmd
    .ActiveConnection = getConn()
    .CommandText = "DELETE_PLAYER_ACCOUNT"
    .Parameters.Append _
    .CreateParameter("ACCOUNT_NUM", adChar, adParamInput, 8, AccountNum)
    .Parameters.Append _
    .CreateParameter("CONFIRM", adInteger, adParamInput, 4, 1)
    .Execute
    End With

    End Sub
    or even

    Public Sub ReallyDeleteAccount(AccountNum As String)
      Dim cmd As New ADODB.Command
    With cmd
    .ActiveConnection = getConn()
    .CommandText = "DELETE_PLAYER_ACCOUNT"
    .Parameters.Append _
    .CreateParameter("ACCOUNT_NUM", adChar, adParamInput, 8, AccountNum)
    .Parameters.Append _
    .CreateParameter("CONFIRM", adInteger, adParamInput, 4, 1)
    .Execute
    End With

    End Sub


  • (cs)

    The key question to me is why would you ever pass false for the "confirm" parameter?  Especially when the methods appear to return right away so you aren't even calling everything that will get called with confirm set to true.

  • AnonymousCoder (unregistered) in reply to MrME

    Anonymous:
    They also pass the confirmed status to the stored proc... so that makes me assume the proc will also check for confirmation... this soulds like code bureaucracy

    But the wouldn't make any sense, (not that it does now anyway). If confirm is false, stored procedure would never get executed anyway, since

    If Confirm <> True Then Exit Sub

    So SP never gets false confirm, what's the point of passing it in then?

  • dfu (unregistered) in reply to dubwai
    dubwai:

    John Bigboote:
    Well, this approach is useless unless you carry it all the way up to the GUI level. You know, Javascript and such.

    No way, this is completely useful if you want to call a method but have it do nothing.



    ROFL
  • (cs) in reply to dfu

    I'm just waiting for people to post about how today's WTF is so bad because of its performance impact rather than the sheer idiocy behind thinking up such a concoction. Then there will be the "premature optimization is the root of all evil" acolytes putting in their 0010 cents with interest.

    This gives me an idea: could we change the label on the "troll" button to say "Troll / related to performance". It would be really nice to read the daily WTF without comments about performance.

  • (cs) in reply to JohnO

    JohnO:
    The key question to me is why would you ever pass false for the "confirm" parameter?  Especially when the methods appear to return right away so you aren't even calling everything that will get called with confirm set to true.

    Come on people, how many times have you called a method by accident and then thought, man I wish there were a way to make the code double check whether I really meant to call it?  This way, when you accidentally call the method, it'll know because you will set confirm to false when you don't really mean to call it.  I mean who would call a method by accident and set confirm to true?  That would be silly.

  • (cs)

    What would be even more shocking is of at some point this method had ever been called with a false parameter.

    What I'm sure we can all agree on though is that whoever mandated this 'security' feature needs to have the 2nd half of his brain removed to put in the jar with the 1st half.

  • AnonymousCoder (unregistered)

    I don't know what's the point of passing confirm around. But it could be one truely big WTF, if what they do is get the value of "confirm" checkbox, and pass it to the method. So, that if a user didn't check off confirm, that method does nothing. That would be brillant!

     

  • (cs)

    Why, I just realised -- it's not safe at all! That sub could actually run and delete the player's account completely in the background, just by setting Confirm to True!

    Here's the safe version:

    Public Sub DeleteAccount(AccountNum As String)

    If MsgBox("You have called a SERIOUS method. Are you sure you want to proceed?", MsgBoxStyle.OKCancel) = MsgBoxResult.OK Then
    If MsgBox("Positive?", MsgBoxStyle.OKCancel) = MsgBoxResult.OK Then

    Dim cmd As New ADODB.Command
    With cmd
    .ActiveConnection = getConn()
    .CommandText = "DELETE_PLAYER_ACCOUNT"
    .Parameters.Append _
    .CreateParameter("ACCOUNT_NUM", adChar, adParamInput, 8, AccountNum)
    .Parameters.Append _
    .CreateParameter("CONFIRM", adInteger, adParamInput, 4, 1)
    .Execute
    End With
          	    End If
    End If

    End Sub


  • (cs) in reply to OneFactor

    OneFactor:
    I'm just waiting for people to post about how today's WTF is so bad because of its performance impact rather than the sheer idiocy behind thinking up such a concoction. Then there will be the "premature optimization is the root of all evil" acolytes putting in their 0010 cents with interest.

    It's more like: some anonymous coward will post about how the WTF isn't a WTF because it's faster.  Then someone will post about how it's not faster and it is in fact slower.  Then you'll have the people saying that not using the WTF for performance reasons is a micro-optimization.

  • Someoneotherthanyou (unregistered) in reply to AnonymousCoder

    ...and here and I was more concerned that he didn't use:

    if not(Confirm) then

    ...

  • MrMe (unregistered) in reply to dubwai
    dubwai:

    OneFactor:
    I'm just waiting for people to post about how today's WTF is so bad because of its performance impact rather than the sheer idiocy behind thinking up such a concoction. Then there will be the "premature optimization is the root of all evil" acolytes putting in their 0010 cents with interest.

    It's more like: some anonymous coward will post about how the WTF isn't a WTF because it's faster.  Then someone will post about how it's not faster and it is in fact slower.  Then you'll have the people saying that not using the WTF for performance reasons is a micro-optimization.

     

    This method of structuring is proven to be faster because if confirm is false it does nothing... hence instance performance boost!

    </anonymous coward performance post>

  • (cs)

    Out of plain curiosity - why exactly the topic is called "Foreign Methodologies" ?

  • Anonymous (unregistered) in reply to MrMe
    Anonymous:
    dubwai:

    OneFactor:
    I'm just waiting for people to post about how today's WTF is so bad because of its performance impact rather than the sheer idiocy behind thinking up such a concoction. Then there will be the "premature optimization is the root of all evil" acolytes putting in their 0010 cents with interest.

    It's more like: some anonymous coward will post about how the WTF isn't a WTF because it's faster.  Then someone will post about how it's not faster and it is in fact slower.  Then you'll have the people saying that not using the WTF for performance reasons is a micro-optimization.

     

    This method of structuring is proven to be faster because if confirm is false it does nothing... hence instance performance boost!

    </ANONYMOUS post performance coward>

    But in fact it's slower since confirm value has to be evaluated.

    </ANOTHER post performance coward benefits no anonymous>

  • (cs) in reply to dreifus
    dreifus:
    Out of plain curiosity - why exactly the topic is called "Foreign Methodologies" ?



    'Cause this wold never be done in Alex's home country!
  • (cs) in reply to Anonymous
    Anonymous:
    Anonymous:
    dubwai:

    OneFactor:
    I'm just waiting for people to post about how today's WTF is so bad because of its performance impact rather than the sheer idiocy behind thinking up such a concoction. Then there will be the "premature optimization is the root of all evil" acolytes putting in their 0010 cents with interest.

    It's more like: some anonymous coward will post about how the WTF isn't a WTF because it's faster.  Then someone will post about how it's not faster and it is in fact slower.  Then you'll have the people saying that not using the WTF for performance reasons is a micro-optimization.

     

    This method of structuring is proven to be faster because if confirm is false it does nothing... hence instance performance boost!

    But in fact it's slower since confirm value has to be evaluated.



    Come on!  We all know if you use today's example, you are really doing optimization before it's really necessary, therefore it's a micro-optimization.
  • (cs)
    Alex Papadimoulis:
    .ActiveConnection = getConn()

    WTF!

    It shuld be:

    Set .ActiveConnection = getConn()

    Else you use a second connection object. Because the code assigne the string value from and to the default property of the connection object. The ConnectionString property.

  • Anonymous (unregistered) in reply to Generic
    Generic:
    Alex Papadimoulis:
    .ActiveConnection = getConn()
    WTF! It shuld be:
    Set .ActiveConnection = getConn()

    Else you use a second connection object. Because the code assigne the string value from and to the default property of the connection object. The ConnectionString property.

    I think it's VB.NET, "set" keyword is obsolete.

  • (cs)

    Anyone see Jungle to Jungle?

    "You didn't say confirm!"

  • Grant (unregistered)

    This is clearly the We-use-our-production-database-for-development-and-QA-so-we-can't-actually-run-some-sql-statements durring-development-and-QA design pattern.

  • (cs) in reply to Maurits

    What I don't get is all these people suggesting that you should get the current value of true from another function. That's something you should be looking up in a database. Gotta keep the hard-coded values out of the system, you know.

  • (cs)

    I guess I would be stating the obvious when I would say confirmation is a concept of a UI and not functionality.

    Should the user (or in the case of an account delete, the admin) be asked to confirm a delete operation, definetly!

    Should the code, hell no.  And obviously no confirmation is actually going on here, we're just requiring the coder to send an extra variable for no good reason.

    So technically their own methods aren't confirming if they should execute because they don't exit/pause and request a seperate confirmation.  Instead they bundle the request and confirmation together, which technically isn't a confirmation.

    I think the previous post said it best about sending a user & pass with the method, now you can really prevent people from executing methods unless they look up the user/pass in the code.  And imagine the coding hell it will create when you need to change the user/pass oneday!  My evil mind is in bliss as we speak!

  • Anonymous (unregistered) in reply to Stan Rogers

    Stan Rogers:
    What I don't get is all these people suggesting that you should get the current value of true from another function. That's something you should be looking up in a database. Gotta keep the hard-coded values out of the system, you know.

    You could do that, but you would still have to run that value through isTrue function. Plus, if confirm value in your database is stored as NULL, you need to be able to randomise true/false values, because there shouldn't be any bias.

  • (cs) in reply to maldrich
    maldrich:
    Why, I just realised -- it's not safe at all! That sub could actually run and delete the player's account completely in the background, just by setting Confirm to True!

    Here's the safe version:

    Actually, I think this would be safer
    Public Sub DeleteAccount(AccountNum As String) 

    If MsgBox("You have called a SERIOUS method. Are you sure you want to proceed?", MsgBoxStyle.OKCancel) = MsgBoxResult.OK Then
    If MsgBox("Positive?", MsgBoxStyle.OKCancel) = MsgBoxResult.OK Then

    Dim cmd As New ADODB.Command
    With cmd
    .ActiveConnection = getConn()
    .CommandText = "DELETE_PLAYER_ACCOUNT"
    .Parameters.Append _
    .CreateParameter("ACCOUNT_NUM", adChar, adParamInput, 8, AccountNum)
    .Parameters.Append _
    .CreateParameter("CONFIRM", adInteger, adParamInput, 4, 1)
    '.Execute
    End With
          	    End If
    End If

    End Sub


  • endothermal (unregistered)

    hmm, what a piece.  I bet the programmer of this shit proudly proclaims to management "It's not just secure, it's code safe, and not just code safe, it's fail safe!", then brimming with excitement, he stands up,  erases some stuff off the white board to help explain how brillant he is.  He adds " I've added many layers of protection, each function will ensure confirmation and even the stored procedure will check to make sure that yes the user is really sure!"  Management will in turn say "Wow, what we could do without you?"  

     

    but I digress

  • (cs) in reply to dubwai
    dubwai:

    John Bigboote:
    Well, this approach is useless unless you carry it all the way up to the GUI level. You know, Javascript and such.

    No way, this is completely useful if you want to call a method but have it do nothing.

     

    Hilarious, this forum needs a Humor button, and then query all the humor posts by # of votes for a "best of humor" page!

  • (cs) in reply to Grant
    Anonymous:
    This is clearly the We-use-our-production-database-for-development-and-QA-so-we-can't-actually-run-some-sql-statements durring-development-and-QA design pattern.
    When I looked at the code, I briefly thought the same thing. However, then something significant made me realize that that didn't make any sense; the code doesn't do ANYTHING if Confirm is false, including logging a message to indicate that "we were going to delete an account here, but didn't.". What sort of testing doesn't involve verifying that the results of your test match what you expected?

    In many of the WTFs that have been posted here, I have been able to come up with satisfactory (to myself) explanations as to why the person may have coded something a particular way (the most common of which is 'this person did not really know how to program'.) But this one stumps me. I cannot fathom any situation where this code would ever be useful for anything other than Confirm == True.

  • (cs) in reply to pbounaix
    pbounaix:

    aww, i was only kidding when i called that method! this way i have a backup!

     

    its also nice how AccountNum is of type string....



    DeleteAccount (AccountNum, "sike")
  • (cs) in reply to OneFactor
    OneFactor:

    This gives me an idea: could we change the label on the "troll" button to say "Troll / related to performance". It would be really nice to read the daily WTF without comments about performance.

    I would vote for you for President. Adding that functionality would reduce the 150 posts on every WTF down to 10-20 funny, un-uber-techie geek posts.

  • Anonymous (unregistered) in reply to Sean
    Sean:
    pbounaix:

    aww, i was only kidding when i called that method! this way i have a backup!

     

    its also nice how AccountNum is of type string....



    DeleteAccount (AccountNum, "sike")

    Hmm... what happens when DeleteAccount (AccountNum, "not sure") is called

  • (cs) in reply to Anonymous
    Anonymous:
    Sean:
    pbounaix:

    aww, i was only kidding when i called that method! this way i have a backup!

     

    its also nice how AccountNum is of type string....



    DeleteAccount (AccountNum, "sike")

    Hmm... what happens when DeleteAccount (AccountNum, "not sure") is called



    If Confirm <> True Then Exit Sub

  • Richard (unregistered)

    I can think of one semi-plausible reason for doing this. Ever heard the term, "fandango on core?" Though even then, whether this would actually prevent a catastrophe depends entirely on what's on the stack at the time... not to mention that accidentally jumping to the precise address of the DropAllTables_CrashTheProgram_AndSendANastyLetterToYourBoss (bool bConfirm) function is probably really really unlikely in practice, assuming that you don't abuse C++ function pointers while high on paint fumes.

  • (cs) in reply to Grant

    Anonymous:
    This is clearly the We-use-our-production-database-for-development-and-QA-so-we-can't-actually-run-some-sql-statements durring-development-and-QA design pattern.

    I thought of this myself.  But do you really wait until you are in production and a user is trying to do something with your system before you make calls to the database?  Do they really think the confirm flag is a substitute for testing the actual calls?

  • Anonymous (unregistered) in reply to Anonymous
    Anonymous:
    Anonymous:
    dubwai:

    OneFactor:
    I'm just waiting for people to post about how today's WTF is so bad because of its performance impact rather than the sheer idiocy behind thinking up such a concoction. Then there will be the "premature optimization is the root of all evil" acolytes putting in their 0010 cents with interest.

    It's more like: some anonymous coward will post about how the WTF isn't a WTF because it's faster.  Then someone will post about how it's not faster and it is in fact slower.  Then you'll have the people saying that not using the WTF for performance reasons is a micro-optimization.

     

    This method of structuring is proven to be faster because if confirm is false it does nothing... hence instance performance boost!

    But in fact it's slower since confirm value has to be evaluated.



    You can't determine whether the aggregate is faster or slower without profiling, because you don't know what proportion of calls to this function have confirm set to true, what proportion have it set to false, and what proportion have it set to SchrodingerSCat. This is only a WTF if the programmer didn't profile properly before and after adding this optimization.
  • (cs) in reply to Richard

    Anonymous:
    Ever heard the term, "fandango on core?"

    No and I've been programming for 23 years now.

  • Sam (unregistered)

    Actually, I think this code is really cute. . .

  • (cs) in reply to JohnO
    JohnO:

    Anonymous:
    Ever heard the term, "fandango on core?"

    No and I've been programming for 23 years now.

    programming) fandango on core - (Unix/C, from the Mexican dance) In <FONT color=#1d4994>C</FONT>, a wild pointer that runs out of bounds, causing a <FONT color=#1d4994>core dump</FONT>, or corrupts the <FONT color=#1d4994>malloc</FONT> <FONT color=#1d4994>arena</FONT> in such a way as to cause mysterious failures later on, is sometimes said to have "done a fandango on core". On low-end personal machines without an <FONT color=#1d4994>MMU</FONT>, this can corrupt the <FONT color=#1d4994>operating system</FONT> itself, causing massive lossage. Other frenetic dances such as the rhumba, cha-cha, or watusi, may be substituted.

  • (cs) in reply to Anonymous
    Anonymous:
    Sean:
    pbounaix:

    aww, i was only kidding when i called that method! this way i have a backup!

     

    its also nice how AccountNum is of type string....



    DeleteAccount (AccountNum, "sike")

    Hmm... what happens when DeleteAccount (AccountNum, "not sure") is called

    How about:
    DeleteAccount("%", true)

    Because you just *know* the stored procedure looks like this:

    <FONT face="Courier New">CREATE PROCEDURE DeleteAccount
    @AccountName varchar(50),
    @Confirm int
    AS

    IF @Confirm = 1
    BEGIN
     EXEC('DELETE FROM AccountTable WHERE AccountName LIKE ''%' + @AccountName + '%''')
    END</FONT>

  • CoderMan (unregistered)

    This might not be soooooo bad if it's called with something like:

    DeleteAccount(GetAccountNum("username"), GetConfirmation())


    You can wrap it up on one line...though I don't honestly know the benefit (or possible pitfalls) from doing it this way.

Leave a comment on “Foreign Methodologies”

Log In or post as a guest

Replying to comment #:

« Return to Article