Introducing the TORMENT style guide!

Not suitable for the weak-minded or sensitive.

Author: robertrossmann

coding-styles/torment.js

@@ -0,0 +1,49 @@
+/**
+ * js-coding-standards
+ *
+ * @author      Robert Rossmann <[email protected]>
+ * @copyright   2016 STRV
+ * @license     http://choosealicense.com/licenses/bsd-3-clause  BSD-3-Clause License
+ */
+
+'use strict'
+
+// You are crazy and you know it. You take pride in it. These rules will take eslint to the next
+// level of strictness and you will feel its presence in every keystroke. You will fear what it
+// throws at you next and you will revel in that fear.
+//
+// You have been warned.
+module.exports = {
+  extends: 'javascript/coding-styles/base',
+
+  rules: {
+    // Enforce/Disallow Variable Initializations
+    // You think you can get away with uninitialised variables? Hah! Forget it, dude!
+    'init-declarations': 1,
+
+    // Disallow Shadowing of Variables Inside of catch
+    // No. Make up a new variable name.
+    'no-catch-shadow': 1,
+
+    // Limit Maximum Number of Statements
+    // Hit this limit? You are doing it wrong -> refactor!
+    'max-statements': [1, 15],
+
+    // Disallow use of negated expressions in conditions
+    'no-negated-condition': 1,
+
+    // Variable Sorting
+    // Of course you should sort your vars! It makes your code look more like poetry!
+    'sort-vars': 1,
+
+    // Disallow Magic Numbers
+    // Nope. Define them as constants. Or something.
+    'no-magic-numbers': 2,
+
+    // Require Radix Parameter
+    'radix': 1,
+
+    // Require Regex Literals to be Wrapped
+    'wrap-regex': 1
+  }
+}

unused.js

@@ -9,19 +9,7 @@
 'use strict'
 
 module.exports = {
-  'rules': {
-    // Enforce/Disallow Variable Initializations
-    // Unused, too restrictive. On frequent occasions, you need to declare a property uninitialised and
-    // give it value later.
-    'init-declarations': 0,
-
-    // Disallow Shadowing of Variables Inside of catch
-    // In IE 8 and earlier, the catch clause parameter can overwrite the value of a variable in the
-    // outer scope, if that variable has the same name as the catch clause parameter.
-    // Unused, front-end specific. Should be moved to appropriate front-end config as soon as it
-    // exists.
-    'no-catch-shadow': 0,
-
+  rules: {
     // Treat var as Block Scoped
     // Unused in favour of `no-var` rule. Front-end could have some interest in this rule.
     'block-scoped-var': 0,
@@ -63,10 +51,6 @@ module.exports = {
     // exists.
     'no-script-url': 0,
 
-    // Limit Maximum Number of Statements
-    // Unused, too restrictive.
-    'max-statements': 0,
-
     // Disallow ++ and --
     // Unused, these operators are quite useful as long as whitespace is used responsibly around them.
     'no-plusplus': 0,
@@ -93,33 +77,8 @@ module.exports = {
     // Unused, continue seems to be quite useful.
     'no-continue': 0,
 
-    // Disallow use of negated expressions in conditions
-    // Unused, too restrictive.
-    'no-negated-condition': 0,
-
     // Disallow Ternary Operators
     // You kidding me? Ternaries are great!
-    'no-ternary': 0,
-
-    // Variable Sorting
-    // Unused, too restrictive.
-    'sort-vars': 0,
-
-    // Disallow Magic Numbers
-    // Unused, too restrictive. It was flagging i.e. `array.indexOf('a') !== -1` (is 'a' in this array?)
-    // as errors. Also, status code checks in HTTP responses were being reported as issues.
-    // While I generally like the idea, current implementation simply won't fly well.
-    'no-magic-numbers': 0,
-
-    // Require Radix Parameter
-    // This rule is aimed at preventing the unintended conversion of a string to a number of a
-    // different base than intended.
-    // Unused, too restrictive. Front-end team might have some interest in this as the whole radix
-    // issue started with different browsers using different radix for different numbers.
-    'radix': 0,
-
-    // Require Regex Literals to be Wrapped
-    // Unused, too restrictive.
-    'wrap-regex': 0
+    'no-ternary': 0
   }
 }