• NotAThingThatHappens (unregistered)

    Null-check be gone!!!

    sw = sw ?? new Stopwatch(); ResetStopwatch();

  • (nodebb)

    sw = sw ?? new Stopwatch(); ResetStopwatch();

    Relatively new syntax... Try that back in 2008 (yeah, I know about stopwatch history; not the point).

  • NotAThingThatHappens (unregistered)

    Honestly, there are problems here with things like: Who owns the stopwatch, who is allowed to reset the stopwatch, what is multiple methods did this.

    If the point is that there should always be a stopwatch, then create it in the constructor and make it readonly. Even then, you run the risk that different methods are resetting each others measurements.

    Thank you, I hate this.

  • Esther (unregistered) in reply to NotAThingThatHappens

    This is not functionally the same. In the original code ResetStopWatch is only called when a new one is created.

  • (nodebb) in reply to NotAThingThatHappens

    That's not equivalent. In the code in the article (both old and new), ResetStopwatch() is only called when sw was null. This would call it every time.

    Addendum 2021-12-09 08:01: I should have expected someone else to e faster.

  • Loren Pechtel (unregistered)

    The replacement code isn't the same--the original version will create and reset the stopwatch if it has been disposed of. The shortened version will not.

  • Gnasher729 (unregistered) in reply to NotAThingThatHappens

    So you call ResetStopWatch() when you probably shouldn’t.

  • (nodebb)

    if (sw ==null) { sw = new Stopwatch(); ResetStopwatch(); }

    // Was the following: the purpose was: check if there is a stopwatch, if not, do the create one and reset it. // the code above seems simpeler

    //try //{ // bool check = sw.IsRunning; //} //catch //{ // sw = new Stopwatch(); // ResetStopwatch(); //}

    "Do or do not. There is no try."

  • nestor (unregistered)

    The main issue was raised by NotAThingThatHappens, but another issue was ironically missed: the act of creating any object should result in a predictable, not-a-thing-that-happens state.

    When creating a thread, I don't expect it to be running before being instructed to start. Having just created an XHR-request, I don't expect it to be in the middle of some communication. When creating a stopwatch, I don't expect it to be running (or to be show some random measurement ). I do expect it to be at t=0 and ready to start when instructed.

    What's up with the "create-and-then-initialize" stratagem?

  • (nodebb) in reply to NotAThingThatHappens

    Honestly, there are problems here with things like: Who owns the stopwatch, who is allowed to reset the stopwatch, what is multiple methods did this.

    So you're saying: who watches the stopwatchmen?

  • (nodebb) in reply to chucker23n

    Who *stopwatches the stopwatchmen?

  • TrayKnots (unregistered)

    Well, the original code might have some advantage. Assumption: This code runs in a loop, like a game loop, for 120 times per second. The original version would not have any overhead checking an if statement.

    And before I am torn to shreds, I only state that there are a few situations in which the original code is better. Not that it is usually better.

  • (nodebb)

    I have implemented almost exactly this in the past - keeping e.g. Information and Errors but not Warnings can be useful, and being able to make the logger more or less verbose as an additional option also makes sense. If you are used to embedded programming its more likely you think about bit masks in this way and bend an enum to the way you would have done it in assembler.

    Addendum 2021-12-22 12:27: Woops wrong WTF. I shall go back to sleep.

Leave a comment on “Stop, Watch”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article