It's ok, I used a regex



  • I've been trying to get people on the team to use Regex when/if they have to format validation. I suppose this is a step in the right direction? (As long as you don't mind the 2 ball-kickingly bad steps back)


    function PostalCode(vTestValue)
    {
                var vNums = vTestValue.charAt(1) +vTestValue.charAt(3) +vTestValue.charAt(5);

                if (vNums.match(/[0-9][0-9][0-9]/) == null)
                {
                    return false;
                }
             

               return true;

    }




  • Wait, they're doing what?  What is the format for postal codes in canadia?



  • Letter-Digit-Letter Digit-Letter-Digit.

    They don't use the letters D, F, I, O, Q, or U.

    (Not a Canadian.)


  • Discourse touched me in a no-no place

    @locallunatic said:

    Wait, they're doing what?  What is the format for postal codes in canadia?

    Without bothering to look I'd guess something like ®5¶3⁂6‱☞ judging from that code snippet.



  • Ze goggles...



  • @blakeyrat said:

    Letter-Digit-Letter Digit-Letter-Digit.

    They don't use the letters D, F, I, O, Q, or U.

    (Not a Canadian.)

     

    Thanks, I missed Lorne's tag with a better regex (though apparently it would still allow through bad letters).



  • @locallunatic said:

    @blakeyrat said:

    Letter-Digit-Letter Digit-Letter-Digit.

    They don't use the letters D, F, I, O, Q, or U.

    (Not a Canadian.)

     

    Thanks, I missed Lorne's tag with a better regex (though apparently it would still allow through bad letters).

     

     Didn't know about those unused letters, though I'd err on the side of "a moving target" and let them through anyways. 



  • Let's use a really big hammer when a much smaller one would do.  Aside from the obvious errors (assuming the string has at least 6 chars, ignoring the characters after the 6th char, constructing a temp string; not using the ternary operator), why would you think that using a regex to parse/test this string is efficient?

     (OK, with modern processors you almost never have to think about efficiency at this level; whats the difference between a few hundred cycles and a few thousand?) But still, regex is overkill.  Now if I needed to test a more complicated string I'd use regex, but just to see if 3 chars are numbers?

     Or maybe I'm missing the whole point, where /^[A-Za-z][0-9][A-Za-z][0-9][A-Za-z][0-9]$/  is simpler to write, test, and understand than faster but more complicated code



  • @Lorne Kates said:

    Didn't know about those unused letters, though I'd err on the side of "a moving target" and let them through anyways.

    Probably a good plan. Also the middle character is not well-defined-- sometimes it's a space, sometimes a dash, sometimes it's not there at all. Your RegEx covers that (at least as far as I can read RegEx, which is... not well), in our case the field is only 6-digits wide so it's not an issue. But I could see it tripping someone up.

    And yeah, we don't exclude any letters either. That list was just in the code comment next to the ZIP code validator I wrote... good thing, too, as Wikipedia tells me U is used in some cases.



  • @dogbrags said:

    But still, regex is overkill. Now if I needed to test a more complicated string I'd use regex, but just to see if 3 chars are numbers

    Well, the another choice would be something like this:

    int l = str.len();
    if (l != 6 && l != 7)
      return false;
    if (!is_alpha(str[0]))
      return false;
    if (!is_numeric(str[1]))
      return false;
    if (!is_alpha(str[2]))
      return false;
    int i = 3;
    if (!is_numeric(str[i])) {
      if (str[i] != ' ' && str[i] != '-')
        return false;
      if (!is_numeric(str[++i]))
        return false;
      if (l == 6)
        return false;
    } else if (l == 7)
      return false;
    if (!is_alpha(str[++i]))
      return false;
    if (!is_numeric(str[++i]))
      return false;
    

    return true;

    And good regexp parser probably optimizes it pretty close to that anyway (+regexp expression parsing if it's not pre-compiled)



  • @dogbrags said:

    Let's use a really big hammer when a much smaller one would do.  Aside from the obvious errors (assuming the string has at least 6 chars, ignoring the characters after the 6th char, constructing a temp string; not using the ternary operator), why would you think that using a regex to parse/test this string is efficient?

     (OK, with modern processors you almost never have to think about efficiency at this level; whats the difference between a few hundred cycles and a few thousand?) But still, regex is overkill.  Now if I needed to test a more complicated string I'd use regex, but just to see if 3 chars are numbers?

     Or maybe I'm missing the whole point, where /^[A-Za-z][0-9][A-Za-z][0-9][A-Za-z][0-9]$/  is simpler to write, test, and understand than faster but more complicated code

    Really? You think a chain of ifs is easier? Regexes are never pretty, but as regexes go, that (or /^\w\d\w\d\w\d$/) is pretty straightforward. I mean, you have know know regex to understand it...but that kind of goes without saying. Overuse of regex is indeed a problem, but I'd argue that so is underuse--regex has real, valid, useful uses, it's not just a tool invented to torture programmers. And this seems like just the sort of situation that regex was made for (middle character issues notwithstanding).



  • @dogbrags said:

    Aside from the obvious errors (assuming the string has at least 6 chars, ignoring the characters after the 6th char, constructing a temp string; [b]not using the ternary operator[/b])
     

     Really? "Not using the ternary operator", an arbitrary coding style preference, now counts as an "obvious error"?



  • @Bumble Bee Tuna said:

    @dogbrags said:

    Aside from the obvious errors (assuming the string has at least 6 chars, ignoring the characters after the 6th char, constructing a temp string; not using the ternary operator)
     

     Really? "Not using the ternary operator", an arbitrary coding style preference, now counts as an "obvious error"?

     

    It is when the coder would reply "What's a ternary operator?"

    ... and who writes

    if (someBoolean = True)

     return True

    else

     return False

    end if



  • @Lorne Kates said:

    @Bumble Bee Tuna said:

    @dogbrags said:

    Aside from the obvious errors (assuming the string has at least 6 chars, ignoring the characters after the 6th char, constructing a temp string; not using the ternary operator)
     

     Really? "Not using the ternary operator", an arbitrary coding style preference, now counts as an "obvious error"?

     

    It is when the coder would reply "What's a ternary operator?"

    Huuuh?

    The whole point of avoiding the ternary operator is that a lot of programmers don't know what it is or how to use it. (And those who do know how to use it frequently use it to make unreadable spaghetti piles of crap.)

    So you're saying you should encourage the use of an operator that the other programmers might be terrible at using? One that has an easy-to-read, 100% equivalent form that every programmer knows?

    Is your code review basically designed to create buggy programs? Because it seems like that's your end-goal here.



  • @blakeyrat said:

    The whole point of avoiding the ternary operator is that a lot of programmers don't know what it is or how to use it. (And those who do know how to use it frequently use it to make unreadable spaghetti piles of crap.)

    So you're saying you should encourage the use of an operator that the other programmers might be terrible at using? One that has an easy-to-read, 100% equivalent form that every programmer knows?

    Is your code review basically designed to create buggy programs? Because it seems like that's your end-goal here.

     

    I don't expect other codes to use it, but I would expect them to at least KNOW about it. Especially given that it's used in the codebase, so he has encountered it. It's a fairly basic concept that anyone who has "near 5 years experience" should have encountered and understood, even if they don't use it.



  • @Lorne Kates said:

    @blakeyrat said:

    The whole point of avoiding the ternary operator is that a lot of programmers don't know what it is or how to use it. (And those who do know how to use it frequently use it to make unreadable spaghetti piles of crap.)

    So you're saying you should encourage the use of an operator that the other programmers might be terrible at using? One that has an easy-to-read, 100% equivalent form that every programmer knows?

    Is your code review basically designed to create buggy programs? Because it seems like that's your end-goal here.

     

    I don't expect other codes to use it, but I would expect them to at least KNOW about it. Especially given that it's used in the codebase, so he has encountered it. It's a fairly basic concept that anyone who has "near 5 years experience" should have encountered and understood, even if they don't use it.

    A few posts ago, you said that not using the ternary operator was, and I quote, "an obvious error." Now you say you don't expect other coders to use it. So maybe figure it out and report back, huh?



  • @blakeyrat said:

    A few posts ago, you said that not using the ternary operator was, and I quote, "an obvious error." Now you say you don't expect other coders to use it. So maybe figure it out and report back, huh?

     Hi, reporting back. My report is as follows:

     @dogbrags said:


    Aside from the obvious errors (assuming the string has at least 6
    chars, ignoring the characters after the 6th char, constructing a temp
    string; not using the ternary operator)

    After careful analysis and research, it turns out that I'm not dogbrags.

    I prefer dark chocolate and blue roses. Cash is ok, but no paypal.



  • @Lorne Kates said:

    After careful analysis and research, it turns out that I'm not dogbrags.

    Confuzzled by someone replying to someone else's thread once again! I admit defeat, and offer a one-time gift of... uh. This CSS Is Awesome mug. Just the link. Not the actual mug.



  • @blakeyrat said:

    @Lorne Kates said:
    After careful analysis and research, it turns out that I'm not dogbrags.

    Confuzzled by someone replying to someone else's thread once again! I admit defeat, and offer a one-time gift of... uh. This CSS Is Awesome mug. Just the link. Not the actual mug.

     

    I shall cherish it forever. Until the site goes out of business. Then I shall cherish archive.org forever.



  • @Lorne Kates said:

    @blakeyrat said:

    @Lorne Kates said:
    After careful analysis and research, it turns out that I'm not dogbrags.

    Confuzzled by someone replying to someone else's thread once again! I admit defeat, and offer a one-time gift of... uh. This CSS Is Awesome mug. Just the link. Not the actual mug.

     

    I shall cherish it forever. Until the site goes out of business. Then I shall cherish archive.org forever.

    I actually have the mug on my desk. It's badass.



  •  @Lorne Kates said:

    I've been trying to get people on the team to use Regex when/if they have to format validation.
    As someone who's always had team members lag behind I have to say I understand your pain.



  • @blakeyrat said:

    @Lorne Kates said:
    After careful analysis and research, it turns out that I'm not dogbrags.

    Confuzzled by someone replying to someone else's thread once again! I admit defeat, and offer a one-time gift of... uh. This CSS Is Awesome mug. Just the link. Not the actual mug.

     

    I lol'd at this mug. Do you perchance have a newsletter to which I may subscribe?





  • @superjer said:

    it sure is!
     

    I appropriately tagged your post.



  • @blakeyrat said:

    The whole point of avoiding the ternary operator is that a lot of programmers don't know what it is or how to use it. (And those who do know how to use it frequently use it to make unreadable spaghetti piles of crap.)

    If you're a programmer and you come across something you don't understand in code, you go and read the language's docs, or you ask someone senior to you. You don't fucking say "I dunno what that is" and go back to biting on a rock, because that's lazy and stupid and if you're that lazy and that stupid, you are going to write bad code.

    Besides, the ternary operator is a fundamental feature of almost every programming language available to man. (If you code in a language that doesn't have it, that language is unadulterated shit.) If you don't fucking well know fundamental language features, it is 100% certain you are going to write bad code. QED.

    @blakeyrat said:

    So you're saying you should encourage the use of an operator that the other programmers might be terrible at using? One that has an easy-to-read, 100% equivalent form that every programmer knows?

    How is it possible to be "terrible at using" an operator? If you meant to type "terrible at understanding", your argument is still invalid because if you can't understand something as simple as the ternary operator, you're a failure as a human being, not to mention a programmer. I find ternaries far faster, and therefore easier, to read than if...else blocks because the expression is all on one line.

    @blakeyrat said:

    Is your code review basically designed to create buggy programs? Because it seems like that's your end-goal here.

    Yes, let's ignore useful operators because they're potentially confusing! I guess you're going to have a difficult time writing code then, because any operator can be used in a confusing manner - like using

    !(left == right)
    instead of
    (left != right)
    .

    In my decade of coding, I've been caught out by ternary expressions a handful of times. Statements where ! is the first operator after the left bracket - particularly when followed by another left backet, e.g.

    (!(left as Something) == (right as Something))
    - are far more dangerous.



  • @The_Assimilator said:

    (If you code in a language that doesn't have it, that language is unadulterated shit.)
     

    But VB.Net doesn't have a ternary operator, and it... oh.



  • @Lorne Kates said:

    @The_Assimilator said:

    (If you code in a language that doesn't have it, that language is unadulterated shit.)
     

    But VB.Net doesn't have a ternary operator, and it... oh.

    Actually it does, sorta, but it may not behave as you expect.



  • @The_Assimilator said:

    @Lorne Kates said:

    @The_Assimilator said:

    (If you code in a language that doesn't have it, that language is unadulterated shit.)
     

    But VB.Net doesn't have a ternary operator, and it... oh.

    Actually it does, sorta, but it may not behave as you expect.

     

    Yes, I know about Iif(condtion, true, false).  I don't consider a function to be an operator. I am surprised VB.Net has mathmatical operators. I was expecting to have to type [i]sum = Add(1, 2)[/i]

    VB.Net has so many little syntax things that would be wrong in any other language. It really screws up your thinking when having to switch between it and a real language (or JavaScript, which at least uses real syntax).

    It'd be like if, at home, everyone insisted on using the wrong "there, their and they're", and then you go to a strict grammar school run by nuns with spiked rulers and a hankering for some spankering.



  • @The_Assimilator said:

    If you're a programmer and you come across something you don't understand in code, you go and read the language's docs, or you ask someone senior to you. You don't fucking say "I dunno what that is" and go back to biting on a rock, because that's lazy and stupid and if you're that lazy and that stupid, you are going to write bad code.

    I agree, but that's not the point. The point is, sooner or later, your project is going to have a contributer who is (in your words) "lazy and stupid." It will happen with 100% certainty if your project survives long enough. And when it does happen, your "lazy and stupid" programmer is going to try to work with your ternary operators, and fail, and introduce bugs, and your product quality is going to nose-dive.

    Software development isn't just writing something a computer can understand. It's writing something that a computer and a human, simultaneously, can understand.

    Now your point: the lazy and stupid person is going to write bad code anyway. Well, possibly. But why not take out some insurance and reduce the chance of that happening? What's the end-goal? To have a bug-free product? Work towards that goal.

    @The_Assimilator said:

    Besides, the ternary operator is a fundamental feature of almost every programming language available to man.

    Not really, no.

    @The_Assimilator said:

    If you don't fucking well know fundamental language features, it is 100% certain you are going to write bad code. QED.

    Look: the ternary operator is not a "well known fundamental language feature" in any language. It's never even taught in most schools. It's an expression that duplicates something that already exists, and is the more obscure of the two, so it can't possibly be defined as a "fundamental language feature."

    And the world isn't as black and white as you seem to think it is. There are probably millions of programmers who can write solid code with if() statements, but would get thrown with a construct like:

    return Value < MinVal ? MinVal : (Value > MaxVal ? MaxVal : Value);

    And you know what? I wouldn't blame them.

    @The_Assimilator said:

    How is it possible to be "terrible at using" an operator? If you meant to type "terrible at understanding",

    Thanks, Mr. Pedantic Asshole.

    @The_Assimilator said:

    your argument is still invalid because if you can't understand something as simple as the ternary operator, you're a failure as a human being, not to mention a programmer.

    Wow you're being a prick right now. So if a brain surgeon who's saved hundreds of lives with his new, extremely complex 6-hour-long surgical technique doesn't understand the ternary operator, he's a "failure as a human being?" Is your world really so tiny?

    If you genuinely believe that, fuck you. Just... fuck you. There's no other way to express how disgusting that line of thinking is.

    @The_Assimilator said:

    I find ternaries far faster, and therefore easier, to read than if...else blocks because the expression is all on one line.

    I guess it never occurred to you to just write the if() block on one like. You misanthropic moron.

    @The_Assimilator said:

    Yes, let's ignore useful operators because they're potentially confusing! I guess you're going to have a difficult time writing code then, because any operator can be used in a confusing manner - like using

    !(left == right)
    instead of
    (left != right)
    .

    Yeah, and I'd recommend that people avoid doing that as well. But... nice try trying to paint me as a hypocrite. Maybe next time you'll be more successful at creating your Blakeyrat Strawman.

    @The_Assimilator said:

    In my decade of coding, I've been caught out by ternary expressions a handful of times.

    If it's more than zero times, then you're just supporting my point.

    @The_Assimilator said:

    Statements where ! is the first operator after the left bracket - particularly when followed by another left backet, e.g.

    (!(left as Something) == (right as Something))
    - are far more dangerous.

    Quite possibly, but that isn't what we were talking about, and so I didn't address that. I can see your debating skills are as honed as your software development skills.



  • @The_Assimilator said:

    RARGH
     

    Hey, remember that bit we discussed where you asked if you were an asshole?



  • @blakeyrat said:

    return Value < MinVal ? MinVal : (Value > MaxVal ? MaxVal : Value);

    That's not really a good example, since it's so obviously a clamp. The ternary operator does indeed make bad code much worse, though.



  • @Faxmachinen said:

    @blakeyrat said:

    return Value < MinVal ? MinVal : (Value > MaxVal ? MaxVal : Value);

    That's not really a good example, since it's so obviously a clamp.

    Oh yeah, obviously it's a clamp. (WTF?)

    Anyway, bad example or not, it's certainly an easy-to-find one. (It's actually used as an example of the ternary operator in C# when you Google "ternary operator." So easily accessible to below average coders, who do most of their work via Google and copy&paste.)



  • @blakeyrat said:

    [snipped image]

    That's a good example of how not to use the ternary operator. Some comments help clear things up, but I'd still not recommend it.

    [IMG]http://i.imgur.com/YKZp0.png[/IMG]



  • @Faxmachinen said:

    That's a good example of how not to use the ternary operator. Some comments help clear things up, but I'd still not recommend it.

    Maybe next time define the word you pulled out of your ass before using it, and I won't make fun of you with clamp clip art. Just FYI.


  • Discourse touched me in a no-no place

     @Faxmachinen said:

    Great, now my Unobtanium Sony widescreen CRT is covered in coffee. You fuck. (And for the record, blakey, I knew exactly what he was talking about when he said 'clamp' - it's a common operation in a lot of rendering and other math-heavy areas - I wouldn't say it's immediately obvious what the hell that line of code is doing, though. Nested ternary operators are among the ugliest fucking things you can write)



  • @The_Assimilator said:

    Yes, let's ignore useful operators because they're potentially confusing!
     

    Heh, I found triple-nested tenary operators the other day in some old code, all on one line with few brackets. That was more than a little confusing.

    Right next to a if tree...



  • @blakeyrat said:

    @Faxmachinen said:
    That's a good example of how not to use the ternary operator. Some comments help clear things up, but I'd still not recommend it.

    Maybe next time define the word you pulled out of your ass before using it, and I won't make fun of you with clamp clip art. Just FYI.

    Wait, really? There are computer scientists (software developers, whatever) who don't know of the term "clamp" in the sense of "coercing a value to a certain range"?



  • @toth said:

    @blakeyrat said:
    @Faxmachinen said:
    That's a good example of how not to use the ternary operator. Some comments help clear things up, but I'd still not recommend it.

    Maybe next time define the word you pulled out of your ass before using it, and I won't make fun of you with clamp clip art. Just FYI.

    Wait, really? There are computer scientists (software developers, whatever) who don't know of the term "clamp" in the sense of "coercing a value to a certain range"?

    It must be a regional thing. I've never heard that before in my life. And it's also stupid, considering how an actual clamp works... although I suppose the geeks who use the word "clamp" that way have never actually used a clamp.

    In any case, that definition isn't in the dictionary, so you can't blame me for not knowing it.




  • I don't think the term is too regional, it's certainly used around my Pennsylvaniay zones. Caveat, I've only heard it used with that meaning in the context of voltage control.

    In any case, I feel like chiming in here to say that it really irritates me when language developers and those "best practices" think tanks start getting twitchy because the coder can use languages features that endow them with Turing-compete powers. And I regularly use Java, so that irritates me a lot. The ternary operator has good standing and is included in most all languages of Algol-derived syntax for a reason. The reason is that it's useful.

    language_irritation_points = 3;
    //...
    printf("Writing this statement with an if or useless temp variable would cost me %d irritation %s.\n",
            language_irritation_points,
            language_irritation_points == 1? "point", "points");
    

    In a more extreme and subjective case, let's consider these two equivalent constructs:


    if (foo) {
    if (bar) {
    derp = "foobar";
    } else {
    derp = "foo";
    }
    } else {
    derp = "lol"
    }

    and
    derp = foo
            ? bar
                ? "foobar"
                : "foo"
            : "lol";
    
    To me, the second is far more cleaner, easier on the eyes, and just as trivial to modify. What do you think?



  • @Xyro said:

    To me, the second is far more cleaner, easier on the eyes, and just as trivial to modify. What do you think?

    You already know what I think. The goal of software development isn't to make "clean" code, or code that's "easy on the eyes". Software also isn't made in a vacuum, and therefore it certainly won't be "easier on the eyes" to someone who hasn't been previously exposed to the ternary operator.

    The goal is to make good software.

    Is there any situation, *any* situation, where using the ternary operator results in a better software product than not using it? None I can think of.

    Are there situations where using the ternary operator results in a worse software product? Yes, this thread contains examples.

    QED.



  • @blakeyrat said:

    Is there any situation, any situation, where using the ternary operator results in a better software product than not using it? None I can think of.
     

    You may take issue with this example, but here I go anyway:  the ternary operator (for simple cases at least) can be quick to understand and faster to modify (like Xyro's example of slight differences in text display) than the more verbose if statement.  While it may be confusing and thus cause the introduction of bugs, for some of us (I do internal corporate software) speed of development/altering for changes in business rules is a primary feature for all the clients and webapps I deal with.



  • @locallunatic said:

    You may take issue with this example, but here I go anyway:

    You know, as long as you've actually spent more than 0.5 seconds thinking "how does this help my end-goal", I'm actually ok with whatever bullshit you come up with to justify it. (And it does sound like bullshit-- let's be honest here. But you knew that going in.)

    What I'd really like to combat is the idiots doing things "because it's always been done that way."



  • @Xyro said:

    To me, the second is far more cleaner, easier on the eyes, and just as trivial to modify. What do you think?
     

    Depends on what you're used to.

    I think the second is shit. You also cuddle your } else { statements, which I hate because then the IF and ELSE aren't vertically aligned, and the code becomes more dense. Thus the code is less scannable. If the second is less readable to you, it's because you've adopted a style that is less readable.

    It's also harder to judge an example of things when the variables are nonsense examples. I can't immediately think of real code and real business logic that would make me nest ifs in that way. From what it looks like, both snippets of code should be scrapped and replaced with a more linear version.



  • @blakeyrat said:

    The goal of software development isn't to make "clean" code, or code that's "easy on the eyes". Software also isn't made in a vacuum, and therefore it certainly won't be "easier on the eyes" to someone who hasn't been previously exposed to the ternary operator.

    The goal is to make good software.

    I, and I think I can speak for a lot of monitor-eyed coders out there, would argue that clean code that is easy on the eyes is necessary for good and maintainable software. And while visual aesthetics are subjective, reducing construct cruft is a sure way to keeping your eyes soft. The reverse is also true: ugly and difficult code is almost always produces bad and unmaintainable software.

    Ultimate, the comparative value of if statements vs. ternary operators, or if statements vs. switch statements, or constructors using the "new" keyword vs. constructors hiding behind well-named static methods, or variable names, or class structure, etc; the value all depends on context. Sometimes technique X is better, sometimes Y is better. What you're arguing is that X is *always* better because Y *can* be used incorrectly. By that logic, why are even using Turning-complete languages??



  •  I find it telling that people speak of the ternary operator.  In theory, any function with three arguments (I'm thinking in particular of some of those probability distributions) could be implemented as a ternary operator, and that fact that only the "if-then-else" concept actually gets this treatment suggests that there's something special about it.

    This comes from a background that included a fair amount of APL, where just about every operator, built-in or user-written can be either unary or binary ("monadic" and "dyadic" in their jargon), and sometimes the actual relationship between the two (here I'm thinking of the "circle" ops) can be a little fuzzy.



  • @blakeyrat said:

    You know, as long as you've actually spent more than 0.5 seconds thinking "how does this help my end-goal", I'm actually ok with whatever bullshit you come up with to justify it.
     

    +1

    I am 75% less upset with bullshit if I realize the person has been thinking and is (trying to be) aware of his/her actions. I mean that generally, not just in programming.

    @blakeyrat said:

    And it does sound like bullshit-- let's be honest here.

    +1

    Ternary is faster to change? Dubious. You don't win hours by using a ternary. That unsupported time benefit is lost ten times over as soon as you go for an extra cup of coffee on any given day.

     



  • @dhromed said:

    I can't immediately think of real code and real business logic that would make me nest ifs in that way. From what it looks like, both snippets of code should be scrapped and replaced with a more linear version.

    Here is one I was thinking about when I wrote the nonsense example. Names slightly changed to protect the me.

    /* Rather than bringing in some heavyweight XML monster (as if there's

    • any other kind) to create a document which is nothing more than
    • name-value pairs, we'll write XML the old-fashioned way.
      */
      StringBuilder sb = new StringBuilder(1024)
      .append("<Entry>\n")
      .append("\t<guid>") .append(fileGuid) .append("</guid>\n")
      .append("\t<start-time>") .append(startTime) .append("</start-time>\n")
      .append("\t<return-code>").append(returnCode).append("</return-code>\n")
      .append("\t<message>").append(
      message == null
      ? returnCode == 0
      ? "Successful"
      : "Error"
      : StringEscapeUtils.escapeXml(message))
      .append("</message>\n")
      .append("</Entry>");


  • @Xyro said:

    Ultimate, the comparative value of if statements vs. ternary operators, or if statements vs. switch statements, or constructors using the "new" keyword vs. constructors hiding behind well-named static methods, or variable names, or class structure, etc; the value all depends on context.

    Yes, but my very point here is that I can't think of a single context in which the ternary operator is (practically) superior to the if statement.

    @Xyro said:

    Sometimes technique X is better, sometimes Y is better. What you're arguing is that X is always better because Y can be used incorrectly.

    Not really; I'm arguing that:

    1) Y is not superior to X in any practical way

    2) Y tends to lead to spaghetti-code

    That is to say, something about Y leads to it being used incorrectly-- in the same way it's really easy to incorrectly write PHP, but very difficult to incorrectly write C#. Now, maybe you don't believe in this phenomena, but I happen to.

    @Xyro said:

    By that logic, why are even using Turning-complete languages??

    With the implication that all Turing-complete languages are equivalent in ease-of-use? ... I'm not sure what you're saying here.



  • @blakeyrat said:

    @Xyro said:
    By that logic, why are even using Turning-complete languages??

    With the implication that all Turing-complete languages are equivalent in ease-of-use?

    No, no, he was talking about turning-complete languages, not about Turing-complete ones. Turning-complete languages are ones that are almost-complete at all times, but not quite. Such as PHP.



  • @dhromed said:

    @blakeyrat said:

    And it does sound like bullshit-- let's be honest here.

    +1

    Ternary is faster to change? Dubious. You don't win hours by using a ternary. That unsupported time benefit is lost ten times over as soon as you go for an extra cup of coffee on any given day.

     

    Ok yeah, I should have used an example of where I actually do use it rather than referencing someone else's example to try to explain my opinion.  My bad.  Heres one that is a bit closer to what I actually deal with (using a simpler than average setup, please excuse if this doesn't format right, trying to use tags I see in HTML source to make it look right)

    if (

             (x.SelectedValue == "some string decided byBA") &&

             //clause part 1: if x is this value and

             (y.SelectedValue == "shorthand used in the DB for a status") &&

             //clause part 2: value2 is selected in drop down y and

             (z.Checked ? a.Value.Trim() != "" : b.Value.Trim() != "")

             //clause part 3: if checkbox z is checked then field a cannot be blank, if it is not then field b cannot be

       )

    {

         ...whatever supposed to do in that case...

    }


    Edit: Well, almost got it except for the too long lines.  Comments moved below the line they are commenting.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.