Comment On Loopy Validation

Anonymous:

Antidepressants and Javascript might SEEM to go well together, but...

Newb:

Mandatory summarization: Got paid to port bad code, found bad code.

teh jav:

Newb:

Mandatory summarization: Got paid to port bad code, found bad code.

Like Mandatory Fun Day but less funny.

function isDigit(digit)
{
var charOk = "0123456789";
return !(charOk.indexOf(digit) == -1)
}

function isAlphaNumeric(digit)
{
var charOk =
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
return !(charOk.indexOf(digit) == -1)
}

Newb:

Mandatory summarization: Got paid to port bad code, found bad code.

Beldar the Phantom Replier:

function isDigit(digit)
{
var charOk = "0123456789";
return !(charOk.indexOf(digit) == -1)
}

function isAlphaNumeric(digit)
{
var charOk =
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
return !(charOk.indexOf(digit) == -1)
}

What is so bad about these two functions? Are they really WTF worthy?

I could understand if either of the soft-coded strings were missing some digits or letters (respectively), but I must just be missing the WTF moment here.

// isDecimal

// Validates s as a decimal number within the decimal number system

// Used in all pages which depend on multilingual JavaScripts with language output

 

function isDecimal(s) {

  var j;

  for(var i = 0; i < s.length; i++) {

    var c = s.charAt(i);

    j = parseInt(c,10);

    if ((j >= 0) && (j <= 9)) continue;

    else return false;

  }

  return true;

}



// isInteger

// Validates s as an integer within the decimal number system

// Used in all pages which depend on multilingual JavaScripts with language output

 

function isInteger(s) {

  var j;

  for(var i = 0; i < s.length; i++) {

    var c = s.charAt(i);

    j = parseInt(c,10);

    if ((j >= 0) && (j <= 9)) continue;

    else return false;

  }

  return true;

}

Anonymously Yours:

I don't see an issue with this code. So what if there's a bit of redundancy and unusual customization specific to the task? It's easy to update without breaking anything.

This code doesn't have any issues I can see. Okay, there's some function and procedure copying, but that makes tweaking it to the task easier. Plus updates won't break anything.

Where the issue? I don't see it. Repetitious code isn't cluttered and making uncommented code specific to the task at hand has the upside of not breaking the other 80 places you put copies of it. Updates are easy and safe, you just have to read more.

I don't see a WTF with this code. Who cares if there's a bit of redundancy and unusual customization specific to the job? It's simple to update without breaking anything.

This script doesn't have any WTFs I can perceive. Yes, there's some code copying, but that makes tweaking it to the task easier. Plus changes won't break anything.

Where the WTF? I can't find it. Repetitive work isn't cluttered, and making uncommented code specific to what you're working on has the upside of not breaking the other /* 80 */ 83 places you put copies of it. Updates are easy and safe, you just have more to read.

I don't have a problem with this content. So when if there's a bit of redundancy and unusual customizing unique to the task? It's easy to break without updatinging anything.

This source code doesn't have any visible problems. OK, there's some copying and pasting and pasting but that makes working it to task easier. Plus updates won't crash anything.

Where your boggle? I don't see it. see it. Repetitious code isn't cluttered and making nd has the upside of not breaking the other /* 80 */ 23 places you put copies of it. Updates are easy and safe, you

Anonymously Yours:

I don't see an issue with this code. So what if there's a bit of redundancy and unusual customization specific to the task? It's easy to update without breaking anything.

This code doesn't have any issues I can see. Okay, there's some function and procedure copying, but that makes tweaking it to the task easier. Plus updates won't break anything.

Where the issue? I don't see it. Repetitious code isn't cluttered and making uncommented code specific to the task at hand has the upside of not breaking the other 80 places you put copies of it. Updates are easy and safe, you just have to read more.

I don't see a WTF with this code. Who cares if there's a bit of redundancy and unusual customization specific to the job? It's simple to update without breaking anything.

This script doesn't have any WTFs I can perceive. Yes, there's some code copying, but that makes tweaking it to the task easier. Plus changes won't break anything.

Where the WTF? I can't find it. Repetitive work isn't cluttered, and making uncommented code specific to what you're working on has the upside of not breaking the other /* 80 */ 83 places you put copies of it. Updates are easy and safe, you just have more to read.

