[Dylan16807]

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.

[qu4z-2]

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".

[ranman]

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.

[lmm]

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.

[Dylan16807]

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.

[ollysb]

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;