• xorium (unregistered)

    I thought bin VB the underscore at the end of a line means "statement continues on next line", so the fields would not be separated at all.

  • DQ (unregistered) in reply to xorium

    You'reRight.TheyAreJustGlueingEverythingTogether.

  • ichbinkeinroboter (unregistered) in reply to xorium

    correct. _ is line continuation

  • dVeteran (unregistered)

    In early versions of VB.NET the underscore marked a line continuation. And I bet the "d" before each name stands for "delimited", which would mean that each field has a sibling that cares about the output format.

  • KiwiGeek (unregistered) in reply to xorium

    You are correct.

  • (nodebb) in reply to xorium

    Yes it is. You are absolutely correct.

    It should have been obvious because:

    1. The underscores are not in quotes
    2. There is no concatenation operator (+) between each underscore and the next field.
  • Hans (unregistered)

    And String.Join has first the separator, then the list of values to join ...

  • Yazeran (unregistered) in reply to jeremypnet

    Which means that the lower case 'd' (mistaken for misused hungarian notation') is the only thing you can use in the split later on.....

    Just hope that none of the identifiers themselves has a lower case d in them (was too lazy to check)

    Yazeran

  • netmunky (unregistered)

    possibly 'd' denotes byte, while 'dw' denotes word? if that's the case, this may be a scenario of concatenating strings of 2 character and 4 character hex strings that are later decoded one (or two) bytes at a time.

  • King (unregistered)

    This might be a way to prepare for a search for a searchstring in all fields, instead of search each and every field separately.

  • I must be doing it wrong then (unregistered)

    Searching (instr ?) for "dtype" will get you dTypeEE, dTypeJJ, dTypeKK, and dTypeTT and not dBearingType or dTerminalBoxType etc. Why the "d" "delimiter"? Why not - the brighter the mind the dimmer it gets on simple things. As to what is done with the "result", I dunno. It also looks like an "evolving" list - got a new "part description" then just add (or concatentace) to the end.

  • I must be doing it wrong then (unregistered) in reply to netmunky

    Because there is already a dFlanges?. But that don't explan the diferences between them or account for the apparent fact that there or no duplicates for the other two "dw"s

  • ZZartin (unregistered)

    I doubt they're unpacking it, based on the field name PartSearchDescription they're probably just doing a text search of the concatenated field.

  • Duston (unregistered)

    "Searching (instr ?) for "dtype" will get you. . . " Why would you instr() for a variable name in the string that's created?

    Perhaps as someone suggested the "d" prefix means it's delimited so perhaps the actual delimiter is defined elsewhere (extra points for it being in an XML file) and added outside of this statement. That way the delimiter can be easier (if not dynamically) be changed. That said, this is awful.

  • (nodebb)

    Ah, good days, before there were dictionaries and LINQ :-)

  • Sauron (unregistered)

    written by a slew of mechanical engineers

    Let me guess, it probably went like this:

    New manager: "Whaddya mean, we need software engineers? You guys can build rockets, and you're afraid of writing code? Don't tell me writing code is rocket science!"

    Mechanical engineers: "We don't build rockets, this is a car manufacturing company."

    New manager: "Whatever! I write code in Excel all day long, it ain't that hard! You guys are paid more than enough to write code!"

    Mechanical engineers: "No, we're not."

    New manager: "That's not my problem. Write that f***ing code!"

  • (nodebb) in reply to Yazeran

    Which means that the lower case 'd' (mistaken for misused hungarian notation') is the only thing you can use in the split later on.....

    Is this another example of the mere presence of VB code causing a brain to seize up? Remy made the mistake of assuming that the underscores would be included in the string despite the absence of quote around them, then you make the mistake of assuming that somehow the name of the variable rather than its value would be in the resultant string.

    Both of these are errors that neither of you would normally make in another context. I support some VB.Net code at work and I see a similar pattern happen there all the time too - people just assume VB was written by idiots, so they imagine more idiocy into the code than is actually there. I also get a lot of people questioning "can VB do that" when they are talking about simple things like function overloading, or even sometimes when referring to a library behavior.

    Then I have to explain to highly-paid individuals that yes, String.IsNullOrWhiteSpace does the same thing in VB and C#.

  • Old Graybeard (unregistered)

    The names throw me a bit, and it's definitely not an efficient way to do it, but I would bet those are pre-formatted strings and this is building a fixed-width record to send to a mainframe or the like. Even without a mainframe fixed-width has the benefits of avoiding all these delimiter quoting/escaping situations being commented on; the data could truly be anything as long as it's a known size. The only major issues are ASCII-mode FTP which can change line breaks, parsers that split the file on line breaks (if there are line breaks embedded in any field), and the inevitable need to change the size of a field.

  • Duke of New York (unregistered)

    "d" stands data or, alternately, the appropriate German article.

  • mgnoonan (unregistered) in reply to Old Graybeard

    I would expect to see padding logic if it was a fixed width output, unless the data is gauranteed to be the same length every time. I think the variable name gives it away, this is just field value concatenation so they can do a quick "search" using Instr().

  • (nodebb)

    I strongly suspect this is being done for compatibility with some old system, the only WTF being the continued existence of said old system.

  • Your Name (unregistered)

    From the name of the variable it sounds like the source string to use when searching for key words. A simple contains on that one string will make it show up in a filter list, instead of checking every single field.

  • FTB (unregistered)

    WTF???

    Wouldn't the underscores be in quotes if they were for string concatenation...?

  • Worf (unregistered)

    I bet it started as "decimal" and then the "maintainers" just saw that this string had lots of "d" things so they thought their code needed to have "d" named variables.

    And that's how coding non-standards get passed on and on and on....

  • jimbobmcgee (unregistered)

    Nowhere near enough context here to know quite how bad this is. It is entirely possible that this isn't a string, but the world's worst bitwise-flags enum. I see they've exceeded 64 items, so it isn't going in a ulong any more, and so I reckon d is double or decimal (because of the higher maximum value).

    I expect there's accompanying SQL which is far more interesting: perhaps a nice big dynamically-generated block, with a whole bunch of...

    IF (@part_search_desc & 1) = 1 SET @q = @q + N' OR c_frame_type LIKE @search ';
IF (@part_search_desc & 2) = 2 SET @q = @q + N' OR c_frame_size LIKE @search ';
IF (@part_search_desc & 4) = 4 SET @q = @q + N' OR c_syzd LIKE @search ';
...
EXEC sp_executesql @q, '@search nvarchar(max)', @search_str;

    If that is case, it's still painful (and I wonder if anyone actually tested adding beyond the 63rd item, because I'm not sure bitwise ops work on a SQL FLOAT).

    Of course, Occam's razor suggests that this is probably populating a string though: one of those everything fields that makes up the body of a page describing a part. I expect most of the terms are empty, and what was once supposed to be premium sales content for your parts catalog is now just a splooge of whatever specs you have saved in the database.

    But if that is the case, then I'd be more concerned about the use of + instead of & (although I'd rather see a StringBuilder)...

  • Anon (unregistered)

    Looks like they’re just throwing everything into a single string for text search purposes. Not sure where the points about concatenating by “_” or unpacking it afterwards come from. Is this the first time that TRWTF is the criticism itself and not the code?

  • Craig (unregistered) in reply to dVeteran

    The underscore still means line continuation, but the compiler has gotten a lot smarter about inferring it in places where line continuation is unambiguous. There remain cases where the explicit continuation is necessary. These days, you can type it in if in doubt and let the text editor remove it.

Leave a comment on “Scoring the Concatenation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article