The console will print the result of evaluating an expression. The result of evaluating console.log() is undefined since console.log does not explicitly return something. It has the side effect of printing to the console.

You can observe the same behaviour with many expressions:

> var x = 1;
undefined;

A variable declaration does not produce a value so again undefined is printed to the console.

As a counter-example, expressions containing mathematical operators do produce a value which is printed to the console instead of undefined:

> 2 + 2;
4

It prints the result of this expression - which is undefined. And yes, var a is a valid expression on its own.

Actually, you should rather be amused by why console prints undefined when you write var a = 3 or something like this. It also prints undefined if function anyFunctionName() {} statement is processed. In fact, all the var and function declaration (!) statements seem to be ignored if there's another statement with some 'real' result:

>>> var a = 3;
undefined

>>> var a = 3; a = 4;
4

>>> var a = 3; a = 4; var a = 5; function f() {};
4 // !!!

Now, I suppose the real reason behind is behaviour of eval statement, as described here:

• Let result be the result of evaluating the program prog.
• If result.type is normal and its completion value is a value V, then return the value V.
• If result.type is normal and its completion value is empty, then return the value undefined.

So now the question is, what does var a = 4 statement return? Guess what: it's not 4.

The production VariableStatement : var VariableDeclarationList; is evaluated as follows:

• Evaluate VariableDeclarationList.
• Return (normal, empty, empty).

Now the most interesting part: what happened in the last example, why 4 is the result? That's explained in this section:

The production Program : SourceElements is evaluated as follows:

• Let result be the result of evaluating SourceElements.

[...]

The production SourceElements : SourceElements *SourceElement* is evaluated as follows:

• Let headResult be the result of evaluating SourceElements.
• If headResult is an abrupt completion, return headResult.
• Let tailResult be result of evaluating SourceElement.
• If tailResult.value is empty, let V = headResult.value, otherwise let V = > tailResult.value.
• Return (tailResult.type, V, tailResult.target)

Both function f() {} and var a = 5 statements' return values were (normal, empty, empty). So the script ended up with giving out the result of the first statement (starting from the script's end, so technically it's the last one) that's not (normal, empty, empty). That is the result of a = 4 assignment statement - which is 4.

P.S. And now for some icing on the cake: consider the following:

>>> function f() {}
undefined

>>> (function f() {})
function f() {}

The difference is quite subtle: the first input is treated as a Function Declaration statement, which, according to this rule...

The production SourceElement : FunctionDeclaration is evaluated as follows:

• Return (normal, empty, empty).

... will eventually produce undefined when eval-ed, as we already know.

The second input, however, is treated as a Function Expression, which is evaluated to the function itself. That means it'll be passed through eval and eventually returned to the console (in its format).

If you are interested in finding out whether a variable has been declared regardless of its value, then using the in operator is the safest way to go. Consider this example:

// global scope
var theFu; // theFu has been declared, but its value is undefined
typeof theFu; // "undefined"

But this may not be the intended result for some cases, since the variable or property was declared but just not initialized. Use the in operator for a more robust check.

"theFu" in window; // true
"theFoo" in window; // false

If you are interested in knowing whether the variable hasn't been declared or has the value undefined, then use the typeof operator, which is guaranteed to return a string:

if (typeof myVar !== 'undefined')

Direct comparisons against undefined are troublesome as undefined can be overwritten.

window.undefined = "foo";
"foo" == undefined // true

As @CMS pointed out, this has been patched in ECMAScript 5th ed., and undefined is non-writable.

if (window.myVar) will also include these falsy values, so it's not very robust:

false
0
""
NaN
null
undefined

Thanks to @CMS for pointing out that your third case - if (myVariable) can also throw an error in two cases. The first is when the variable hasn't been defined which throws a ReferenceError.

// abc was never declared.
if (abc) {
    // ReferenceError: abc is not defined
} 

The other case is when the variable has been defined, but has a getter function which throws an error when invoked. For example,

// or it's a property that can throw an error
Object.defineProperty(window, "myVariable", { 
    get: function() { throw new Error("W00t?"); }, 
    set: undefined 
});
if (myVariable) {
    // Error: W00t?
}

Try

if (!window.console) console = ...

An undefined variable cannot be referred directly. However, all global variables are attributes of the same name of the global context (window in case of browsers), and accessing an undefined attribute is fine.

Or use if (typeof console === 'undefined') console = ... if you want to avoid the magic variable window, see @Tim Down's answer.

If you're running console.log() from a JS file, this undefined line should not be appended.

If you're running console.log() from the console itself, it makes sense. This is why: In the console you can type a name of a variable (for example try typing window) and it prints info about it. When you run any void function (like console.log) from the console, it also prints out info about the return value, undefined in this case.

I tested both cases on my Chrome (Mac ver 23.0.1271.101) and indeed I see the undefined line when I run it inside the console. This undefined also appears when I write this line in the console: var bla = "sdfdfs"