I don't have a problem with this content. So when if there's a bit of redundancy and unusual customizing unique to the task? It's easy to break without updatinging anything.

This source code doesn't have any visible probles. OK, there's some copying and pasting and pasting but that makes working it to task easier. Plus updates won't crash anything.

Where your boggle? I don't see it. see it. Repetitious code isn't cluttered and making nd has the upside of not breaking the other /* 80 */ 23 places you put copies of it. Updates are easy and safe, you

sdfggfdsg:

Anonymously Yours:

I don't see an issue with this code. So what if there's a bit of redundancy and unusual customization specific to the task? It's easy to update without breaking anything.

This code doesn't have any issues I can see. Okay, there's some function and procedure copying, but that makes tweaking it to the task easier. Plus updates won't break anything.

Where the issue? I don't see it. Repetitious code isn't cluttered and making uncommented code specific to the task at hand has the upside of not breaking the other 80 places you put copies of it. Updates are easy and safe, you just have to read more.

I don't see a WTF with this code. Who cares if there's a bit of redundancy and unusual customization specific to the job? It's simple to update without breaking anything.

This script doesn't have any WTFs I can perceive. Yes, there's some code copying, but that makes tweaking it to the task easier. Plus changes won't break anything.

Where the WTF? I can't find it. Repetitive work isn't cluttered, and making uncommented code specific to what you're working on has the upside of not breaking the other /* 80 */ 83 places you put copies of it. Updates are easy and safe, you just have more to read.

I don't have a problem with this content. So when if there's a bit of redundancy and unusual customizing unique to the task? It's easy to break without updatinging anything.

This source code doesn't have any visible probles. OK, there's some copying and pasting and pasting but that makes working it to task easier. Plus updates won't crash anything.

Where your boggle? I don't see it. see it. Repetitious code isn't cluttered and making nd has the upside of not breaking the other /* 80 */ 23 places you put copies of it. Updates are easy and safe, you

You need to be taken out back GIVEN and shot.

Melvis:

sdfggfdsg:

Anonymously Yours:

I don't see an issue with this code. So what if there's a bit of redundancy and unusual customization specific to the task? It's easy to update without breaking anything.

This code doesn't have any issues I can see. Okay, there's some function and procedure copying, but that makes tweaking it to the task easier. Plus updates won't break anything.

Where the issue? I don't see it. Repetitious code isn't cluttered and making uncommented code specific to the task at hand has the upside of not breaking the other 80 places you put copies of it. Updates are easy and safe, you just have to read more.

I don't see a WTF with this code. Who cares if there's a bit of redundancy and unusual customization specific to the job? It's simple to update without breaking anything.

This script doesn't have any WTFs I can perceive. Yes, there's some code copying, but that makes tweaking it to the task easier. Plus changes won't break anything.

Where the WTF? I can't find it. Repetitive work isn't cluttered, and making uncommented code specific to what you're working on has the upside of not breaking the other /* 80 */ 83 places you put copies of it. Updates are easy and safe, you just have more to read.

I don't have a problem with this content. So when if there's a bit of redundancy and unusual customizing unique to the task? It's easy to break without updatinging anything.

This source code doesn't have any visible probles. OK, there's some copying and pasting and pasting but that makes working it to task easier. Plus updates won't crash anything.

Where your boggle? I don't see it. see it. Repetitious code isn't cluttered and making nd has the upside of not breaking the other /* 80 */ 23 places you put copies of it. Updates are easy and safe, you

You need to be taken out back and GIVEN A shot.

Fixed.

Anonymously Yours:

I don't see an issue with this code. So what if there's a bit of redundancy and unusual customization specific to the task? It's easy to update without breaking anything.

This code doesn't have any issues I can see. Okay, there's some function and procedure copying, but that makes tweaking it to the task easier. Plus updates won't break anything.

Where the issue? I don't see it. Repetitious code isn't cluttered and making uncommented code specific to the task at hand has the upside of not breaking the other 80 places you put copies of it. Updates are easy and safe, you just have to read more.

I don't see a WTF with this code. Who cares if there's a bit of redundancy and unusual customization specific to the job? It's simple to update without breaking anything.

