• (cs) in reply to da Doctah
    da Doctah:
    Coyne:
    "Reynard thought about educating the lead programmer on normalized data."

    I used to think there were two categories: normalized data, and not.

    But I'd guess this falls in a whole other category: Abnormalized data.

    Have you heard the Boyce of Codd?

    Sure. Not sure I fully understand all the implications of that one.

    But today's WTF violates some of the lower rules. Such as 3NF, which it completely trashes; and pretty much trashes in the worst possible way. And, probably 2NF, depending on exactly what is in the attributes.

  • (cs)

    Is this set of "snippets" the programming equivalent of Frenglish?

  • qbolec (unregistered)

    I see no advantage in using tabs, or pipes, or ascii 4 or ascii 11 as delimiters. It introduces the same problems, equaly easy to reproduce, but more rare in real world, which means that they can bite you in the ass years after release.

    What we use here as delimiter, is \xFF, which at least never occurs in properly crafted UTF-8 strings.

  • (cs) in reply to Inigo Montoya
    Inigo Montoya:
    I am the submitter and I know something you don't know. I am not left-handed

    CHOP! You are now.

  • neminem (unregistered) in reply to qbolec
    qbolec:
    I see no advantage in using tabs, or pipes, or ascii 4 or ascii 11 as delimiters.
    If you know where your input is coming from, and you know for 100% sure that there is at least one keyboard-friendly, human-readable character that will never be in any of the fields in your input, then tab-delimiting files makes perfect sense to me: they're easy to read and understand, and easy to create or edit test files if you ever need to. Tab is a particularly good candidate because a. it's not that common within single strings, and b. it does a particularly good job of separating strings visually.

    If the strings going into the file come directly from the user, though, xml is probably a better idea, though, since the user might easily enough decide it'd be a great idea to stick a tab in a string. (But only if it's coming directly from the user - if it's coming from the user but you have control over how, you could easily enough strip tabs, convert them to spaces, or just not allow them to have gotten into the control the user is entering strings into in the first place.)

  • Ozzie (unregistered)
    $oRecSet.movefrist();

    Did anyone else notice the "frist" or was that just me?

  • Simon (unregistered) in reply to ubersoldat
    ubersoldat:
    ...any sane Perl developer...

    And this being April Fools Day, I expect to hear any moment that one has been sighted.

  • Norman Diamond (unregistered) in reply to qbolec
    qbolec:
    Actually: for (int i = curItemArr.length; i >= 0; i++) in C++ finishes as soon as there is overflow, but unfortunatelly does not visit any valid index.
    Well, unless it segfaults before that, but that doesn't matter because it didn't start where you thought it did.
    qbolec:
    On the other hand this pattern: for (unsigned int i = $curItemArr.length; i-- <= curItemArr.length;) even though looks strange, is quite correct for unsigned integers when you want to iterate backwards.
    That doesn't work either, because it didn't start where you thought it did.
    Lorne Kates:
    $oRecSet.movefrist();
    You see that? I even viewed the source to see if a comment explained why that code was coloured as a comment even though it was coded as code, but no explanation was visible and it can't be counterfeited by anyone because the green pigment came from Canada. Frist entries don't appear frist. You could be anywhere in the array. Or maybe not even in the array. Segfault!
  • Norman Diamond (unregistered) in reply to AC
    AC:
    Ifthere'sadelimiterdumberthatacomma,it'saspace.
    そうですね。日本語のほうが能率が良いです。(You'reright.Japaneseismoreefficient.)

    By the way, dmr once posted in Usenet news the assertion "Whitespace is your friend." I retorted that if he really believed that, he never would have changed the compound assignment operators from syntax like =- to -=. Sure =- was ambiguous for human readers who forgot to do greedy lexing. But if dmr really believed that whitespace was your friend, he would have left the operator that way so programmers would have to put whitespace after it, instead of changing it to -= to allow omission of whitespace.

  • KeroHazel (unregistered)

    "He was able to replace all the CSV with a bit of XML, and all was right in the world."

    Let me guess, he crammed the XML into the FreeText field?

  • just me (unregistered) in reply to Norman Diamond
    Norman Diamond:
    qbolec:
    On the other hand this pattern: for (unsigned int i = $curItemArr.length; i-- <= curItemArr.length;) even though looks strange, is quite correct for unsigned integers when you want to iterate backwards.
    That doesn't work either, because it didn't start where you thought it did.
    Actually it does not stop where you thought it would (the loop is executed once after decrementing zero).

    In these cases I'd recommend using the goes-towards operator (in C because who in his right mind would write PHP):

    for (int i = currItemArr.length; i --> 0; )
  • Altreus (unregistered) in reply to APerlo

    It's Perl not PERL kthx

  • Buddy (unregistered)

    Okay, I'm the original submitter. It was written in Haskell in negative ten lines, without any variables or memory, and ran in the past so that I had the results beforehand. Also, I wrote it in the middle of a lake during a raging sleet storm with both hands and feet hogtied. And without electricity.

  • Paul Neumann (unregistered) in reply to Buddy
    Buddy:
    Okay, I'm the original submitter. It was written in Haskell in negative ten lines, without any variables or memory, and ran in the past so that I had the results beforehand. Also, I wrote it in the middle of a lake during a raging sleet storm with both hands and feet hogtied. And without electricity.
    A little late to the party, sparqy
  • AC (unregistered) in reply to Daniel
    Daniel:
    That's a lovely combination of PHP and VBScript!

    Also, it doesn't seem to really be CSV, just a list of IDs separated by commas. CSV implies you have tabular-ish data, with structure (a fixed number of fields) and possibly a variable number of records. Neither is the case here.

    Absolutely correct.

  • qbolec (unregistered) in reply to just me
    just me:
    In these cases I'd recommend using the goes-towards operator (in C because who in his right mind would write PHP): 
    for (int i = currItemArr.length; i --> 0; )

    I love it.

  • (cs)

    Is this $oRecSet.EOF common in languages that Visual studio is supporting? I am thinking it is more in common with Unix based languages.

  • Ziggyfish (unregistered)

    I think the biggest WTF is the language.

    $curItemArr = split($_SESSION["CustomerValues"], ",");

    is PHP, but split was deprecated in 5.3.0, and the parameters are in the wrong order. It should be

    $curItemArr = explode(',', $_SESSION["CustomerValues"]);

    The code below isn't any better.

    $oRecSet = DB.Execute("SELECT ValueName FROM Values WHERE ValueType='Customer' ORDER BY ValueName ");

...

while (! $oRecSet.eof) 

...

for ($i = $curItemArr.length; $i >= 0; $i++)

...

$oRecSet.movenext();

...

$oRecSet2 = DB.Execute(sSQL);

...

while (! $oRecSet2.eof) 

...

if (idStr <> "") 

...

if (idStr <> "")

    PHP doesn't use the . for object access, and PHP treats all terms without a $ before it as a constant, so for example DB needs to be $DB.

    if ($curItemArr($i) = $oRecSet["ValueName"])

    To access arrays in PHP, you use [], not (). Also $oRecSet is a object so $oRecSet["ValueName"] needs to be $oRecSet->ValueName.

    $curItemSQLNoExt += "'" + replace($curItemArr[x], "'", "''") & "',"

...

sSQL = "select ValueID from Values where ValueType='Customer' AND ValueName in (" + mid($curItemSQLNoExt, 1, len($curItemSQLNoExt)-1) + ") "

...

idStr = idStr & $oRecSet2("ValueID") + " "

...

Response.Write( "<input type='checkbox' name='UserValue' value='" + $oRecSet["ValueName"] + "' checked />" + $$oRecSet["ValueName"]);

...

Response.Write("<input type='checkbox' name='UserValue' value='" + $oRecSet["ValueID"] + "' />" + $$oRecSet["ValueName"]);

    firstly its missing a semi-colon, secondly string concatenation is done using the . operator, also & is not an string concatenation operator as well.

    idStr = "";

...

idStr = mid(idStr, 1,len(idStr) - 1);

...

if (FreeTextValue = "")

    this is just simply invalid as idStr is seen as a constant.

    So lets see what code is actually valid..

    {{{}}}{{}{}}{}{{}{}}{}

    Thats some interesting code. So is the WTF, the fact that Lorne Kates didn't really look at the code?

Leave a comment on “Tough to Separate”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article