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

    You, sir, win the internets. That was downright hilarious.

    (and to you people without a sense of humor - I'd joke about it, but you wouldn't get it anyway)

  • franz ferdinand (unregistered) in reply to Amtep
    Amtep:
    A mistake as small as using a union where you need an intersection could introduce a hard-to-spot bug in your validation routine and perhaps open your site to intrusion. I'm sure you would never make such a mistake, but keep in mind that other people modifying your code (perhaps less competent, perhaps inattentive) will have an easier time getting it right if you keep it simple.

    The problem I have with this is your assumption that your programmers are going to screw up things as commonplace as logical intersections and unions, and building an entire system of inefficient, inappropriate code structures around it. My solution to a programmer who worries me that he won't be able to evaluate X = (A and B) or (C or D) and E is to replace the programmer, not the program.

    Amtep:
    As an exercise for the reader, imagine that your least intelligent coworker is assigned the task of excluding i == 3 from the condition. Which form of the code is easier to maintain and thus more robust?

    The correct answer is whatever form of the code does NOT have that co-worker working on it. Which points to the solution for the whole problem.

    If Microsoft had this problem on the Windows team, we would all be using Macs, because Windows would be slower than molasses. Clarity in your code, besides being slightly subjective, is not an absolute end in and of itself but must be balanced with other considerations.

    Just reflect on what you are defending here:

    For x = 0 to 9
         If x=1 Then
         ElseIf x=2 Then
         ElseIf x=3 Then
         ElseIf x=4 Then
         ElseIf x=5 Then
         ElseIf x=6 Then
         ElseIf x=7 Then
         ElseIf x=8 Then
         ElseIf x=9 Then
              Object.Method
         EndIf
    Next

    ... an anti-pattern for a reason.

  • verto (unregistered) in reply to woodle
    woodle:
    Nyquist:
    Because there are better ways of doing things like character validation that a first year university student learns in the first semester.

    And that for loop really gives me the lolz.

    If you find that code in any way amusing then you haven't been in The Real World for very long.

    OK, it's certainly not great and there is plenty of room for improvement. But my reaction when I saw it was more of a <sigh> than a "WTF??!!1!?". It's mediocre, not catastrophic.

    Some redundancy, if/else instead of a switch, some magic numbers instead of constants, not using built in functions that would have been useful - bah! All very, very ordinary.

    And for the record, JavaScript is a great language, some of the most elegant code I've ever seen was written in JavaScript. Unfortunately it's fairly quick to get results in and the interweb is strewn with sites chock full of very poor examples that inexperienced developers can copy, so there is a lot of less than optimal code out there in the wild.

    But the same can be said about C# and Perl. And Ruby. And Java.

    Thank you, woodle.
  • Resa (unregistered) in reply to Your Name
    Your Name:
    TRWTF is how the featured comment went whoosh over some people's heads.

    True that! That was absolutely hilarious!

  • wtf (unregistered) in reply to Anonymously Yours

    This comment is absolutely DailyWTF-worthy.

  • London Developer (unregistered) in reply to Anonymously Yours
    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

    I think that's great. I thought that was great. That's great. That was great.

  • Blayne (unregistered) in reply to Anonymously Yours

    i feel like your comment was generated with this code

  • anon (unregistered) in reply to Anonymously Yours

    Please post whoever was crazy enough to hire you, so that I know never to work there...

  • C (unregistered) in reply to franz ferdinand
    franz ferdinand:
    Amtep:
    A mistake as small as using a union where you need an intersection could introduce a hard-to-spot bug in your validation routine and perhaps open your site to intrusion. I'm sure you would never make such a mistake, but keep in mind that other people modifying your code (perhaps less competent, perhaps inattentive) will have an easier time getting it right if you keep it simple.
    The problem I have with this is your assumption that your programmers are going to screw up things as commonplace as logical intersections and unions, and building an entire system of inefficient, inappropriate code structures around it.
    Apparently, you missed the whole point. Please re-read the comment that Amtep replied to. And if you still don't get it, think about what "if(i >= 1) || i <= 2)" actually does.
  • TheGodDamnMan (unregistered) in reply to Anonymously Yours
    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

    I see what you did ther.

  • Anonymous (unregistered) in reply to Anonymously Yours

    I get jokes.

  • Anonymous (unregistered) in reply to Anonymously Yours

    pmsl at last comment... lulz

  • Tangr (unregistered) in reply to Anonymously Yours

    Where is the WTF? I can see it plainly.

    Okay, your comment was sort of unclear and repetitive so I'll try my best to help.

    Shouldn't coding be as small as possible to optimize performance? Eg: If 5000 lines of code will do, why write 6000?

    Your comment was a little repetive and unclear. Where is the WTF? I can see it plainly.

    There isn't a issue with the code. However, it doesn't follow the proper programmer's guidelines.

    Again, your comment was a little repetitive.

    Copying and pasting code is encouraged but when it is used without understanding it fully, it becomes clutter.

    So why write more code than you need.

    But what happens when you need to clean up the code? Everything needs /* to be redone */ almost redone.

    Where is the WTF? I can see it plainly.

    I completely disagree that repititious code isn't cluttered. What happens when you need to unrepetidize it?

    AGain, your comment was unclear

  • Henry Troup (unregistered) in reply to Anonymously Yours

    The "for" loop that only does anything for value 0 doesn't bother you?

  • Bob (unregistered) in reply to Anonymously Yours

    In other words, the coder is wearing seven pairs of pants (each with holes in different places) to cover his behind.

  • Bob (unregistered) in reply to Tangr
    Where is the WTF? I can see it plainly.

    Okay, your comment was sort of unclear and repetitive so I'll try my best to help.

    Shouldn't coding be as small as possible to optimize performance? Eg: If 5000 lines of code will do, why write 6000?

    Your comment was a little repetive and unclear. Where is the WTF? I can see it plainly.

    There isn't a issue with the code. However, it doesn't follow the proper programmer's guidelines.

    Again, your comment was a little repetitive.

    Copying and pasting code is encouraged but when it is used without understanding it fully, it becomes clutter.

    So why write more code than you need.

    But what happens when you need to clean up the code? Everything needs /* to be redone */ almost redone.

    Where is the WTF? I can see it plainly.

    I completely disagree that repititious code isn't cluttered. What happens when you need to unrepetidize it?

    AGain, your comment was unclear

    WTF?

  • outside the box (unregistered) in reply to TimTom

    I wonder if the submitted understands JavaScript function parameters.

    function OpenWindowToReports (address, height, width) { //var features = "height=" + height + ",width=" + width; var features = "height=640,width=480"; address = (address == null ? "http://server/reports.aspx" : address); return window.open(address, null, features); }

    This allows specific caller-level overrides while also preserving the option of making changes in only one place.

  • Joshua (unregistered) in reply to Anonymously Yours

    Ever heard of ... (gasp) ... umm... (>.>) ... uh... regular expressions?

  • LegacyCrono (unregistered) in reply to Anonymously Yours

    Hopefully you aren't serious, or hopefully you aren't the programmer that actually coded that. Just look at that "for" statement. LOOK!

  • sirius (unregistered) in reply to Anonymously Yours

    how about setting a return statement in a for loop(which is always reached) it's like they expected it to return without breaking the for loop

    and @anonymously yours: why do you state the same thing 9 times

  • sirius (unregistered) in reply to sirius

    failage comment from me, forgot what the for loop looked like still, pointless to make an if(i = 1 || i = 2 .....|| i = 9){nop} statement(besides, continue; should give an error, because as far as i know it's not a function, but that might just be me)

  • Andreas (unregistered) in reply to Anonymously Yours
    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

    Are you serious? Did you see the for loop?

  • WindsAloft (unregistered) in reply to Anonymously Yours

    ^ Amazing

Leave a comment on “Loopy Validation”

Log In or post as a guest

Replying to comment #:

« Return to Article