Comment On Divide and Validate

Well sounds very odd, yet it can return "what is your percentage of completeness"....
I wouldnt do it by myself (mixing bools and ints and magin all the way) but I think I understand why this code came to mind of programmer .-)

That's pretty weird indeed.

return "frist".Length / 0.0;

Take into consideration poor Piotr Kaminski, who got stuck with unmaintainable code, in the Twilight Zone...

Well if you want to tell the user how close their form is to completion, that'll work quite nicely. If all the fields are entered correctly it'll return 100; if only one is, you'll get 12 and so on. You can use the value to show a "Your application is now xx% complete" message.

Not great, but not necessarily a WTF.

It's actually quite clever. Of course it demands from the developer who reads that, some arithmetic and boolean skills.
I know, it's asking a lot from people who actually are supposed to know how to crunch numbers. Transforming 100*ct/9.0 to ct/0.09 should be obvious to anyone, and if it isn't, pull down that keyboard and search for another job, more tuned to your skills (flipping burgers, collecting garbage or whatever).

Not a WTF, in my opinion.

The bit I really don't like is adding BOOLs.

I don't like the divide because it's not obvious, and not commented (and not self commenting), and there's also the issue that if you add another thing to check for, then the 'percentage complete' calculation would be wrong.

So, if it was me, I'd:
- change the 'adding BOOLs pattern' to using tertiary operators (slower, but for this type of check I can't see it being an issue)
- change the final calcuation to "(ct / 9) * 100" to make it a bit more obvious
- add a comment to say that if you change the number of checks, then change the calculation at the end

TRWTF is JavaScript, right? Coercing those booleans to be integers (0 or 1) is very cheeky at best - I didn't even know you could do that.

If this were ported to VB it would be even more fun because TRUE would become -1, so you'd divide by -0.09.

It works, but is it portable?

It seems quite an unusual method for validation, but I can see some value in quantifying how far through the validation process you are as a decimal value, rather than the usual true/false/filenotfound.

Then I got to the line:

u.employerSharing && true);

I can't even imagine what sort of person thinks "where [the] employer is sharing, and true" is a reasonable statement.

The WTF is that a % of completeness has been given for a form. On one hand a code maintainer would have to calculate the new number when adding and removing fields. On the other the user would get a percentage value of 'form completeness' which is nonsense.

"7 out of 8 fields completed" is far more intuitive and meaningful.

But of course TRWTF is "&& true", amirite? Or is this just a smart-bottomed technique to force its type?

gallier2:

Transforming 100*ct/9.0 to ct/0.09 should be obvious to anyone

Possibly obvious, but also wrong: 0.09 can't be exactly represented in IEEE floating-point, so you may get a fractionally different result. It happens to work for 9 items, but not in general e.g.

$ python -c 'import math; print math.ceil(57/0.57)'

101

The general trick for forcing types to booleans is !! (not-not)
!!1 === true
!!0 === false

Whether it is smart to use this in everyday code, I don't know.

LoremIpsumDolorSitAmet:

TRWTF is JavaScript, right? Coercing those booleans to be integers (0 or 1) is very cheeky at best - I didn't even know you could do that.

If this were ported to VB it would be even more fun because TRUE would become -1, so you'd divide by -0.09.

Coercing booleans to integers comes from C, and I think since JS is loosely-typed and has C as its most obvious ancestor, you can reasonably expect it to work.

It's still shitty code. No need to repeat all that.

ct=0;

elementslist = [u.nickname, u.websiteUrl, u.linkedin, u.locationString, u.title, u.bio, u.imageUrl, u.resume]

for element in elementslist:

    if typeof(element)=="string" and element.length>0: ct += 1

if u.employerSharing: ct += 1

return 100*ct/(len(elementslist)+1);

Python syntax. I don't know if you can get rid of the "u." in elementslist easily.

Tragedian:

