• bvs23bkv33 (unregistered)

    commentchar[0] = f && commentchar[1] = r && commentchar[2] = i && commentchar[3] = s && commentchar[4] = t

  • Quite (unregistered)

    As nasty little schoolboys, my contemporaries and I used to pronounce the word as "tit ration", of course.

  • Catzilla (unregistered)

    Lex, where are you?

  • (nodebb) in reply to bvs23bkv33

    No usage of the venerable for-if-pattern?

  • What? I'm not giving you my name. (unregistered)

    Probably a chemist wrote it. I wish I was as good at chemistry as that chemist is a coding.

  • Oliver Jones (google)

    My first job was helping scientists debug their code. This is a blast from the past. There's lots of stuff like this kicking around lab computers.

  • BOFH (unregistered)

    At least he is specifying which characters to allow and not which characters to reject, that's a good pattern. If only he had known about m/^[A-Za-z,.()*/+-]+$/ though.

  • BOFH (unregistered)

    I had a backslash in there to escape the /, but apparently it got filtered out by the form's input validator. Oh, the irony!

  • (nodebb) in reply to BOFH

    You have n problems. You solve k of them using regexes. Now you have n+k problems.

  • Jezor (unregistered)

    "titem"

    childish chuckle

  • Kashim (unregistered)

    As we continuously have to go over at my work: Most Scientists and Engineers can probably learn to write code. Not all of them can learn to write good code, and far fewer of them even try. My job security as a legit Software Engineer is that anyone can write code, but it takes one of us to write code that anyone else will ever want to look at.

  • Ulysses (unregistered)

    It looks more like a Qwertytration.

  • (nodebb)

    Parsing is hard. And I don't know what this code does, but it's not parsing.

  • Sole Purpose of Visit (unregistered)

    Well, it doesn't actually "solve" the equation, does it? (Or indeed anything, ho ho.) Nor, despite the assertion at the start, does it "parse" anything in any meaningful sense, since what little tokenization it does is immediately thrown away on a character-by-character basis.

    What it appears to be doing (and I'm going out on a limb here) is to filter non-accepted characters out (this is not necessarily a good thing), leave any numerical expression as it is, and match the remaining 'variable' against a list of titem. If no match is found, it throws the non-matched variable away (genius!). Otherwise it appends the variable name to the output string. I particularly like that the only use of C++ is to use the overloaded equality operator for String ... no iterators, no containers, no nothing.

    Well, something like that, anyway. It's doing just about everything wrong, but the least of its problems is the qwerty stuff. This is trivially easy to refactor, and of course management would be delighted for you to do so, except who am I kidding, your ass would be grass, you are a code monkey and not allowed to touch the work of a professional scientist, and once refactored you can actually ask the dimwit what they meant the thing to do.

    I'd go so far as to assert that the only intelligiible part of this whole routine is, in fact, the qwerty stuff. But that might just be me.

  • foxyshadis (unregistered)

    Screw that. I haven't looked at code in 80 columns in at least two decades, and I probably never will again. Let this 80 column fetish go, unless you're still coding on IBM dumb terminals somewhere. My monitor can do 250, which is perfect for 120 side by side or a wide view with no overflow at all.

  • Sole Purpose of Visit (unregistered)

    Guessing even more wildly, I infer that, in the general case, this function takes an input string and returns that input string (as an axis label) ... possibly with whitespace striped out, I wouldn't know, my eyes went a little blurry. At least it doesn't incur the risk of a buffer overflow (i forgot to mention the String + operator overload).

    Now, the thing is, this is uuseless. It's even more useless than it sounds. It's a practical certainty that some earlier function has, in fact, parsed this string properly, complete with a test against titem variable names. Because, otherwise, how would you solve the equation in the first place? So this boils down to a concatenation of stringified, previously parsed, terms. Very useful, that. And only ever so slightly brittle.

    Of course, this parsing and solving might be done in a third-party library ... I hope so, because I wouldn't trust the author to get it right himself. So either the TPL handles error detection properly, in which case all of this checking nonsense is irrelevant, or else it doesn't, in which case I would be interested to see its interpretation of "a + misspelt_nonexistent_variable * b" might be.

    There's definitely a WTF here, but I think it's not the one shown, as it were.

  • Sole Purpose of Visit (unregistered)

    I do have a proposal to ameliorate this WTF in future, however. I suggest that the author of the code be sent on a remedial course of titration.

    "Here's a beaker half-full of concentrated hydrochloric acid and a pipette. Suck hard -- just like your code ..."

  • Ulli (unregistered)

    for (int i = 0; strlen(yvalue) + 1; ++i) ???

  • Barry Margolin (google)

    Anyone notice the real WTF in the for-loop header?

    for (int i = 0; strlen(yvalue) + 1; ++i)

    It's not comparing anything to strlen(yvalue)+1, so it's an infinite loop, only ending when it executes one of the break statements.

  • siciac (unregistered) in reply to foxyshadis

    My monitor can do 250, which is perfect for 120 side by side or a wide view with no overflow at all.

    Okay, so that's your workstation, and that seems to be a common size, but people do work on laptops. And a 12" laptop is small enough to be usable even in economy class.

    The problem with long lines is they're optimizing for the writer, not the reader. They're easy to write because you save the effort of indenting them.

    But they are hard to read because of how eyes work. If you are trying to understand an expression, you have to read the different parts of it and link them together. It's not like natural language, you can't just read it right to left. (Even with natural language, books never have text set that wide.)

    The reader has to build a tree in their mind of the components, and it's a demanding mechanical task for the human eye to scan left and right to find those components; it's much easier to move around a reasonably circular area. That's why control flow, especially, is always indented (giving distinctive visual clues) and very long algorithms have the same problem.

    (120 characters is fine in many styles as we're often losing 40 characters or so to hanging indents. And, of course, there is a gain in optimizing for the writer.)

  • (nodebb) in reply to Barry Margolin

    There was another case recently of a code block that appeared to be missing some characters including a less than sign. Perhaps the same bug has struck TDWTF again?

  • Sole Purpose of Visit (unregistered) in reply to Barry Margolin

    I did notice the pointless strlen+1, which either hits a null (which "yvalue" will be filtered out, obviously) or else falls off a cliff because there is no null and consequently strlen() will not work. I didn't notice that, though. (Props.)

    It's an interesting mis-specification at the root of the C language though, isn't it? Properly speaking, the middle clause of a for-loop doesn't need to be an expression. In fact, it shouldn't be an expression, because there is no RHS to collect the result of the expression. It's interesting, because if the middle clause were specified as a statement (not an uncommon thing in C), the compiler would rightly complain.

    Once again, I think the code is relying on a previous TPL routine detecting such an error. Not that I can defend it, of course.

    Quite the tidy collection of random WTFs we have here. Here's another proposition. Why not let Domain Experts (people who swallow hydrochloric acid for a living) do what Domain Experts do, and let software folk save them hours and days and even possibly weeks of getting things wrong, by getting things right?

    It's a modest proposal. It will never catch on. Now, if you excuse me, I'm off to eat some Irish babies.

  • Sole Purpose of Visit (unregistered)

    (LHS, sorry)

  • siciac (unregistered)

    Properly speaking, the middle clause of a for-loop doesn't need to be an expression. In fact, it shouldn't be an expression

    O_o

    What should go inside if(...)?

  • head-desk (unregistered)

    To everyone other than Catzilla: this is generated code. TRWTF might be that the original developer renamed the function that the tool generated, but that's about it.

  • Sole Purpose of Visit (unregistered) in reply to siciac

    Badly and incorrectly expressed (or stated); my apologies. Yes, I didn't mean "statement," despire what I thought; even strlen(x) etc is a boolean expression, but only because C and variants coerce zero to false and anything else to true.

    So, what I think I am principally complaining about, re C, is that the middle clause is not forced to be a literal boolean expression. Which would probably catch a very large number of inadvertent bugs.

    Then again, I am still a fan of BCPL's version of true/false, which is 11111... for false (basically -1) and 0 for true, and everything else can go hang. But if your language demands a boolean expression as part of a built-in syntactic construct, you really ought to insist on the result of the expression being a boolean.

    One small problem here, of course, is that C doesn't actually feature a boolean type. (Pre C99: not sure about the exact semantics now.) But I feel a respectable compiler should at least warn you when you do something obviously unintentional like this.

  • Neil (unregistered)

    The real WTF is that Purdue don't seem to have updated their web site since the mid 90s. I'm surprised there aren't any 'Designed for Internet Explorer' icons, or dancing bears.

  • Bubba (unregistered)

    Some poo came out

  • (nodebb) in reply to Sole Purpose of Visit

    But I feel a respectable compiler should at least warn you when you do something obviously unintentional like this.

    Not a C compiler. Nothing is "obviously unintentional" in C. Especially not assignments of which the result is to be interpreted as a bool.

  • comments.Count.ToString + "th" (unregistered)

    While titration is indeed frustrating, Flash-columns are way worse. They are the reason I quit being a chemist and became a coder.

  • (nodebb) in reply to siciac

    If you are trying to understand an expression, you have to read the different parts of it and link them together. It's not like natural language, you can't just read it right to left.

    Go away until you've learned about APL. APL expressions are, indeed, interpreted strictly right-to-left (with parentheses to override that where needed). (3 x 4 + 7 (33) is not equal to 4 x 3 + 7 (40) nor to 7 + 3 x 4 (19) in APL.)

  • (nodebb) in reply to Sole Purpose of Visit

    which is 11111... for false (basically -1)

    At the time (and afterwards) when BCPL was a thing, there were computers where the all-ones bit pattern is zero. OK, negative, but zero all the same. It's called "one's complement", and that representation is just part of why signed-arithmetic overflow in C is considered UB.

  • (nodebb)

    It occurs to me, also, that strlen(blahblah)+1 as a condition (in an if or a while or the middle expression of a for) should generate a "condition is always true" warning because strlen returns a size_t, that is, an unsigned type, whose value cannot be -1, and therefore the expression can NEVER be zero.

  • Sole Purpose of Visit (unregistered) in reply to Steve_The_Cynic

    See? BCPL 4 T Winz! Told you so.

  • Sole Purpose of Visit (unregistered) in reply to Steve_The_Cynic

    This is a site for smart young things.

    I did not feel the compulsion to confuse them by mentioning one's complement. Although I have a hazy memory of Martin Richards boasting about having implemented a BCPL compiler on that "architecture."

    I wonder if he still insisted on a bit-bucket full of 1s as "false?"

    It would of course be a horror when it comes to interoperability or networking or even binary compatibility. But that was then, and this is now.

  • Sole Purpose of Visit (unregistered) in reply to Steve_The_Cynic

    There's also natural languages that are not Hamitic or Semitic. I may have missed something here, but in general you read them left to right.

    Of course, there's also boustrophedism and the ever popular Early Period Clerical Chinese, but let's just leave those to one side for a moment.

  • Bonko (unregistered)

    Reading down the left column: E U A G L ... language!

    Second column: R I S H ... Irish girl!

  • (nodebb) in reply to Barry Margolin

    so it's an infinite loop, only ending when it executes one of the break statements

    It'll definitely break at some point on any finite string; the NUL string terminator will catch it if nothing else. The code is just awful, not outright dangerous (or at least not in this respect).

  • goerch (unregistered)

    Looks like a yacc appendix.

Leave a comment on “Titration Frustration”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article