• Derp (unregistered)

    WTF(rist)???

  • Classic (unregistered)

    A real lack of comments in this article.

  • regaito (unregistered)

    I actually appreciate the thorough explanation but maybe I am just weird...

  • (nodebb)

    This is the sort of thing for which comments are for. No amount of naming of methods would capture the information as usefully.

  • WTFery (unregistered)

    Comments are more idiotic than the code. // Plz ignore my 2 pages of bullshit

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    A few paragraph breaks would have been helpful. Wall-O-Text(tm) is a less than effective way to get ideas across. I've written such comment essays before, and it's a lot more readable when you can skim first lines of paragraphs to get a general idea of what is being discussed.

  • LawrenceW (unregistered)

    Code can never be so clearly written that comments are not, at least, a good idea. Knowing what the programmer did isn't enough. We most often need to know why they did it and what was the objective.

  • Unregistered (unregistered)

    I'm glad I can leave a comment to this comments.

  • (nodebb)

    Indeed. The code says the how, but only comments can say the why.

  • Guest (unregistered)

    This is the opposite of a WTF. When there is a weird thing in the code, the best possible thing to be next to it is a lengthy discussion of what problem they were trying to solve, what other solutions were considered and discarded, and an explanation of the downsides and gotchas of the solution that was chosen. This person should put this comment on their resume, I would hire them!

  • SysKoll (unregistered)

    This comment could be more readable, but it packs an excellent analysis of the underlying reason for an apparently senseless code. So kudos++.

    TRWTF is the series of bugs that allowed this situation to develop. http://html-agility-pack.net is apparently a transform tools that silently corrupt data. Dear developers of that tool, you just achieved eternal glory.

  • Primary Key (unregistered)

    Is it just me but isn't the need to mention Frist as first post bloody annoying? Wouldn't this site be improved by basically deleting the Frist entries? Or can those bozos be banned or something? Or at least get a course in either writing correctly, or getting some self-esteem?

    Just my two cents.

  • guest (unregistered)

    I only come here for Frist memes

  • Guess-the-guest (unregistered) in reply to LawrenceW

    And if I'm diving into your code to fix a bug some time in the future, your code tells me what you did.

    Your comments should tell me what you meant to do, and ideally why.

  • jmm (unregistered)

    And they say that developers don't like to write documentation!

  • Not Frist (unregistered)

    Fifftennth!!!

  • TheCPUWizard (unregistered)

    The provided information is useful (or at least appears to be, so we will go with that)...but I argue that inline comments are NOT the place for any of it. Proper ALM artifacts [Stories, PBIs, Tasks, Bugs, Issues] all linked together is significantly more effective. As a trivial example how many of those points would be known to people who never open that file? [Rhetorical, the answer is ZERO]. But if they items are surfaced on Backlogs, Boards, Dashboards there is at least a chance they will be remediated.

  • Charles Wood (github)

    ...until your organization migrates to new ALM software...

  • TheCPUWizard (unregistered) in reply to Charles Wood

    Charles Wood - IT can be a problem if people are not smart. But that describes just about everything in life. I have been dealing with ALM tooling for nearly 20 years [longer if you count the days before the term was coined]. With proper planning and utilization it should never be a real consideration.

  • not a robot (unregistered)

    tventifrist!

  • Quite (unregistered)

    Well yes, there is a WTF, but the comments aren't it.

  • Derp (unregistered) in reply to Primary Key

    You're just mad that someone else got there frist.

  • Tim (unregistered) in reply to TheCPUWizard

    in my experience any codebase worth it's salt will outlive many changes of tools, processes, owning companies etc. etc. A comment in the code is much more likely to be found by the person trying to track down a problem than if that was in a document or other external repository somewhere

  • Ext3h (unregistered)

    Well, commenting that is anything but a WTF. You wouldn't believe that's necessary at all without the background information.

    The use of the read/writer lock for that purpose is though, and so is the atomic. Could have been smarter, something like this:

    static unsigned int contention = 0; static unsigned int currentVersion = 0; static mutex m; static condition_variable cv;

    wrapper (..., unsigned int targtVersion) { lock l(m); cv.wait(l, [&contention, &currentVersion, targetVersion] () { return currentVersion == targetVersion || contention == 0; }; currentVersion = targetVersion; contention++; l.unlock(); ... // Do work l.lock(); contention; l.unlock(); cv.notify_all(); }

    And there you had your nice and simple "multi value lock".

  • Ext3h (unregistered)

    Or not, because this stupid comment field is guaranteed to screw up any code....

    static unsigned int contention = 0;
static unsigned int currentVersion = 0;
static mutex m;
static condition_variable cv;
wrapper (..., unsigned int targtVersion) {
  lock l(m);
  cv.wait(l, [&contention, &currentVersion, targetVersion] () {
    return currentVersion == targetVersion || contention == 0;
  };
  currentVersion = targetVersion;
  contention++;
  l.unlock();
  DOWORK();
  l.lock();
  contention--;
  l.unlock();
  cv.notify_all();
}
  • Mistakes in an article about mistakes (unregistered) in reply to Primary Key

    I heartily agree.

  • Hannes (unregistered) in reply to Guess-the-guest

    Ideally, comments should do that. But I've run accross comments like

    //Setting filter to .txt openFileDialog1.Filter = "csv files (.csv)|.csv";

    And I'm left there wondering if the code is wrong or the comment.

  • Hannes (unregistered) in reply to Hannes

    Stupid me forgot the code-tag. :( That should be 2 lines of code, not only 1.

  • Paula Bean (unregistered) in reply to Primary Key

    Frist posts are brillant.

  • mth (unregistered)

    In general, I think documenting the need for workaround is a good thing. in this particular case I'm wondering though if working around the problem was the best idea: HtmlAgilityPack is an open source library and it might have taken less effort to fix the bug there than to work around it. It might simply be a case of the parser incorrectly thinking that

    is not allowed inside <form> and therefore closing the tag early.

  • mth (unregistered)

    That was supposed to say "<div> is not allowed inside <form>". I blame the lack of a preview option.

Leave a comment on “Documented Concerns”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article