• Vault_Dweller (unregistered)

    Ok, so I read the comments like the title suggested, and I don't see the WTF

  • Prime Mover (unregistered)

    Smacks to me of autogenerated code from an XML parser program of some kind.

    Nothing to see here, move along now.

  • Mark (unregistered)

    Ok, the comments are useless filler (and I didn't actually see one that didn't match the following record name).

    The 04_14 code doesn't have to be a problem either. Sometimes codes like that are just part of the business domain. I've worked on systems where we discussed Category 05 or Category 09, and everybody knows what that means, from the analyst down to the QA who started last week. If that's the business language, it really does make sense to stick with it.

  • Industrial Automation Engineer (unregistered)

    It's an F nonetheless. The "End Sub" line was not commented.

  • Industrial Automation Engineer (unregistered)

    And why is the title "read the comments" when they are all held for moderation?

  • Steve The Cynic (unregistered) in reply to Vault_Dweller

    Yes, it's really me - the network here is broken, so I don't have my login info.

    Ok, so I read the comments like the title suggested, and I don't see the WTF

    I hope I don't have to reiterate the point that comments should explain why rather than what...

  • Tim Ward (unregistered)

    Generated, not human written, surely? I hope?? Particularly with the hard coded field lengths in there???

  • I Read The Comments (unregistered) in reply to Tim Ward

    Re-check the "Name" case, so....

  • Tinkle (unregistered)

    Got to love the HireDate expressly handled by the custom string formatter.

  • Dave (unregistered)

    "BuildActuarial04_14Row" sounds to me more like 'Actuarial04' is the thing being built, and it has 14 rows. Which suggests an enticing set of WTFs somewhere else.

  • (nodebb)

    Comments need comments, too. Also, where are the names of the authors and dates in each comment? Not good.

  • (nodebb) in reply to Vault_Dweller 
    // The following explains that comments are not needed if the code is self explanatory.

    If it's obvious from reading the code what it is doing, you don't need a comment explaining what it is doing.

  • Morten Grøtan (unregistered)

    By Googling, it seems that "actuarial" deals with pensions and the like, which fits nicely with some of the field names. And according to "http://www.actuarialstandardsboard.org/wp-content/uploads/2013/12/asop004_125.pdf", there's a thing called "Actuarial Standard of Practice No. 4", so probably that explains the "04" part at least. Then maybe "14" represents row 14 in some report.

  • Sole Purpose Of Visit (unregistered) in reply to Morten Grøtan

    I'd imagine it's more likely to represent the version of the standard, or the date.

    Irrespective of which, Remy may be reading too much into the VB.Net "As" here. There may be no polymorphism involved at all. And since it's VB.Net, it may well be one of a select few PODs that really cannot usefully be genericised (I'm thinking TC45s, TC49s, TC54s here from the credit card processing world).

    And frankly I don't care if every line is commented. I don't care if no lines are commented. I don't even care about the distinction between "comment what" and "comment why." All I want is (a) a guarantee that this code "works" (for some version of "works") and a "guideline" for how to fix it if not (for some version of "guideline").

    Not remotely a WTF in any way, shape or form, therefore.

  • MaxiTB (unregistered)

    VisualBasic was designed to be the "programming" language for manager without any knowledge of best practices. And it really succeeded in that regard, similar to how sequel is still around even though it is a very sub optimal way to write data queries. As long as there's the general mindset around that you can cut out developers in the future, I guess we developers have to live with quality code like that :-)

  • markm (unregistered) in reply to Jeremy Pereira

    Pointless commenting is taught in programming classes. The teacher correctly wants to emphasize writing comments, but the assignments are so simple that there isn't anything to say that's not obvious in the code. So you wind up with lines like "a = b; // Set a to b" just to get some comment in there.

    Also, "what's obvious in the code" depends on ones experience and knowledge of the language. There was a time when the code in the OP was not obvious to you. But then you got through the first couple of weeks of your first programming class, and assuming you were actually learning to program, it became obvious. And the teacher still wanted a comment for every line... This builds bad habits.

  • markm (unregistered) in reply to Mark

    "I've worked on systems where we discussed Category 05 or Category 09, and everybody knows what that means, from the analyst down to the QA who started last week. If that's the business language, it really does make sense to stick with it."

    The company you wrote this for gets bought out by another company, then merged with a third and fourth. The company-specific jargon changes. Then 15 years from now, they open an office in Ulaanbaatar and some poor guy has to figure out how to change the software to support the Mongolian language and tax code. And those outdated codes make less sense than the specs written in Mongolian...

  • The Actuary (unregistered)

    Who knows what mysteries lie in the heart of the code???

    The Actuary Knows!!!!!!!!!!!!

  • ooOOooGa (unregistered) in reply to Dave

    Or it is the 14th version of this function to create the 'Actuarial04' data. Which is an entire skyscraper of WTF to consider.

  • Oh so strict (unregistered)
    It needed to work the first try or you might be waiting a whole day before you could try again.

    Reminds me of Google interviews, except substitute "6 months to a year" for "day".

  • Who needs source code control? (unregistered)

    I was once at a place that had a rule that every change made to the code had to have a comment with the previous version of the code commented out. This led to lots and lots of comments clogging up the code.

    I tried to point out that having a source code control system made that unnecessary, but I got nowhere. Of course, this made any non-trivial change to the code practically impossible.

  • Loren Pechtel (unregistered)

    I call this sort of thing school comments. The garbage that "teachers" demand for documentation. By now I consider comments to be a mild code smell, something to be refactored out if feasible. Occasionally you need to document something unusual about the situation but in your code you can almost always do better with good naming.

  • wolferitza (unregistered)

    I've done this too - you get a spec with a list of fields or something that need to be translated into code. So paste the list in the code, comment it, copy paste the relevant code under each field, replace the field name... and forget (or not care enough) to delete the comments

  • Prime Mover (unregistered) in reply to Jeremy Pereira

    "If it's obvious from reading the code what it is doing, you don't need a comment explaining what it is doing."

    What comments are actually for is to explain why it's doing it and how it's doing it.

    At the top of this file I would expect to find something like:

    'Autogenerated by (xyz tool) from a (standard industry database interface) for (such-and-such project).
'Used by (so-and-so utility) to transfer (this and that data) to database.

    If your programming trainer didn't teach you that, get your money back.

  • Argle (unregistered)

    Time to talk about signal-to-noise ratios.

Leave a comment on “Read the Comments”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article