This script doesn't have any WTFs I can perceive. Yes, there's some code copying, but that makes tweaking it to the task easier. Plus changes won't break anything.

Where the WTF? I can't find it. Repetitive work isn't cluttered, and making uncommented code specific to what you're working on has the upside of not breaking the other /* 80 */ 83 places you put copies of it. Updates are easy and safe, you just have more to read.

I don't have a problem with this content. So when if there's a bit of redundancy and unusual customizing unique to the task? It's easy to break without updatinging anything.

This source code doesn't have any visible probles. OK, there's some copying and pasting and pasting but that makes working it to task easier. Plus updates won't crash anything.

Where your boggle? I don't see it. see it. Repetitious code isn't cluttered and making nd has the upside of not breaking the other /* 80 */ 23 places you put copies of it. Updates are easy and safe, you

Anyone:

teh jav:

Newb:

Mandatory summarization: Got paid to port bad code, found bad code.

Like Mandatory Fun Day but less funny.

So like Mandatory Fun Day then :P ?

Newb:

Mandatory summarization: Got paid to port bad code, found bad code.

Anonymously Yours:

You all may be having trouble seeing the forest for all the trees. Due to the number of trees to all may be experiencing difficulty seeing the forest. The forest might escape your vision because of placement of trees. You guys may be having trouble noticing the forest for all the trees. Due to the quantity of foliage to all may be experiencing difficulty seeing the forest. The forest might escape your sight because of placement You all may not see the forest because of all the trees. As a result of the number of trees to all may be experiencing trouble seeing the forest. The forest not be in escape your vision because of placement of trees. of trees.

mjk:

function popupRegulations(popWinURL, popWinTitle, popWinWidth, popWinHeight)

function popupDemo(windowURL, windowTitle)
...
function popupTutorials(popWinURL, popWinTitle, popWinWidth, popWinHeight)

--------------------
what is wrong with these functions?

Stephen E. Baker:

<quote>
Just a typical use of the for-case construct. You know, the one that looks like this:
for (int i=0; i < 3; i++) {
switch(i):
case 0:
puts("W");
break;
case 1:
puts("T");
break;
case 2:
puts("F");
}
</quote>

WTFTFF

sad bob:

Anonymously Yours:

You all may be having trouble seeing the forest for all the trees. Due to the number of trees to all may be experiencing difficulty seeing the forest. The forest might escape your vision because of placement of trees. You guys may be having trouble noticing the forest for all the trees. Due to the quantity of foliage to all may be experiencing difficulty seeing the forest. The forest might escape your sight because of placement You all may not see the forest because of all the trees. As a result of the number of trees to all may be experiencing trouble seeing the forest. The forest not be in escape your vision because of placement of trees. of trees.

it was clever the first time. not that time.

gasman:

Newb:

Mandatory summarization: Got paid to port bad code, found bad code.

That is kind of the whole point of this website, yes. Were you looking for thedailypeoplewhoarecompetentattheirjobsandeverythingturnsoutfine.com instead?

Mike Caron:

If you learned anything about for loops by looking at that code, you're doing it wrong.

Captcha: quis (yes, I am feeling a bit quisy)

SR:

Beldar the Phantom Replier:

function isDigit(digit)
{
var charOk = "0123456789";
return !(charOk.indexOf(digit) == -1)
}

function isAlphaNumeric(digit)
{
var charOk =
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
return !(charOk.indexOf(digit) == -1)
}

What is so bad about these two functions? Are they really WTF worthy?

I could understand if either of the soft-coded strings were missing some digits or letters (respectively), but I must just be missing the WTF moment here.

JS has isNaN() and !isNaN() to do these things.

Alex Papadipamopaopeaopolis:

"On the bright side," Clark added, "at least I finally found something impressively bad."

Anonymously Yours:

sad bob:

Anonymously Yours:

You all may be having trouble seeing the forest for all the trees. Due to the number of trees to all may be experiencing difficulty seeing the forest. The forest might escape your vision because of placement of trees. You guys may be having trouble noticing the forest for all the trees. Due to the quantity of foliage to all may be experiencing difficulty seeing the forest. The forest might escape your sight because of placement You all may not see the forest because of all the trees. As a result of the number of trees to all may be experiencing trouble seeing the forest. The forest not be in escape your vision because of placement of trees. of trees.

