✓ "disallow labels for anything other than loops and switches" http://eslint.org/docs/rules/no-empty-label
if it was up to me, we can prohibit labels altogether

Noooooooooooooooooooooo

http://eslint.org/docs/rules/no-extra-boolean-cast
It would prevent if (!!foo) {, but this is widely used to return a boolean if a (A) property doesn't exist, like x && x.y or to convert something to boolean that isn't a boolean yet (for example if the target function expects a boolean and treats something like a boolean but someone passes some class instance)

The trick is mostly used to return something truthy to true.

The linter already complained about files that contain this double negation.

If we were to prevent that, we would have to use "x ? true : false` in many cases or even `

And to check for existence of settings, we would have to test like this (while easily being able to oversee some typo):
else if (g_IsController && g_GameAttributes.settings.PlayerData[playerSlot].AI && g_GameAttributes.settings.PlayerData[playerSlot].AI != "")

The first proposal was posted here
https://wildfiregames.com/forum/index.php?/topic/22251-coding-conventions-updates/&_fromLogin=1

✓ prevents unneeded parenthesis like `if ((x == y) && z) http://eslint.org/docs/rules/no-extra-parens ( ͡° ͜ʖ ͡°)

✓ betcha! http://eslint.org/docs/rules/no-extra-semi

Looks correct. The only case when we really do foo = function(..) {.. is for local functions and for global objects that have functions in objects, like unitAI or gui http://eslint.org/docs/rules/no-func-assign

prevents if(!key in object) {

This rule was deprecated in ESLint v3.3.0 and replaced by the no-unsafe-negation rule.

which isn't specified here, but I guess that has a reason.

✓ as long as we specify it at all

✓
Uh yes, who would ever call Math() or JSON()
http://eslint.org/docs/rules/no-obj-calls

✓ useful one, prevents return; foo; http://eslint.org/docs/rules/no-unreachable

✓ prevent if (foo == NaN) {, require isNaN(foo)

✓ yes please! I have seen too many broken JS doc comments http://eslint.org/docs/rules/valid-jsdoc

✓ prevents typos typeof foo === "strnig" http://eslint.org/docs/rules/valid-typeof

ok, but but wai not
prevents

if (true) {
    var build = true;
} else {
    var build = false;
}

http://eslint.org/docs/rules/block-scoped-var

Might be ok to start with it since that is still present in the codebase in various places, but I'd discourage a code pattern like that. A variable ought to be defined in the broadest scope it's accessible.

If we use let in local scope everywhere, above pattern will throw error at JS-compile time afaik, which makes it easy to spot for devs to find instances where variables are used out of scope weirdly

✓ must have, prevents if (x) return; else return X. should either never or always specify the return value. http://eslint.org/docs/rules/consistent-return

Not convinced in particular for requireing default, (Not that I like switches neither), for example if we can guarantee that it will never occur.
http://eslint.org/docs/rules/default-case

✓ prevents foo["bar"] requires foo.bar http://eslint.org/docs/rules/dot-notation

✓ prevents if (x) return; else bar(); http://eslint.org/docs/rules/no-else-return since that else is entirely pointless, code that can't be executed.

✓ didn't see someone trying this yet, definitely should prevent access to this if not inside a class http://eslint.org/docs/rules/no-invalid-this

Not necessarily.

Prevents unneeded scopes.
D195, also might help structuring things sometimes, making some vars more local than before. Would only to argue for the D195, not really for any others. http://eslint.org/docs/rules/no-lone-blocks

✓ We don't run into closure issues that often (only saw it once in menu.js iirc) so we violate this recommendation all over the place
http://eslint.org/docs/rules/no-loop-func

✓ prevents duplicate spaces if(foo === "bar") {} I do this all the time without noticing until the linter complains http://eslint.org/docs/rules/no-multi-spaces

✓ Never seen the Symbol class being used, so I guess it's ok to prevent doing wrong things with it http://eslint.org/docs/rules/no-new-symbol

✓ We have many occurances of that I assume, but they will be easy to fix
prevents

var a = 3;
var a = 10;

✓ prevents return x = z which is useless and misleading http://eslint.org/docs/rules/no-return-assign

✓ prevents foo = foo; http://eslint.org/docs/rules/no-self-assign

✓ prevents if (x === x) http://eslint.org/docs/rules/no-self-compare

Maybe.

prevents

while (node)
    doSomething(node);

assuming that node never changes.
Can have it enabled until we meet the first false positive.
http://eslint.org/docs/rules/no-unmodified-loop-condition

✓ prevents useless code

function increment() { i += 1; }
increment(); // return value is unused, but i changed as a side effect

http://eslint.org/docs/rules/no-unused-expressions

✓ prevents unused labels (for GOTOs), definitely cut them off. http://eslint.org/docs/rules/no-unused-labels

Maybe. Prevents "x" + "y".

There might be occurances where having it this way might be more logical, as those might be 2 logically separate strings that might be replaced individually sometime.

Can be kept until further notice.

http://eslint.org/docs/rules/no-useless-concat

✓prevents delete x since delete only works on properties http://eslint.org/docs/rules/no-delete-var

✓ prevents variables that are label names http://eslint.org/docs/rules/no-label-var

✓ prevents overwriting defined keywords like undefined http://eslint.org/docs/rules/no-shadow-restricted-names

Wrong?

prevents overshadowing of ones own variables:

var a = 3;
function b() {
    var a = 10;
}

Sounds good to me, is there a reason not to do it?

✓ definitely each variable referenced should be declared at some point. However

✓ Meh fine (as discussed in the linting topic). Prevents var foo = undefined; Will fix accoring code sometime.

Any reason for ignoring this?

Prevents unused variables (never read from).
http://eslint.org/docs/rules/no-unused-vars

Why not?

Prevents lowercase prototype names. At least for the sim+AI directory everything looks fine on first sight
http://eslint.org/docs/rules/new-cap

✓ requires parenthesis for ctors, i.e. prevents var person = new Person;

✓
prevents `var isYes = answer === 1 ? true : false`;
(Depends on above "noooooooooooo" thing)

✓
prevents overwriting of class definitions:

class A { }
A = 0;

✓ prevents overwriting consts:

const a = 0;
a = 1;

✓ prevents duplicate class members:

class Foo {
  bar() { console.log("hello"); }
  bar() { console.log("goodbye"); }
}

✓ requires const if the value isn't changed.
totally dont want this rule so that our code and mods can modify globals in different files externally
http://eslint.org/docs/rules/prefer-const

Still not convinced. Why would we require default in switch statements?

I see. Then we can set this to 1

no-shadow should become 1, no?

oh, obviously.

✓ until we find a good reason not to

I think here is the reason: https://code.wildfiregames.com/D516#22933

Because that's the proper way of writing a switch. You should always handle all cases, you can issue a warning if the default case shouldn't happen but does.

Sorry, I had missed it indeed.

I tried to change that in the previous iteration and it produced things like in D516, so that's a good reason to have it to zero ?

In case of review https://docs.pylint.org/en/1.6.0/features.html and I'd ask for the source of this file (to see whether those are actually defaults)

Trying this on my on device, it seems loopfunc has to be true to not get this Don't make functions within a loop. error.
(Sorry for suggesting the wrong change)
When set to true, these options will make JSHint produce fewer warnings about your code.