Take the 2-minute tour ×

I was looking at the source code to qTip 2 and saw the following:

// Munge the primitives - Paul Irish tip
var TRUE = true,
   FALSE = false,
    NULL = null;

I can't come up with a reason you should ever do this, and have a strong feeling that it would just encourage bad coding habits. Say a developer makes a typo in a Yoda condition like if (TRUE = someCondition()), then TRUE could very well end up actually meaning false, or you might end up assigning someObject to NULL.

I guess I'm just wondering if there's some redeeming quality for this practice that I'm missing, or if this is just a plain old Bad Idea™

share|improve this question
Btw, +1 not only for the good question but for using the term Yoda condition.. –  Mike Christensen Jan 5 '12 at 17:22
@MikeChristensen: You might be interested in this article, then :) -dodgycoder.net/2011/11/yoda-conditions-pokemon-exception.html –  Tristan Jan 5 '12 at 18:33
Hmm, actually get work done or read funny coding blog. Blog it is! –  Mike Christensen Jan 5 '12 at 18:36

3 Answers 3

up vote 12 down vote accepted

The goal of this is just to improve compression, Paul Irish himself calls it as an "Anti-Pattern".

He describes it as "Good for compression and scope chain traversal" on the following presentation:

On scope chain traversal, we won't see any improvement on literals as null, false, true, since the scope chain is not inspected, they are just literals.

On other identifiers as undefined or windows the scope chain traversal is indeed inspected.

Paul Irish Anti-patterns slide 55

share|improve this answer
I wonder if it's worth it at all if you gzip. I seem to recall cases where the obfuscated result was indeed smaller, but the gzipped result was larger than the equivalent gzip without the munging. –  squint Jan 5 '12 at 17:25
The exact code from the OP appears on slide 55. How fitting... –  hugomg Jan 5 '12 at 17:26
@missingno - qTip got the idea from this slide. They put it write there in the comment (see the first line in the OP's code). –  Joseph Silber Jan 5 '12 at 17:29
@JosephSilber: thank you for the detailed response :) –  Tristan Jan 5 '12 at 18:36
@amnotiam: that's a great question, I'd be interested in seeing some real world comparisons –  Tristan Jan 5 '12 at 18:38

You could do this for the sake of code compression. For example, YUI Compressor is not going to touch true and false, but it could replace all occurrences of, for example, TRUE with A, saving four characters per occurrence. For example, before compression:

    if (foo === null) {
        bar = true;

After compression, assuming the compressor replaces TRUE with a and NULL with c:


Versus this, after compression with no "munging of primitives":


The bad-coding-habits danger that you quite correctly cite in your question may outweigh the small savings in additional compression. It depends on how desperate you are to save a few dozen or perhaps a few hundred bytes.

Personally, I would (almost) never do this. Too dangerous.

share|improve this answer

I believe this is recommended for compression.

These shortcut variables will be compressed when munged, resulting in smaller files. However, your noted drawbacks are most certainly valid points!

share|improve this answer

Your Answer


