- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Null-check be gone!!!
sw = sw ?? new Stopwatch(); ResetStopwatch();
Admin
sw = sw ?? new Stopwatch(); ResetStopwatch();
Relatively new syntax... Try that back in 2008 (yeah, I know about stopwatch history; not the point).
Admin
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.
Admin
This is not functionally the same. In the original code ResetStopWatch is only called when a new one is created.
Admin
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.
Admin
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.
Admin
So you call ResetStopWatch() when you probably shouldn’t.
Admin
"Do or do not. There is no try."
Admin
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?
Admin
So you're saying: who watches the stopwatchmen?
Admin
Who *stopwatches the stopwatchmen?
Admin
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.
Admin
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.