it was clever the first time. not that time.

I was just replying to the people who seemed to miss it the first time. I'd rather make what happened more obvious instead of explaining the other post. That takes all the fun out of it.

Kagome Higurashi:

mjk:

what is wrong with these functions?

Redundancy.

Anonymously Yours:

I don't see an issue with this code. So what if there's a bit of redundancy and unusual customization specific to the task? It's easy to update without breaking anything.

This code doesn't have any issues I can see. Okay, there's some function and procedure copying, but that makes tweaking it to the task easier. Plus updates won't break anything.

Where the issue? I don't see it. Repetitious code isn't cluttered and making uncommented code specific to the task at hand has the upside of not breaking the other 80 places you put copies of it. Updates are easy and safe, you just have to read more.

I don't see a WTF with this code. Who cares if there's a bit of redundancy and unusual customization specific to the job? It's simple to update without breaking anything.

This script doesn't have any WTFs I can perceive. Yes, there's some code copying, but that makes tweaking it to the task easier. Plus changes won't break anything.

Where the WTF? I can't find it. Repetitive work isn't cluttered, and making uncommented code specific to what you're working on has the upside of not breaking the other /* 80 */ 83 places you put copies of it. Updates are easy and safe, you just have more to read.

I don't have a problem with this content. So when if there's a bit of redundancy and unusual customizing unique to the task? It's easy to break without updatinging anything.

This source code doesn't have any visible probles. OK, there's some copying and pasting and pasting but that makes working it to task easier. Plus updates won't crash anything.

Where your boggle? I don't see it. see it. Repetitious code isn't cluttered and making nd has the upside of not breaking the other /* 80 */ 23 places you put copies of it. Updates are easy and safe, you

Paul:

Kagome Higurashi:

mjk:

what is wrong with these functions?

Redundancy.

But they're not totally redundant.

If you want to change the way that 'Tutorials' popup now, then you just change one function - job done. If you just had one function instead, it would be a lot harder, as you'd have to find everywhere that called 'CreateGenericPopup' which used it in a 'Tutorial' sense.

Paul:

Kagome Higurashi:

mjk:

what is wrong with these functions?

Redundancy.

But they're not totally redundant.

If you want to change the way that 'Tutorials' popup now, then you just change one function - job done. If you just had one function instead, it would be a lot harder, as you'd have to find everywhere that called 'CreateGenericPopup' which used it in a 'Tutorial' sense.

Anonymously Yours:

I don't see an issue with this code. So what if there's a bit of redundancy and unusual customization specific to the task? It's easy to update without breaking anything.

This code doesn't have any issues I can see. Okay, there's some function and procedure copying, but that makes tweaking it to the task easier. Plus updates won't break anything.

Where the issue? I don't see it. Repetitious code isn't cluttered and making uncommented code specific to the task at hand has the upside of not breaking the other 80 places you put copies of it. Updates are easy and safe, you just have to read more.

I don't see a WTF with this code. Who cares if there's a bit of redundancy and unusual customization specific to the job? It's simple to update without breaking anything.

This script doesn't have any WTFs I can perceive. Yes, there's some code copying, but that makes tweaking it to the task easier. Plus changes won't break anything.

Where the WTF? I can't find it. Repetitive work isn't cluttered, and making uncommented code specific to what you're working on has the upside of not breaking the other /* 80 */ 83 places you put copies of it. Updates are easy and safe, you just have more to read.

I don't have a problem with this content. So when if there's a bit of redundancy and unusual customizing unique to the task? It's easy to break without updatinging anything.

This source code doesn't have any visible probles. OK, there's some copying and pasting and pasting but that makes working it to task easier. Plus updates won't crash anything.

Where your boggle? I don't see it. see it. Repetitious code isn't cluttered and making nd has the upside of not breaking the other /* 80 */ 23 places you put copies of it. Updates are easy and safe, you

xtremezone:

This looks like the kind of JavaScript that I wrote when I was new to it. In my experience, it takes a while to begin to understand the language and browser built-ins. It's WTF worthy, but I think the author can be forgiven. I still write crappy JavaScript, but I'd like to think /some/ of it is better than this. ;)