{"id":13395317,"url":"https://github.com/bevacqua/js","last_synced_at":"2025-05-15T01:06:32.275Z","repository":{"id":17103113,"uuid":"19868645","full_name":"bevacqua/js","owner":"bevacqua","description":":art: A JavaScript Quality Guide","archived":false,"fork":false,"pushed_at":"2023-11-07T14:37:24.000Z","size":60,"stargazers_count":2944,"open_issues_count":20,"forks_count":508,"subscribers_count":128,"default_branch":"master","last_synced_at":"2025-04-13T22:39:37.324Z","etag":null,"topics":["javascript","style-guide"],"latest_commit_sha":null,"homepage":"https://ponyfoo.com","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/bevacqua.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null}},"created_at":"2014-05-16T19:44:41.000Z","updated_at":"2025-04-12T15:13:14.000Z","dependencies_parsed_at":"2023-02-17T05:15:59.201Z","dependency_job_id":"85765eb8-f3d6-4376-8f88-84f41ee3195b","html_url":"https://github.com/bevacqua/js","commit_stats":{"total_commits":35,"total_committers":13,"mean_commits":"2.6923076923076925","dds":"0.48571428571428577","last_synced_commit":"891667efb35b1f520b560d016b4932493dcf72fe"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bevacqua%2Fjs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bevacqua%2Fjs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bevacqua%2Fjs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bevacqua%2Fjs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/bevacqua","download_url":"https://codeload.github.com/bevacqua/js/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254254041,"owners_count":22039792,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["javascript","style-guide"],"created_at":"2024-07-30T17:01:52.243Z","updated_at":"2025-05-15T01:06:27.261Z","avatar_url":"https://github.com/bevacqua.png","language":null,"readme":"# function qualityGuide () {\n\n\u003e A **quality conscious** and _organic_ JavaScript quality guide\n\nThis style guide aims to provide the ground rules for an application's JavaScript code, such that it's highly readable and consistent across different developers on a team. The focus is put on quality and coherence across the different pieces of your application.\n\n## Goal\n\nThese suggestions aren't set in stone, they aim to provide a baseline you can use in order to write more consistent codebases. To maximize effectiveness, share the styleguide among your co-workers and attempt to enforce it. Don't become obsessed about code style, as it'd be fruitless and counterproductive. Try and find the sweet spot that makes everyone in the team comfortable developing for your codebase, while not feeling frustrated that their code always fails automated style checking because they added a single space where they weren't supposed to. It's a thin line, but since it's a very personal line I'll leave it to you to do the drawing.\n\n\u003e Use together with [bevacqua/css][32] for great good!\n\nFeel free to fork this style guide, or better yet, send [Pull Requests][33] this way!\n\n## Table of Contents\n\n1. [Modules](#modules)\n2. [Strict Mode](#strict-mode)\n3. [Spacing](#spacing)\n4. [Semicolons](#semicolons)\n5. [Style Checking](#style-checking)\n6. [Linting](#linting)\n7. [Strings](#strings)\n8. [Variable Declaration](#variable-declaration)\n9. [Conditionals](#conditionals)\n10. [Equality](#equality)\n11. [Ternary Operators](#ternary-operators)\n12. [Functions](#functions)\n13. [Prototypes](#prototypes)\n14. [Object Literals](#object-literals)\n15. [Array Literals](#array-literals)\n16. [Regular Expressions](#regular-expressions)\n17. [`console` Statements](#console-statements)\n18. [Comments](#comments)\n19. [Variable Naming](#variable-naming)\n20. [Polyfills](#polyfills)\n21. [Everyday Tricks](#everyday-tricks)\n22. [License](#license)\n\n## Modules\n\nThis style guide assumes you're using a module system such as [CommonJS][1], [AMD][2], [ES6 Modules][3], or any other kind of module system. Modules systems provide individual scoping, avoid leaks to the `global` object, and improve code base organization by **automating dependency graph generation**, instead of having to resort to manually creating multiple `\u003cscript\u003e` tags.\n\nModule systems also provide us with dependency injection patterns, which are crucial when it comes to testing individual components in isolation.\n\n## Strict Mode\n\n**Always** put [`'use strict';`][4] at the top of your modules. Strict mode allows you to catch nonsensical behavior, discourages poor practices, and _is faster_ because it allows compilers to make certain assumptions about your code.\n\n## Spacing\n\nSpacing must be consistent across every file in the application. To this end, using something like [`.editorconfig`][5] configuration files is highly encouraged. Here are the defaults I suggest to get started with JavaScript indentation.\n\n```ini\n# editorconfig.org\nroot = true\n\n[*]\nindent_style = space\nindent_size = 2\nend_of_line = lf\ncharset = utf-8\ntrim_trailing_whitespace = true\ninsert_final_newline = true\n\n[*.md]\ntrim_trailing_whitespace = false\n```\n\nSettling for either tabs or spaces is up to the particularities of a project, but I recommend using 2 spaces for indentation. The `.editorconfig` file can take care of that for us and everyone would be able to create the correct spacing by pressing the tab key.\n\nSpacing doesn't just entail tabbing, but also the spaces before, after, and in between arguments of a function declaration. This kind of spacing is **typically highly irrelevant to get right**, and it'll be hard for most teams to even arrive at a scheme that will satisfy everyone.\n\n```js\nfunction () {}\n```\n\n```js\nfunction( a, b ){}\n```\n\n```js\nfunction(a, b) {}\n```\n\n```js\nfunction (a,b) {}\n```\n\nTry to keep these differences to a minimum, but don't put much thought to it either.\n\nWhere possible, improve readability by keeping lines below the 80-character mark.\n\n## Semicolons`;`\n\nThe majority of JavaScript programmers [prefer using semicolons][6]. This choice is done to avoid potential issues with Automatic Semicolon Insertion _(ASI)_. If you decide against using semicolons, [make sure you understand the ASI rules][7].\n\nRegardless of your choice, a linter should be used to catch unnecessary or unintentional semicolons.\n\n## Style Checking\n\n**Don't**. Seriously, [this is super painful][8] for everyone involved, and no observable gain is attained from enforcing such harsh policies.\n\n## Linting\n\nOn the other hand, linting is sometimes necessary. Again, don't use a linter that's super opinionated about how the code should be styled, like [`jslint`][9] is. Instead use something more lenient, like [`jshint`][10] or [`eslint`][11].\n\nA few tips when using JSHint.\n\n- Declare a `.jshintignore` file and include `node_modules`, `bower_components`, and the like\n- You can use a `.jshintrc` file like the one below to keep your rules together\n\n```json\n{\n  \"curly\": true,\n  \"eqeqeq\": true,\n  \"newcap\": true,\n  \"noarg\": true,\n  \"noempty\": true,\n  \"nonew\": true,\n  \"sub\": true,\n  \"undef\": true,\n  \"unused\": true,\n  \"trailing\": true,\n  \"boss\": true,\n  \"eqnull\": true,\n  \"strict\": true,\n  \"immed\": true,\n  \"expr\": true,\n  \"latedef\": \"nofunc\",\n  \"quotmark\": \"single\",\n  \"indent\": 2,\n  \"node\": true\n}\n```\n\nBy no means are these rules the ones you should stick to, but **it's important to find the sweet spot between not linting at all and not being super obnoxious about coding style**.\n\n## Strings\n\nStrings should always be quoted using the same quotation mark. Use `'` or `\"` consistently throughout your codebase. Ensure the team is using the same quotation mark in every portion of JavaScript that's authored.\n\n##### Bad\n\n```js\nvar message = 'oh hai ' + name + \"!\";\n```\n\n##### Good\n\n```js\nvar message = 'oh hai ' + name + '!';\n```\n\nUsually you'll be a happier JavaScript developer if you hack together a parameter-replacing method like [`util.format` in Node][12]. That way it'll be far easier to format your strings, and the code looks a lot cleaner too.\n\n##### Better\n\n```js\nvar message = util.format('oh hai %s!', name);\n```\n\nYou could implement something similar using the piece of code below.\n\n```js\nfunction format () {\n  var args = [].slice.call(arguments);\n  var initial = args.shift();\n\n  function replacer (text, replacement) {\n    return text.replace('%s', replacement);\n  }\n  return args.reduce(replacer, initial);\n}\n```\n\nTo declare multi-line strings, particularly when talking about HTML snippets, it's sometimes best to use an array as a buffer and then join its parts. The string concatenating style may be faster but it's also much harder to keep track of.\n\n```js\nvar html = [\n  '\u003cdiv\u003e',\n    format('\u003cspan class=\"monster\"\u003e%s\u003c/span\u003e', name),\n  '\u003c/div\u003e'\n].join('');\n```\n\nWith the array builder style, you can also push parts of the snippet and then join everything together at the end. This is in fact what some [string templating engines like Jade][13] prefer to do.\n\n## Variable Declaration\n\nAlways declare variables in **a consistent manner**, and at the top of their scope. Keeping variable declarations to _one per line is encouraged_. Comma-first, a single `var` statement, multiple `var` statements, it's all fine, just be consistent across the project, and ensure the team is on the same page.\n\n##### Bad\n\n```js\nvar foo = 1,\n    bar = 2;\n\nvar baz;\nvar pony;\n\nvar a\n  , b;\n```\n\n```js\nvar foo = 1;\n\nif (foo \u003e 1) {\n  var bar = 2;\n}\n```\n##### Good\n\n\u003csub\u003eJust because they're consistent with each other, not because of the style\u003c/sub\u003e\n\n```js\nvar foo = 1;\nvar bar = 2;\n\nvar baz;\nvar pony;\n\nvar a;\nvar b;\n```\n\n```js\nvar foo = 1;\nvar bar;\n\nif (foo \u003e 1) {\n  bar = 2;\n}\n```\n\nVariable declarations that aren't immediately assigned a value are acceptable to share the same line of code.\n\n##### Acceptable\n\n```js\nvar a = 'a';\nvar b = 2;\nvar i, j;\n```\n\n## Conditionals\n\n**Brackets are enforced**. This, together with a reasonable spacing strategy will help you avoid mistakes such as [Apple's SSL/TLS bug][14].\n\n##### Bad\n\n```js\nif (err) throw err;\n```\n\n##### Good\n\n```js\nif (err) { throw err; }\n```\n\nIt's even better if you avoid keeping conditionals on a single line, for the sake of text comprehension.\n\n##### Better\n\n```js\nif (err) {\n  throw err;\n}\n```\n\n## Equality\n\nAvoid using `==` and `!=` operators, always favor `===` and `!==`. These operators are called the \"strict equality operators,\" while [their counterparts will attempt to cast the operands][15] into the same value type.\n\n##### Bad\n\n```js\nfunction isEmptyString (text) {\n  return text == '';\n}\n\nisEmptyString(0);\n// \u003c- true\n```\n\n##### Good\n\n```js\nfunction isEmptyString (text) {\n  return text === '';\n}\n\nisEmptyString(0);\n// \u003c- false\n```\n\n## Ternary Operators\n\nTernary operators are fine for clear-cut conditionals, but unacceptable for confusing choices. As a rule, if you can't eye-parse it as fast as your brain can interpret the text that declares the ternary operator, chances are it's probably too complicated for its own good.\n\njQuery is a prime example of a codebase that's [**filled with nasty ternary operators**][16].\n\n##### Bad\n\n```js\nfunction calculate (a, b) {\n  return a \u0026\u0026 b ? 11 : a ? 10 : b ? 1 : 0;\n}\n```\n\n##### Good\n\n```js\nfunction getName (mobile) {\n  return mobile ? mobile.name : 'Generic Player';\n}\n```\n\nIn cases that may prove confusing just use `if` and `else` statements instead.\n\n## Functions\n\nWhen declaring a function, always use the [function declaration form][17] instead of [function expressions][18]. Because [hoisting][19].\n\n##### Bad\n\n```js\nvar sum = function (x, y) {\n  return x + y;\n};\n```\n\n##### Good\n\n```js\nfunction sum (x, y) {\n  return x + y;\n}\n```\n\nThat being said, there's nothing wrong with function expressions that are just [currying another function][20].\n\n##### Good\n\n```js\nvar plusThree = sum.bind(null, 3);\n```\n\nKeep in mind that [function declarations will be hoisted][21] to the top of the scope so it doesn't matter the order they are declared in. That being said, you should always keep functions at the top level in a scope, and avoid placing them inside conditional statements.\n\n##### Bad\n\n```js\nif (Math.random() \u003e 0.5) {\n  sum(1, 3);\n\n  function sum (x, y) {\n    return x + y;\n  }\n}\n\n```\n\n##### Good\n\n```js\nif (Math.random() \u003e 0.5) {\n  sum(1, 3);\n}\n\nfunction sum (x, y) {\n  return x + y;\n}\n```\n\n```js\nfunction sum (x, y) {\n  return x + y;\n}\n\nif (Math.random() \u003e 0.5) {\n  sum(1, 3);\n}\n```\n\nIf you need a _\"no-op\"_ method you can use either `Function.prototype`, or `function noop () {}`. Ideally a single reference to `noop` is used throughout the application.\n\nWhenever you have to manipulate an array-like object, cast it to an array.\n\n##### Bad\n\n```js\nvar divs = document.querySelectorAll('div');\n\nfor (i = 0; i \u003c divs.length; i++) {\n  console.log(divs[i].innerHTML);\n}\n```\n\n##### Good\n\n```js\nvar divs = document.querySelectorAll('div');\n\n[].slice.call(divs).forEach(function (div) {\n  console.log(div.innerHTML);\n});\n```\n\nHowever, be aware that there is a [substantial performance hit][22] in V8 environments when using this approach on `arguments`. If performance is a major concern, avoid casting `arguments` with `slice` and instead use a `for` loop.\n\n#### Bad\n```js\nvar args = [].slice.call(arguments);\n```\n\n#### Good\n```js\nvar i;\nvar args = new Array(arguments.length);\nfor (i = 0; i \u003c args.length; i++) {\n    args[i] = arguments[i];\n}\n```\n\nDon't declare functions inside of loops.\n\n##### Bad\n\n```js\nvar values = [1, 2, 3];\nvar i;\n\nfor (i = 0; i \u003c values.length; i++) {\n  setTimeout(function () {\n    console.log(values[i]);\n  }, 1000 * i);\n}\n```\n\n```js\nvar values = [1, 2, 3];\nvar i;\n\nfor (i = 0; i \u003c values.length; i++) {\n  setTimeout(function (i) {\n    return function () {\n      console.log(values[i]);\n    };\n  }(i), 1000 * i);\n}\n```\n\n##### Good\n\n```js\nvar values = [1, 2, 3];\nvar i;\n\nfor (i = 0; i \u003c values.length; i++) {\n  setTimeout(function (i) {\n    console.log(values[i]);\n  }, 1000 * i, i);\n}\n```\n\n```js\nvar values = [1, 2, 3];\nvar i;\n\nfor (i = 0; i \u003c values.length; i++) {\n  wait(i);\n}\n\nfunction wait (i) {\n  setTimeout(function () {\n    console.log(values[i]);\n  }, 1000 * i);\n}\n```\n\nOr even better, just use `.forEach` which doesn't have the same caveats as declaring functions in `for` loops.\n\n##### Better\n\n```js\n[1, 2, 3].forEach(function (value, i) {\n  setTimeout(function () {\n    console.log(value);\n  }, 1000 * i);\n});\n```\n\nWhenever a method is non-trivial, make the effort to **use a named function declaration rather than an anonymous function**. This will make it easier to pinpoint the root cause of an exception when analyzing stack traces.\n\n##### Bad\n\n```js\nfunction once (fn) {\n  var ran = false;\n  return function () {\n    if (ran) { return };\n    ran = true;\n    fn.apply(this, arguments);\n  };\n}\n```\n\n##### Good\n\n```js\nfunction once (fn) {\n  var ran = false;\n  return function run () {\n    if (ran) { return };\n    ran = true;\n    fn.apply(this, arguments);\n  };\n}\n```\n\nAvoid keeping indentation levels from raising more than necessary by using guard clauses instead of flowing `if` statements.\n\n##### Bad\n\n```js\nif (car) {\n  if (black) {\n    if (turbine) {\n      return 'batman!';\n    }\n  }\n}\n```\n\n```js\nif (condition) {\n  // 10+ lines of code\n}\n```\n\n##### Good\n\n```js\nif (!car) {\n  return;\n}\nif (!black) {\n  return;\n}\nif (!turbine) {\n  return;\n}\nreturn 'batman!';\n```\n\n```js\nif (!condition) {\n  return;\n}\n// 10+ lines of code\n```\n\n## Prototypes\n\nHacking native prototypes should be avoided at all costs, use a method instead. If you must extend the functionality in a native type, try using something like [poser][23] instead.\n\n##### Bad\n\n```js\nString.prototype.half = function () {\n  return this.substr(0, this.length / 2);\n};\n```\n\n##### Good\n\n```js\nfunction half (text) {\n  return text.substr(0, text.length / 2);\n}\n```\n\n**Avoid prototypical inheritance models** unless you have a very good _performance reason_ to justify yourself.\n\n- Prototypical inheritance boosts puts need for `this` through the roof\n- It's way more verbose than using plain objects\n- It causes headaches when creating `new` objects\n- Needs a closure to hide valuable private state of instances\n- Just use plain objects instead\n\n## Object Literals\n\nInstantiate using the egyptian notation `{}`. Use factories instead of constructors, here's a proposed pattern for you to implement objects in general.\n\n```js\nfunction util (options) {\n  // private methods and state go here\n  var foo;\n\n  function add () {\n    return foo++;\n  }\n\n  function reset () { // note that this method isn't publicly exposed\n    foo = options.start || 0;\n  }\n\n  reset();\n\n  return {\n    // public interface methods go here\n    uuid: add\n  };\n}\n```\n\n## Array Literals\n\nInstantiate using the square bracketed notation `[]`. If you have to declare a fixed-dimension array for performance reasons then it's fine to use the `new Array(length)` notation instead.\n\nIt's about time you master array manipulation! [Learn about the basics][24]. It's way easier than you might think.\n\n- [`.forEach`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach)\n- [`.slice`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice)\n- [`.splice`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/splice)\n- [`.join`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/join)\n- [`.concat`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/concat)\n- [`.unshift`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/unshift)\n- [`.shift`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/shift)\n- [`.push`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/push)\n- [`.pop`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/pop)\n\nLearn and abuse the functional collection manipulation methods. These are **so** worth the trouble.\n\n- [`.filter`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/filter)\n- [`.map`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/map)\n- [`.reduce`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/reduce)\n- [`.reduceRight`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/reduceRight)\n- [`.some`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/some)\n- [`.every`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/every)\n- [`.sort`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/sort)\n- [`.reverse`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/reverse)\n\n## Regular Expressions\n\nKeep regular expressions in variables, don't use them inline. This will vastly improve readability.\n\n##### Bad\n\n```js\nif (/\\d+/.test(text)) {\n  console.log('so many numbers!');\n}\n```\n\n##### Good\n\n```js\nvar numeric = /\\d+/;\nif (numeric.test(text)) {\n  console.log('so many numbers!');\n}\n```\n\nAlso [learn how to write regular expressions][25], and what they actually do. Then you can also [visualize them online][26].\n\n## `console` statements\n\nPreferably bake `console` statements into a service that can easily be disabled in production. Alternatively, don't ship any `console.log` printing statements to production distributions.\n\n## Comments\n\nComments **aren't meant to explain what** the code does. Good **code is supposed to be self-explanatory**. If you're thinking of writing a comment to explain what a piece of code does, chances are you need to change the code itself. The exception to that rule is explaining what a regular expression does. Good comments are supposed to **explain why** code does something that may not seem to have a clear-cut purpose.\n\n##### Bad\n\n```js\n// create the centered container\nvar p = $('\u003cp/\u003e');\np.center(div);\np.text('foo');\n```\n\n##### Good\n\n```js\nvar container = $('\u003cp/\u003e');\nvar contents = 'foo';\ncontainer.center(parent);\ncontainer.text(contents);\nmegaphone.on('data', function (value) {\n  container.text(value); // the megaphone periodically emits updates for container\n});\n```\n\n```js\nvar numeric = /\\d+/; // one or more digits somewhere in the string\nif (numeric.test(text)) {\n  console.log('so many numbers!');\n}\n```\n\nCommenting out entire blocks of code _should be avoided entirely_, that's why you have version control systems in place!\n\n## Variable Naming\n\nVariables must have meaningful names so that you don't have to resort to commenting what a piece of functionality does. Instead, try to be expressive while succinct, and use meaningful variable names.\n\n##### Bad\n\n```js\nfunction a (x, y, z) {\n  return z * y / x;\n}\na(4, 2, 6);\n// \u003c- 3\n```\n\n##### Good\n\n```js\nfunction ruleOfThree (had, got, have) {\n  return have * got / had;\n}\nruleOfThree(4, 2, 6);\n// \u003c- 3\n```\n\n## Polyfills\n\nWhere possible use the native browser implementation and include [a polyfill that provides that behavior][27] for unsupported browsers. This makes the code easier to work with and less involved in hackery to make things just work.\n\nIf you can't patch a piece of functionality with a polyfill, then [wrap all uses of the patching code][28] in a globally available method that is accessible from everywhere in the application.\n\n## Everyday Tricks\n\nUse `||` to define a default value. If the left-hand value is [falsy][29] then the right-hand value will be used. Be advised, that because of loose type comparison, inputs like `false`, `0`, `null` or `''` will be evaluated as falsy, and converted to default value. For strict type checking use `if (value === void 0) { value = defaultValue }`.\n\n```js\nfunction a (value) {\n  var defaultValue = 33;\n  var used = value || defaultValue;\n}\n```\n\nUse `.bind` to [partially-apply][30] functions.\n\n```js\nfunction sum (a, b) {\n  return a + b;\n}\n\nvar addSeven = sum.bind(null, 7);\n\naddSeven(6);\n// \u003c- 13\n```\n\nUse `Array.prototype.slice.call` to cast array-like objects to true arrays.\n\n```js\nvar args = Array.prototype.slice.call(arguments);\n```\n\nUse [event emitters][31] on all the things!\n\n```js\nvar emitter = contra.emitter();\n\nbody.addEventListener('click', function () {\n  emitter.emit('click', e.target);\n});\n\nemitter.on('click', function (elem) {\n  console.log(elem);\n});\n\n// simulate click\nemitter.emit('click', document.body);\n```\n\nUse `Function()` as a _\"no-op\"_.\n\n```js\nfunction (cb) {\n  setTimeout(cb || Function(), 2000);\n}\n```\n\n## License\n\nMIT\n\n\u003e Fork away!\n\n# }\n\n\n  [1]: http://wiki.commonjs.org/wiki/CommonJS\n  [2]: http://requirejs.org/docs/whyamd.html\n  [3]: http://eviltrout.com/2014/05/03/getting-started-with-es6.html\n  [4]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions_and_function_scope/Strict_mode\n  [5]: http://editorconfig.org\n  [6]: http://dailyjs.com/2012/12/24/817-javascript-survey-results\n  [7]: http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding\n  [8]: https://github.com/jscs-dev/node-jscs\n  [9]: http://www.jslint.com/\n  [10]: https://github.com/jshint/jshint/\n  [11]: https://github.com/eslint/eslint\n  [12]: http://nodejs.org/api/util.html#util_util_format_format\n  [13]: https://github.com/jadejs/jade\n  [14]: https://www.imperialviolet.org/2014/02/22/applebug.html\n  [15]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comparison_Operators\n  [16]: https://github.com/jquery/jquery/blob/c869a1ef8a031342e817a2c063179a787ff57239/src/ajax.js#L117\n  [17]: http://stackoverflow.com/q/336859/389745\n  [18]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/function\n  [19]: https://github.com/buildfirst/buildfirst/tree/master/ch05/04_hoisting\n  [20]: http://ejohn.org/blog/partial-functions-in-javascript/\n  [21]: https://github.com/buildfirst/buildfirst/tree/master/ch05/04_hoisting\n  [22]: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers#3-managing-arguments\n  [23]: https://github.com/bevacqua/poser\n  [24]: https://ponyfoo.com/articles/fun-with-native-arrays\n  [25]: https://ponyfoo.com/articles/learn-regular-expressions\n  [26]: http://www.regexper.com/#%2F%5Cd%2B%2F\n  [27]: https://remysharp.com/2010/10/08/what-is-a-polyfill\n  [28]: https://ponyfoo.com/articles/building-high-quality-front-end-modules\n  [29]: http://james.padolsey.com/javascript/truthy-falsey/\n  [30]: http://ejohn.org/blog/partial-functions-in-javascript/\n  [31]: https://github.com/bevacqua/contra#%CE%BBemitterthing-options\n  [32]: https://github.com/bevacqua/css\n  [33]: https://github.com/bevacqua/js/issues\n","funding_links":[],"categories":["Others","JavaScript","Uncategorized"],"sub_categories":["Sass","Uncategorized"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbevacqua%2Fjs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbevacqua%2Fjs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbevacqua%2Fjs/lists"}