Develop Reference

ERROR: 'console is not defined. [no-undef] - Brackets

I've installed brackets and currently playing around with variables and functions. All the outputs work fine in the console, however I keep getting this error in the editor.
How do I go about fixing this?

The no-undef rule looks out for undefined variable, without any initial assumption on the environment and the global variables (console for instance).
You can specify that you are in an environment where console indeed exists, by adding browser and/or node envs in your .eslintrc:
env: {
browser: true,
node: true,
},
More info in the rule doc

just to have comment:
/*global console*/
as the first line of your .js file, and then have:
// eslint-disable-line no-console
at the line of the console.log("");
this will make the error go away!

Since you have it as a Capitol C, I would guess that the editor thinks you're looking for a function or class. Try lowering it from Console.log() to console.log("john won...") and see if that works.

I assume it's coming from no-console rule, which disallows calls to methods of the console object.
In JavaScript that is designed to be executed in the browser, it’s
considered a best practice to avoid using methods on console. Such
messages are considered to be for debugging purposes and therefore not
suitable to ship to the client. In general, calls using console should
be stripped before being pushed to production.
Examples of correct code for this rule:
/*eslint no-console: "error"*/
// custom console Console.log("Hello world!");
As a solution, you can add this to your set of rules in .eslintrc
rules: {
'no-console': 'off'
}

This one was driving me crazy as well. You can edit Brackets' config JSON. It will remove the error icon from the left gutter:
{
"brackets-eslint.gutterMarks": false
}
Reference: https://github.com/brackets-userland/brackets-eslint/blob/master/README.md

add 'no-console' in rules object is inactive

I think you should write "console.log" instead of "Console.log". It should be lowecase.

This might seem like a special case, but deleting and recreating the .eslintrc file fixed this issue for me.

Window object not defined in jasmine

I am trying to test a method where one of the thing that it does it lock orientation of screen. Jasmine however is throwing error in the line:
(<any>window).screen.orientation.lock('portrait') saying that undefined is not a constructer.
I even tried not using typescript types and just window.screen.msOrientationLock('landscape') and other window.screen methods but I get same error. I have the _$window_ injected in beforeEach of my tests too.
Testing if it locks is not necessary part of my test so is there some way to skip this specific line or correct this error. Thanks :)

Well it was easy. I had to inject window object and assign it to a global variable in my global beforeEach like this:
$window = _$window_;
Then, the next issue was that the property orientation was not available in the window.screen object unfortunately. I just had to mock it inside my spec like this:
$window.screen.orientation = {
lock: function() { return; }
};
Just had to do this before spying/calling the method which had window.screen.orientation.lock method inside it.

JavaScript JSHint - 'close' is defined but never used

I don't know why but some words that I use as function names get a lint error of being defined but never used.
For instance, the code below returns error:
// I am using AngularJS
$scope.close = close;
function close() {
/* Code here */
}
But this does not:
// I am using AngularJS
$scope.close2 = close2;
function close2() {
/* Code here */
}
The error is on the line function close(). Why is this such a special name? How can I mute this error?

(Note: Answer has been heavily edited)
Summary
John Papa says to use latedef in JSHint and, at least implicitly, to ignore JSLint issues. (latedef defined here.)
I believe there's a plays-nicely solution (see below), however, that includes the advantages of Papa's suggested style with code that lints in JSHint and JSLint.
JSHint is "wrong" not to complain about close2. JSLint catches it exactly like you'd expect.
close but not close2 is a JSHint problem
For what it's worth, if you paste your code (jslint formatted Pasteee with both close & close2 here) into JSLint.com, both close and close2 cause errors. If you're not seeing an error for close2, I'm guessing it's JSHint's problem, but it'd be more useful to see exactly what you're linting through JSHint (in context) to know for sure.
So close is not a special name to JSLint. I would like to see your "actual" code in context to see if JSLint would say something similar
Just to be clear, this breaks on JSLint.com:
/*jslint sloppy:true, white:true */
/*global $scope */
$scope.close2 = close2;
function close2() {
return "something";
}
That will produce 'close2' was used before it was defined. $scope.close2 = close2;
If you want to know why JSHint is, I believe, breaking, we can go JSHint code spelunking, but to answer your JSLint tag (at least) the behavior you're seeing isn't happening.
How to fix
See this SO answer on exactly what you're discussing here, where John Papa says to use latedef in JSHint. One way around the linting issue is to ignore Papa and define the function first, but, as you mention in your comment, below, that's not ideal.
So here's the best compromise I could come up with...
Declare, but don't define, variables that will hold functions.
Insert your Angular directive
Define your functions from 1.
That definitely mutes the JSHint error, since the code that caused it isn't there any more. If I was doing Angular and needed to follow Papa-style, that's what I'd do to keep Crockford's blessing.
Example:
(function () {
'use strict';
// 1. Declare your function names. Minimally spammy!
var theController;
// 2. Directive
angular
.module('myApp')
.controller('myAppCtrl', theController);
// 3. *Define* the functions. No `latedef` needed, and JSLint compliant.
// Keeps "the list of calls at the top of the page" and allows you to
// "jump to each definition if you need more details". QED? ;^)
theController = function () {
return "so jslint doesn't complain about empty blocks";
};
}());

jshint "function" is defined but never used or how to declare a function

im getting the jshint notification
line 1 col 10 'popUp' is defined but never used.
the js looks like that:
function popUp(e, element) {
do.something();
};
it would be easy to change the jshint config to
/* jshint unused:false */
but i want to see if there are other variables which arent used?
do i have to improve my function declartion or is it jshint?
edit
i boiled it down to two failures, these are the functions who are called in the html file onmousemove or mouseover...

How to tell JSHint to ignore all undefined variables in one file?

In Karma tests, there are a lot of global variables and functions, which JSHint complains about (it is integrated into my editor).
How can I tell JSHint to ignore all undefined variables in this one specific file? I would expect /* jshint undef: false */ to turn off these warning, but it doesn't.

The correct way to tell JSHint about globals is to use the globals directive. For example:
/*globals globalFunction, anotherGlobal, oneMore */
This will prevent "{a} is not defined" warnings when JSHint encounters any of the listed identifiers.
Alternatively, if you really want to ignore all "not defined" warnings in that file, and you're using JSHint 1.0.0 or above, you can simply turn off that specific warning:
/*jshint -W117 */

Just add this rule in your .jshintrc file.
"-W117": true
This will ignore all the warnings which say, '* is not defined.'

Ran into this problem using jshint this afternoon.
This following fix worked for me.
Instead of using "globals", try using "predef".
For example:
{
/*
* RELAXING OPTIONS
* =================
*/
// Suppress warnings about == null comparisons.
"eqnull": true,
"predef" : ["describe", "expect", "it", "inject", "beforeEach", "angular"]
}

I've found myself using jshint ignore:line as a way of addressing this need:
var unusedVar; // jshint ignore:line
This allows jshint to continue its useful checking for this condition but where there are explicit reasons to ignore a specific declaration than adding this both addresses the issue and does it in a way that is immediately apparent to anyone looking at the code.
A good example (at least for me), is when using ES6's destructuring to illicit a set of shortcuts that you may or may not use all the time. In Ember, I often use many of the methods that hang off of it such as typeOf and computed. Rather than always referring to Ember.computed it's far nicer to just refer to computed and have something like the following at the top of all my Ember objects:
const { computed, $, A, run, on, typeOf, debug, get, set } = Ember; // jshint ignore:line