All due respect, I think "explains that" would be more accurate than "explains how" here

True that Dampier. I wish I could edit it :(

If you read the code, you will notice that the FIRST time this error is encountered, it will always be logged.

The test in question is done frequently, and subsequent failures are about 100 times less interesting than the first. Unless you just like filling up disks with log files while your network is acting up.

Finally, note that the "_ok" flag will be RESET and the resolved condition logged once the test finally returns to succeeding.

Awesome, thanks for the explanation

Thank you for an excellent counterexample for when people claim code comments are useless.

You could express the same thing without comments:

    boolean alreadyLogged = !_ok;
    boolean skipLogging = alreadyLogged && (Math.random() > 0.1)
    if( skipLogging ) return res;

I strongly dislike your version. Creating a boolean just to use and discard in the next line? Twice? Ugly. I'd much rather keep the code simple and try to cut out confusing parts. Give the flag a better name and remove the useless ternary. I'd also get rid of the conditional return and let the one outside the catch do the work.

  if (!errorLogged || (Math.random() < 0.1)) {
    
    errorLogged = true;
    
    // log error
    
  }

But if it's a choice between comments and adding temporary variables that don't do anything, I'll almost always choose comments.

I'd tend to choose temporary variables. I trust my compiler to optimise them out, and I find it makes it much easier to find the appropriate place to change or add new code.

"Does this affect working out whether the error has been logged before?", "Does this affect whether we should log this error?", etc

EDIT: But in this case I'd still want to put a comment clarifying the "why".

are you sure the compiler is smart enough to do that? I think we frequently assume compilers are smarter than they really are because we don't fully understand them anymore... but in practice I find they often do very dumb things.

No, but I am sure that my automated performance testing procedures will detect if I've introduced a significant performance problem, and it would be an inefficient use of my time to worry about insignificant performance effects.

Register renaming is one of the most very basic levels of optimization. I challenge you to find me a single optimizing compiler that slows down when you give names to temporary results. Hell, I can show you non-optimizing compilers that suffer no slowdown from code like this.

I wouldn't actually have them as Boolean variables, I'd extract them into query methods, then the code would just be:

    if( skipLogging() ) return res;

Heh ... agreed. A comment here would definitely not go amiss.

These guys are doing Good Things.

This fills me with hope.

Functionally striking, visually beautiful -- it makes me feel suddenly like things are coming together in a way that might stick this time around.

In form: Value placed on aesthetics -- beautiful & functional design -- is a concept that's taken root in the marketplace at large.

In code: Like gfodor commented, it feels like the doors are open wider than they've been in a long time to new ideas, and that we see some elegant language mechanisms being rediscovered and rising to the top.

In tools: The same pattern ... with lots of points of reference, a critical mass of seekers and open source contributors, and bootstrapped on powerful tools that allow rapid expression of new ideas, the good ones see the light of day and, if successful, can take an advantage of an unprecedented kinetics of this ecology to rise to viability and then prominence.

I hope you'll forgive me if I'm blowing this out of proportion to wax elegiac or whatever -- it just suddenly feels like a good day to be a programmer.

This fills me with hope.

Functionally striking, visually beautiful -- it makes me feel suddenly like things are coming together in a way that might stick this time around.

In form: Value placed on aesthetics -- beautiful & functional design -- is a concept that's taken root in the marketplace at large.

In code: Like gfodor commented, it feels like the doors are open wider than they've been in a long time to new ideas, and that we see some elegant language mechanisms being rediscovered and rising to the top.

In tools: The same pattern ... with lots of points of reference, a critical mass of seekers and open source contributors, and bootstrapped on powerful tools that allow rapid expression of new ideas, the good ones see the light of day and, if successful, can take an advantage of an unprecedented kinetics of this ecology to rise to viability and then prominence.

I hope you'll forgive me if I'm blowing this out of proportion to wax elegiac or whatever -- it just suddenly feels like a good day to be a programmer.

Agreed on all counts. I was there in February, and can't recommend it highly enough for any self-respecting nerd. Many wonderful artifacts from the history of human ingenuity, and an incredible sense of place. It was there that I saw my first Dekatron!

Mr. Sale's enthusiasm for and dedication to this functioning piece of history -- and to educating more recent generations about it -- were truly inspiring. It was fun to see a group of schoolchildren hanging on his every word as he pointed out parts of the machine ... after which he simply went back to tinkering with it alongside his colleague.

I'm really sad to learn of his passing. But I'm deeply grateful for the legacy he's left behind.