It seems quite an unusual method for validation, but I can see some value in quantifying how far through the validation process you are as a decimal value, rather than the usual true/false/filenotfound.

Then I got to the line:

u.employerSharing && true);

I can't even imagine what sort of person thinks "where [the] employer is sharing, and true" is a reasonable statement.

QJo:

But of course TRWTF is "&& true", amirite? Or is this just a smart-bottomed technique to force its type?

This.

u.employerSharing could be any type. The AND operation will coerce it to a boolean... which is then coerced to a number.

Paul:

The bit I really don't like is adding BOOLs.

I don't like the divide because it's not obvious, and not commented (and not self commenting), and there's also the issue that if you add another thing to check for, then the 'percentage complete' calculation would be wrong.

So, if it was me, I'd:
- change the 'adding BOOLs pattern' to using tertiary operators (slower, but for this type of check I can't see it being an issue)
- change the final calcuation to "(ct / 9) * 100" to make it a bit more obvious
- add a comment to say that if you change the number of checks, then change the calculation at the end

You should also atleast add an XML layer, coupled with DAL and a backing database implementation. Sure it might be slower, but at least it will be obvious with the added benefit of flexibility.

gallier2:

It's actually quite clever. Of course it demands from the developer who reads that, some arithmetic and boolean skills.
I know, it's asking a lot from people who actually are supposed to know how to crunch numbers. Transforming 100*ct/9.0 to ct/0.09 should be obvious to anyone, and if it isn't, pull down that keyboard and search for another job, more tuned to your skills (flipping burgers, collecting garbage or whatever).

Not a WTF, in my opinion.

Clever is a strong word. This is still very stupid code. (Hint: each field is hard coded, as is the constant 0.09.) But I agree its not exactly a WTF either. It's bad code that kinda works for what it was supposed to do.

chris:

Coercing booleans to integers comes from C, and I think since JS is loosely-typed and has C as its most obvious ancestor, you can reasonably expect it to work.

Let's face it, if this were PHP, nobody would be standing up for this code.

The only real difference between JS and PHP is that when it comes to PHP you have alternatives.

MiffTheFox:

chris:

Coercing booleans to integers comes from C, and I think since JS is loosely-typed and has C as its most obvious ancestor, you can reasonably expect it to work.

Let's face it, if this were StackOverflow, nobody would be standing up for this code.

FTFY. This is TDWTF and we love to ironically defend bad code.

Any value coming from a non-checkbox is a string, not sure why you would check the type every time. Also not sure why a function is being declared anonymously, that's irritating. Also not sure what's up withe the && true statement.

function proFormComplete()

{

    var props = ['websiteUrl', 'linkedin']; // etc.

    var ct = 0;

    var u = user.getUser();

    for(var s in props)

    {

        ct += u[s].length > 0;

    }

    ct += !!u.employerSharing;

    return (props.length+1*100)/9;

}

Doctor_of_Ineptitude:

Paul:

The bit I really don't like is adding BOOLs.

I don't like the divide because it's not obvious, and not commented (and not self commenting), and there's also the issue that if you add another thing to check for, then the 'percentage complete' calculation would be wrong.

So, if it was me, I'd:
- change the 'adding BOOLs pattern' to using tertiary operators (slower, but for this type of check I can't see it being an issue)
- change the final calcuation to "(ct / 9) * 100" to make it a bit more obvious
- add a comment to say that if you change the number of checks, then change the calculation at the end

You should also atleast add an XML layer, coupled with DAL and a backing database implementation. Sure it might be slower, but at least it will be obvious with the added benefit of flexibility.

In JS, surely the way to do it is to maintain an array of functions as a property of a function to run them all and divide by the length of the array?

chris:

Doctor_of_Ineptitude:

Paul:

The bit I really don't like is adding BOOLs.

I don't like the divide because it's not obvious, and not commented (and not self commenting), and there's also the issue that if you add another thing to check for, then the 'percentage complete' calculation would be wrong.

So, if it was me, I'd:
- change the 'adding BOOLs pattern' to using tertiary operators (slower, but for this type of check I can't see it being an issue)
- change the final calcuation to "(ct / 9) * 100" to make it a bit more obvious
- add a comment to say that if you change the number of checks, then change the calculation at the end

You should also atleast add an XML layer, coupled with DAL and a backing database implementation. Sure it might be slower, but at least it will be obvious with the added benefit of flexibility.

In JS, surely the way to do it is to maintain an array of functions as a property of a function to run them all and divide by the length of the array?

Nice. We should also add a round trip to server to check the results. That way we also get the opportunity to add a few more security holes and even slow down the system even more. Double win.

¯\(°_o)/¯ I DUNNO LOL:

MiffTheFox:

chris:

Coercing booleans to integers comes from C, and I think since JS is loosely-typed and has C as its most obvious ancestor, you can reasonably expect it to work.

Let's face it, if this were StackOverflow, nobody would be standing up for this code.

FTFY. This is TDWTF and we love to ironically defend bad code.

I'm not entirely certain said defenders are aware of their irony...of course, maybe that makes your statement doubly ironic!

captcha: ludus, as in, "The amount of crappy code people on TDWTF call clever is just ludus".

chris:

Coercing booleans to integers comes from C, and I think since JS is loosely-typed and has C as its most obvious ancestor, you can reasonably expect it to work.

I don't know of any booleans in C. I doubt it exists in C. (Dunno C++)
So if you see this in C, it's not really because the programmer likes ints more, it's because their are no booleans.

Seeing it in a language that knows booleans, that's probably just stupid.

That's "31337", or "1337". But in this case, it's definitely "14M3".

you never use the final result of the ct tally...

perhaps you meant something more like:

return (ct*100)/(props.length + 1);

Why give this function a global variable? For all it's cleverness that's just sloppy.

The types

_Bool

and its alias

bool

are in the C language since the C99 standard (it was already in some compilers like gcc as extension long before that).

bool b = 99;

printf("Value of b=%d\n", b);

will print

Value of b=1

When I have something like this, I use a series of checks, and return false when any check fails, and return true at the end of the subroutine. Why perform unneeded checks?

The real WTF is dividing by 0.09 and incurring a slow division instead of multiplying with 11.11

Y'know, if you replace that last line with "return ct == 9;" you'd have a perfectly reasonable, if somewhat excessively clever, validation routine.

I used to work with a guy who everyone considered a wizard, because he wrote undocumented "clever" code like this that still met its intended function. Pretty much your standard "job security through obfuscation." It was always a treat to come across a SQL statement that took 15 minutes of analysis to figure out it was checking if a certain type of record existed in a table.

I always thought his code would have been TDWTF-worthy, if not that the WTFs therein were completely opaque to anyone without years of intimate knowledge of the DB schema.

LoremIpsumDolorSitAmet:

TRWTF is JavaScript, right? Coercing those booleans to be integers (0 or 1) is very cheeky at best - I didn't even know you could do that.

If this were ported to VB it would be even more fun because TRUE would become -1, so you'd divide by -0.09.

It's odd that you get a code smell so strong from the language itself. If I were to create a language that forced users to type three equal signs in a row, I'd think, "maybe I'm doing something wrong."

realmerlyn:

When I have something like this, I use a series of checks, and return false when any check fails, and return true at the end of the subroutine. Why perform unneeded checks?

Many languages use short-circuit evaluation, So you can do:

if (a bunch of things you expect to be true, ANDed together) {
return true;
}
return false;

Or simply:
return (a bunch of things you expect to be true, ANDed together);

As soon as one of the terms evaluates to false, it will stop evaluating.

But all that aside, this isn't simply evaluating TRUE or FALSE, it's seeing how many things are TRUE or FALSE.

Abico:

realmerlyn:

When I have something like this, I use a series of checks, and return false when any check fails, and return true at the end of the subroutine. Why perform unneeded checks?

Many languages use short-circuit evaluation, So you can do:

if (a bunch of things you expect to be true, ANDed together) {
return true;
}
return false;

Or simply:
return (a bunch of things you expect to be true, ANDed together);

As soon as one of the terms evaluates to false, it will stop evaluating.

But all that aside, this isn't simply evaluating TRUE or FALSE, it's seeing how many things are TRUE or FALSE.

I should note that using short-circuit evaluation can make debugging really obnoxious.

anonymouse:

Also not sure why a function is being declared anonymously, but that's awesome.

FTFY. In this case, easier to attach to an event.

Anonymous functions are the best thing about JS.

gallier2:

Transforming 100*ct/9.0 to ct/0.09 should be obvious to anyone, and if it isn't, pull down that keyboard and search for another job, more tuned to your skills (flipping burgers, collecting garbage or whatever.

So, okay, given that this is clever and "obvious", then why no do the next clever step and change it to multiply by 11.111111? (Multiply being much more efficient than divide.)

TRWTF is not using AJAX to validate on the server:

1. Server request sends parameters to a validation servlet.
2. Server responds with true or false.
3. If the server gave true, submit to the real server.
4. Else, show error message.

Berend:

Why give this function a global variable? For all it's cleverness that's just sloppy.

If it's 'user' you're talking about, then you can't be sure. It may be part of something like:

function setup(){

  var myForm             // This is how you should declare variables,

    , user               // haven't you heard?

    , proFormSetNickname

    // ...

    , proFormComplete

    ;



  myForm = document.getElementById('theForm');

  user = {};



  proFormSetNickname = function(){

    user.nickname = myForm['nickname'].value;

  }

  // ...



  myForm['nickname'].onchange = proFormSetNickname;

  // ...

  myForm.onsubmit = proFormComplete;

}

Zecc:

  myForm.onsubmit = proFormComplete;

Didn't think of how the return value is used, here.
Oh well, wrap it in an anonymous function are compare it to 100 or something

Zylon:

Y'know, if you replace that last line with "return ct == 9;" you'd have a perfectly reasonable, if somewhat excessively clever, validation routine.

Except, of course, that it produces an incompatible result.

That's not so bad. Back in the old days before strict typing rules existed it used to be possible in some languages to do math on strings and get strings in return as a result (binary math on strings with strings can return some interesting, predictable, and hilarious results). Of few of the more enterprising of us figured how how to use this little fact to our advantage much to the chagrin of anyone who actually saw the code.

This is no more arcane than Zeller's Algorithm for calculating the day of the week (in which today's date in ISO form is 2012-13-07).

LordHighFixer:

That's not so bad. Back in the old days before strict typing rules existed it used to be possible in some languages to do math on strings and get strings in return as a result (binary math on strings with strings can return some interesting, predictable, and hilarious results). Of few of the more enterprising of us figured how how to use this little fact to our advantage much to the chagrin of anyone who actually saw the code.

I still can't believe that the plus sign can be used to concatenate strings in VB .NET. Talk about a huge WTF.

I'm not a javascript expert, but that might have something to do with manipulating the return type. Just as I expect the "0 +" at the beginning of the sum is likely for type casting. But does java not have an explicit cast operator?

I know why it works, but booleans should never have been equated to integers.

From "The Elements of Programming Style" which should be required reading:
"Write clearly - don't be too clever."

chubertdev:

It's odd that you get a code smell so strong from the language itself. If I were to create a language that forced users to type three equal signs in a row, I'd think, "maybe I'm doing something wrong."

Yes, but you also might be a pretentious prick.

chubertdev:

I still can't believe that the plus sign can be used to concatenate strings in VB .NET. Talk about a huge WTF.

Why is that a WTF? Its a feature available in many sane languages.