Here is where I indulge in a little bike-shedding (because mauve is definitely in this season).

I'll go with whatever your ultimate decision is, but I wanted to run through the alternatives first. Apologies in advance.

----

I'll do this along with my next update:
* `this.noLintChanged` to `this.noLintChanged_`.

After LGTM:
* build `bin/traceur.js`.
* squash commits.

----

I don't know, I personally find xor more intuitive here. I actually didn't consider the `!==` possibility until you mentioned it.

Thinking in terms of graphics, the result is the same when xored over a 0-background, and reverse-video when xored over a 1-background.

So here, I naturally think of `decision ^ condition` as "go with your original `decision`, but in the case of `condition`, do the opposite". It's kind of like playing "opposite day".

```js
if ((!options.strictSemicolons || this.noLint) ^ this.noLintChanged_)
```

----

In this situation, I find `decision !== condition` a little harder to follow, because `condition` isn't used in its normal sense. It's more like a baseline for comparing `decision` against.

So the naming in this case might be better as `decision !== baseline` -- "if your `decision` differs from the `baseline`, then do this action."

I still find this less intuitive than the xor version, but changing the var name to match the semantics helps some.

```js
if ((!options.strictSemicolons || this.noLint) !== this.noLintBaseline_)
```

The idea of baseline here seems a little abstract to me here. Quick, what does a `true` baseline mean? I find that I have to run through the conditional, unless I cheat and use the fact that `!==` is just another way to write xor in the case of booleans.

(See equational logic for some neat uses of equality and negation as a substitute for boolean operators; one of those random things I found exploring the net one day. It's not something I ever practiced with enough to make it second nature, but still an interesting idea.)

----

Finally, there is the simplest solution, which is to just make everything explicit. In terms of micro-optimization, this does unneeded work in the normal case of no errors, but I doubt it actually makes much difference considering everything else that's happening in the function.

```js
var strictSemicolons = options.strictSemicolons && !this.noLint;
if (this.noLintChanged_)
  strictSemicolons = !strictSemicolons;
// ...
if (!strictSemicolons)
```

This way is even more verbose, but does no unneeded work.

```js
var strictSemicolons;
// ...
strictSemicolons = options.strictSemicolons && !this.noLint;
if (this.noLintChanged_)
  strictSemicolons = !strictSemicolons;
if (!strictSemicolons)
```

----

I couldn't help myself. I did a test of the different techniques and found the differences to be in the hundredths of a second range for a one-second parse, and not really distinguishable from the sample variation (though I didn't do any statistical analysis).

```bash
cat > bench-traceur <<"END_"
#!/bin/sh
D=$(mktemp -d bench-XXXX)
cp bin/traceur.js $D
cat > $D/bench-parse.js <<"END"
var fs = require('fs');
var traceur = require('../src/node/traceur');

var name = process.argv[2];
var source = fs.readFileSync(name, 'utf8');
console.reportError = console.error;

// bench; code taken from esprima-compare.patch
var start = Date.now();
var file = new traceur.syntax.SourceFile(name, source);
var parser = new traceur.syntax.Parser(console, file);
var tree = parser.parseProgram();
console.log(Date.now() - start);
END

for i in $(seq 5); do
  node $D/bench-parse.js $1
done | awk '
  BEGIN{s=0;n=0}
  {printf("%4d\n",$1);s+=$1;n++}
  END{printf("%f (%d trials)\n", s/n, n)}'
rm -r $D
END_
chmod +x bench-traceur
cp bin/traceur.js{,-bench-source.js}

# try this with different variations of bin/traceur.js
./bench-traceur bin/traceur.js-bench-source.js

# clean up
rm bin/traceur.js-bench-source.js
```

I wonder if we should add a node benchmark? It would make checking for performance regressions much more convenient. I think I've run the html benchmarks once.