Comment On Foreign Methodologies

bool confirm = true;

DoFirstPost(confirm);

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

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.

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

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

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.

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.

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?

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.

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.

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.

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!

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.

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

if not(Confirm) then

...

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>

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.

dreifus:

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

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.

Alex Papadimoulis:

.ActiveConnection = getConn()

Set .ActiveConnection = getConn()

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.

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!

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.

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:

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

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

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!

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.

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

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.

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

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

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:

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.

Anonymous:

Ever heard the term, "fandango on core?"

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

JohnO:

Anonymous:

Ever heard the term, "fandango on core?"

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

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:

CREATE PROCEDURE DeleteAccount
@AccountName varchar(50),
@Confirm int
AS

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