{"id":15920046,"url":"https://github.com/alexdiliberto/code-conventions","last_synced_at":"2026-04-12T23:52:30.018Z","repository":{"id":10725277,"uuid":"12977346","full_name":"alexdiliberto/code-conventions","owner":"alexdiliberto","description":"This is my HTML/CSS code conventions document aggregated from various sources.","archived":false,"fork":false,"pushed_at":"2017-07-21T05:03:49.000Z","size":30,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-08-25T22:31:27.276Z","etag":null,"topics":["conventions","css-resources","css-styles","emberjs","javascript","js-resources"],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"malbrecht/chess","license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/alexdiliberto.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}},"created_at":"2013-09-20T15:43:09.000Z","updated_at":"2017-08-02T15:09:58.000Z","dependencies_parsed_at":"2022-09-15T20:11:08.554Z","dependency_job_id":null,"html_url":"https://github.com/alexdiliberto/code-conventions","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/alexdiliberto/code-conventions","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexdiliberto%2Fcode-conventions","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexdiliberto%2Fcode-conventions/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexdiliberto%2Fcode-conventions/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexdiliberto%2Fcode-conventions/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/alexdiliberto","download_url":"https://codeload.github.com/alexdiliberto/code-conventions/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexdiliberto%2Fcode-conventions/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31734350,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-12T22:19:12.206Z","status":"ssl_error","status_checked_at":"2026-04-12T22:18:33.088Z","response_time":58,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"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":["conventions","css-resources","css-styles","emberjs","javascript","js-resources"],"created_at":"2024-10-06T19:20:45.703Z","updated_at":"2026-04-12T23:52:29.996Z","avatar_url":"https://github.com/alexdiliberto.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Alex's Code Conventions\n*Last Updated: July 20, 2017 12:08 AM*\n\n## Forward\n\nThis document contains a very detailed outline of my most important JavaScript and CSS code conventions in a [Style Guide](http://styleguides.io/) format.\n\nWhen each member of the team is collaborating on a project, we are all likely developing separate pieces of code. Ideally, each of those separate pieces of code should uniformly look and behave in such a way that they were produced by a single developer. There are many reasons behind this belief system:\n\n- Easier to read and quickly inspect\n- Uniform patterns allow others to quickly understand basic flow, meaning, and functionality\n- The long-term value of software to an organization is in direct proportion to the quality of the codebase.\n- Neatness counts\n\n\n## Table of Contents\n\n[Ember JS](#ember-js)\n\n  1. [General Ember Conventions](#general-ember-conventions)\n  1. [Local Variables and Prototype Extensions](#local-variables-and-prototype-extensions)\n  1. [Property Brace Expansion](#property-brace-expansion)\n  1. [Super](#super)\n  1. [Override Init](#override-init)\n  1. [Observers](#observers)\n  1. [Organizing Modules](#organizing-modules)\n  1. [Run Loop](#run-loop)\n  1. [Controllers](#controllers)\n  1. [Templates](#templates)\n  1. [Routing](#routing)\n  \n[Git](#git)\n\n  1. [Creating Feature Branches](#creating-feature-branches)\n  1. [Commit Contents](#commit-contents)\n  1. [Commit Messages](#commit-messages)\n  1. [Example Bug Workflow](#example-bug-workflow)\n\n[Text Editor](#text-editor)\n\n  1. [Atom](#atom)\n  1. [Sublime Text](#sublime-text)\n  1. [VIM](#vim)\n\n[Javascript](#javascript)\n\n  1. [JS Style](#js-style)\n  1. [JS Naming](#js-naming)\n  1. [Variable Declarations](#variable-declarations)\n  1. [Function Declarations](#function-declarations)\n  1. [Primitive Literals](#primitive-literals)\n  1. [Operator Spacing](#operator-spacing)\n  1. [Object Literals](#object-literals)\n  1. [Comment Annotations](#comment-annotations)\n  1. [JS Rules of Thumb](#js-rules-of-thumb)\n\n[CSS](#css)\n\n  1. [CSS Style](#css-style)\n  1. [File Structure](#css-file-structure)\n  1. [CSS Naming](#css-naming)\n  1. [CSS Rules of Thumb](#css-rules-of-thumb)\n\n[HTML](#html)\n\n  1. [Indentation and Line Breaks](#indentation-and-line-breaks)\n  1. [Escaping Characters](#escaping-characters)\n  1. [Smart Quotes](#smart-quotes)\n\n[Resources](#resources)\n\n  1. [JS Resources](#js-resources)\n  1. [CSS Resources](#css-resources)\n\n## Ember JS\n\n### General Ember Conventions\n * Follow all project naming, structure and layout conventions as outlined in the [Ember CLI documentation](https://ember-cli.com/user-guide/#naming-conventions).\n * Always leverage Ember CLI's [eslint-plugin-ember](https://github.com/ember-cli/eslint-plugin-ember) for proper linter support. If you are using the [Atom](https://atom.io/) text editor you should use the [AtomLinter/linter-eslint](https://github.com/AtomLinter/linter-eslint) plugin to automatically apply `eslint --fix` on file save.\n * For a safer accessor, use `Ember.set(foo, 'bar', 'baz')` and `Ember.get(foo, 'bar')` instead of `foo.set('bar', 'baz')` or `foo.get('bar')`. See the [following response by Ember core team member Stef Penner](https://www.reddit.com/r/emberjs/comments/3mr5as/question_why_use_embergetthis_prop_instead_of/cvhkaka) for more information.\n * Always use Ember's [Javascript modules API syntax](https://github.com/emberjs/rfcs/pull/176) for importing values from modules. This allows Ember to leverage static analysis to eliminate unneeded code and  ship less bytes down to the client. This also helps speed up Javascript parsing and evaluating time on the client.\n * Prefer to use the the `Ember` implementation over raw javascript when possible. Example:\n \n\n```javascript\n  // GOOD - Using safe `Ember.get()` and `Ember.set()` accessors\n  // GOOD - Using Ember's Javascript modules API\n  // GOOD - Using `Ember.getWithDefault` and `Ember.isNone` instead of raw javascript\n  import Component from \"@ember/component\";\n  import { get, computed, getWithDefault } from \"@ember/object\";\n  import { isNone } from \"@ember/utils\";\n\n  export default Component.extend({\n    foo: 'bar',\n\n    fiz: computed('foo', {\n      get() {\n        // If `get(this, 'foo') === undefined` then return '', else return `get(this, 'foo')`\n        return getWithDefault(this, 'foo', '');\n      }\n    }),\n\n    qux: computed('foo', {\n      // Returns `true` if the passed value is `null` or `undefined`\n      get() {\n        return isNone(get(this, 'foo'));\n      }\n    })\n  });\n\n  //////////////////////////////////////////////////////////////////\n\n  // BAD - Using `\u003cinstance\u003e.get` and `\u003cinstance\u003e.set`\n  // BAD - Using globally destructured `Ember`\n  // BAD - Not using `Ember` specific APIs where you are able\n  const {\n    Component,\n    computed\n  } = Ember;\n\n  export default Component.extend({\n    foo: 'bar',\n\n    fiz: computed('foo', function() {\n      return this.get('foo') || '';\n    }),\n\n    qux: computed('foo', function() {\n      const foo = this.get('foo');\n      return foo === null || foo === undefined;\n    })\n  });\n```\n\n * [Don't declare arrays or objects directly on Components](https://poteto.github.io/component-best-practices/#/leaky). Instead, add them on init. This is so we can ensure that each instance of the Component has its own independent state.\n * [Don't introduce side-effects in computed properties](https://github.com/ember-best-practices/eslint-plugin-ember-best-practices/blob/master/guides/rules/no-side-effect-cp.md#no-computed-property-side-effects). It will make reasoning about the origin of the change much harder and invalidates proper data flow throughout an Ember application. Data should flows down from the route and send actions back up to modify that data -- where the child does not actually own the data.\n\n```javascript\n  import Component from \"@ember/component\"\n  import { filterBy, alias } from \"@ember/object/computed\";\n\n  export default Component.extend({\n    // GOOD: Don't declare arrays or objects directly on Components\n    // GOOD: Override init\n    // GOOD: Don't forget `_super()`\n    init() {\n      this._super(...arguments);\n      \n      set(this, 'users', [\n        { name: 'Foo', age: 15 },\n        { name: 'Bar', age: 16 },\n        { name: 'Baz', age: 15 }\n      ]);\n    },\n\n    // GOOD:\n    fifteen: filterBy('users', 'age', 15),\n    fifteenAmount: alias('fifteen.length'),\n\n    //////////////////////////////////////////////////////////////////\n\n    // BAD\n    fifteenAmount: 0,\n    fifteen: computed('users', function() {\n      const fifteen = this.get('users').filterBy('items', 'age', 15);\n      this.set('fifteenAmount', fifteen.length); // SIDE EFFECT!\n      return fifteen;\n    })\n  });\n```\n\n * [Don't use `sendAction()`](https://dockyard.com/blog/2015/10/29/ember-best-practice-stop-bubbling-and-use-closure-actions). Use [closure actions](https://alexdiliberto.com/posts/ember-closure-actions/) instead of bubbling actions via `sendAction()`. Ember's primary [action handling method changed after release v1.13](https://emberjs.com/blog/2015/06/12/ember-1-13-0-released.html#toc_closure-actions) with the introduction of closure actions. This change allows for a simpler paradigm where the action caller (child component for example) simply executes the passed-in \"action\" function with the proper context. This allows us to leverage some powerful techniques such as currying and passing back down return values after asynchronous action handlers finish executing on the route or controller.\n \n### Local Variables and Prototype Extensions\nAvoid using Ember's prototype extension syntax and instead prefer using corresponding functions from the Ember object. Create local variables from the Ember namespace.\n\n```javascript\n  // GOOD - Avoids using prototype extensions\n  import Component from \"@ember/component\";\n  import { computed } from \"@ember/object\";\n  import { alias } from \"@ember/object/computed\";\n  import { on } from \"@ember/object/evented\";\n\n  export default Component.extend({\n    first: alias('firstName'),\n    last: alias('lastName'),\n\n    fullName: computed('first', 'last', {\n      get() {\n        /* Code */\n      }\n    }),\n\n    sayHello: on('didInsertElement', {\n      get() {\n        /* Code */\n      }\n    })\n  });\n  \n  //////////////////////////////////////////////////////////////////\n\n  // BAD - Using prototype extensions\n  // BAD - Using global `Ember` import\n  import Ember from 'ember';\n  \n  export default Ember.Component.extend({\n    first: Ember.computed.alias('firstName'),\n    last: Ember.computed.alias('lastName'),\n\n    fullName: function() {\n      /* Code */\n    }).property('first', 'last'),\n\n    sayHello: function() {\n      /* Code */\n    }).on('didInsertElement')\n  });\n```\n\n### Property Brace Expansion\nAlways prefer to use Ember's property brace expansion for computed property dependent keys. This will help improve readability and it provides less redundancy overall. The dependent keys must be together (**without space**) for the brace expansion to properly work.\n\n```javascript\n  // GOOD - Using property brace expansion\n  fullName: computed('user.{firstName,lastName}', {\n    // Code\n  })\n\n  //////////////////////////////////////////////////////////////////\n\n  // BAD - Not using property brace expansion\n  fullName: computed('user.firstName', 'user.lastName', {\n    // Code\n  })\n```\n\n### Super\n[Don't forget `_super()`](https://poteto.github.io/component-best-practices/#/super). When overriding framework methods, always call `this._super(...arguments);`. This is necessary because certain methods need to setup certain things, and overriding them without a `super` call will prevent that, leading to unexpected behavior.\n\n### Override Init\n[Override init](https://dockyard.com/blog/2015/10/19/2015-dont-dont-override-init). Rather than using the object's init hook via `Ember.on()`, override init and call `_super` with `...arguments`. This allows you to control execution order.\n\n```javascript\n  // GOOD - Overriding `init()`\n  init() {\n    this._super(...arguments);\n    \n    this.foo();\n    this.bar();\n    this.baz();\n  });\n\n  //////////////////////////////////////////////////////////////////\n\n  // BAD\n  foo: on('init', () =\u003e {\n    // ...\n  }),\n  bar: on('init', () =\u003e {\n    // ...\n  }),\n  baz: on('init', () =\u003e {\n    // ...\n  })\n```\n\n### Observers\n[Never use observers](https://github.com/ember-best-practices/eslint-plugin-ember-best-practices/blob/master/guides/rules/no-observers.md#no-observers). Usage of observers is very easy *BUT* it leads to hard to reason about consequences. Since observers eagerly compute we have these possible times period when data within the application is not actually \"correct\" or what you would expect. When we introduce many observers into an application this problem compounds on itself. Unless observers are necessary, it's better to avoid them. See the following video for more information: [Observer Tip Jar by Stef Penner](https://www.youtube.com/watch?v=7PUX27RKCq0)\n\n```handlebars\n {{input value=text key-up=\"change\"}}\n```\n\n```javascript\n  // GOOD\n  // `{{input value=text key-up=\"change\"}}`\n  import Controller from \"@ember/controller\";\n  import { get } from \"@ember/object\"\n\n  export default Controller.extend({\n    actions: {\n      change() {\n        console.log(`change detected: ${get(this, 'text')}`);\n      },\n    },\n  });\n\n  //////////////////////////////////////////////////////////////////\n\n  // BAD\n  // `{{input value=text}}`\n  export default Ember.Model.extend({\n    change: Ember.observer('text', function() {\n      console.log(`change detected: ${get(this, 'text')}`);\n    })\n  });\n```\n\n### Organizing Modules\nLeverage Ember CLI's [eslint-plugin-ember](https://github.com/ember-cli/eslint-plugin-ember) addon for a great set of configurable rules for proper organization within [components](https://github.com/ember-cli/eslint-plugin-ember/blob/v3.6.2/lib/rules/order-in-components.js), [controllers](https://github.com/ember-cli/eslint-plugin-ember/blob/v3.6.2/lib/rules/order-in-controllers.js), [models](https://github.com/ember-cli/eslint-plugin-ember/blob/v3.6.2/lib/rules/order-in-models.js), and [routes](https://github.com/ember-cli/eslint-plugin-ember/blob/v3.6.2/lib/rules/order-in-routes.js)\n \nComponents: \n  1. Services\n  1. Default values\n  1. Single line computed properties\n  1. Multiline computed properties\n  1. Observers\n  1. Lifecycle Hooks\n  1. Actions\n  1. Custom / private methods\n\nControllers:\n  1. Services\n  1. Query params\n  1. Default controller's properties\n  1. Custom properties\n  1. Single line computed properties\n  1. Multi line computed properties\n  1. Observers\n  1. Actions\n  1. Custom / private methods\n\nModels:\n  1. Attributes\n  1. Relations\n  1. Single line computed properties\n  1. Multiline computed properties\n  1. Other structures (custom methods etc.)\n\nRoutes:\n  1. Services\n  1. Default route's properties\n  1. Custom properties\n  1. model() hook\n  1. Other route's methods (beforeModel etc.)\n  1. Actions\n  1. Custom / private methods\n\n```javascript\n  // GOOD - Component module organization follows best practices\n  // 1. Services\n  // 2. Default values\n  // 3. Single line computed properties\n  // 4. Multiline computed properties\n  // 5. Observers\n  // 6. Lifecycle Hooks\n  // 7. Actions\n  // 8. Custom / private methods\n  import Component from \"@ember/component\";\n  import { computed } from \"@ember/object\";\n  import { alias } from \"@ember/object/computed\";\n  import { inject } from \"@ember/service\"\n  \n  export default Component.extend({\n    // 1. Services\n    i18n: inject(),\n\n    // 2. Defaults\n    role: 'sloth',\n\n    // 3. Single line Computed Property\n    vehicle: alias('car'),\n\n    // 4. Multiline Computed Property\n    levelOfHappiness: computed('attitude', 'health', {\n      get() {\n        let result = get(this, 'attitude') * get(this, 'health') * Math.random();\n        return result;  \n      }\n    }),\n\n    // 6. Lifecycle Hooks\n    init() {\n      this._super(...arguments);\n      \n      this._secretMethod();\n    },\n    \n    // 7. All actions\n    actions: {\n      sneakyAction() {\n        return this._secretMethod();\n      }\n    },\n\n    // 8. Custom / private methods\n    _secretMethod() {\n      // custom secret method logic\n    }\n  });\n```\n\n### Run Loop\nNever use `jQuery` without the [Ember Run Loop](https://github.com/eoinkelly/ember-runloop-handbook). Using plain `jQuery` invokes actions out of the Ember Run Loop. In order to have a control on all operations in Ember it's good practice to trigger actions in run loop.\n\n```javascript\n  // GOOD\n  import $ from \"jquery\";\n  import { bind } from \"@ember/runloop\";\n\n  $('#something-rendered-by-jquery-plugin').on(\n    'click',\n    bind(this, this._handlerActionFromController)\n  );\n\n  //////////////////////////////////////////////////////////////////\n\n  // BAD\n  Ember.$('#something-rendered-by-jquery-plugin').on('click', () =\u003e {\n    this._handlerActionFromController();\n  });\n```\n\n### Controllers\n * [Don't not use controllers](https://dockyard.com/blog/2017/06/16/ember-best-practices-what-are-controllers-good-for)\n * Follow the recommended organization within [controllers](https://github.com/ember-cli/eslint-plugin-ember/blob/v3.6.2/lib/rules/order-in-controllers.js).\n * Never use `ObjectController` or `ArrayController`; simply use `Controller`.\n * Alias your model. It provides a cleaner code, it is more maintainable, and will align well with future routable components within Ember.\n\n```javascript\n  // GOOD - Alias your model\n  import Controller from \"@ember/controller\";\n  \n  export default Controller.extend({\n    user: alias('model')\n  });\n```\n\n### Templates\n * Never use partials. Always use components instead. Partials share scope with the parent view and components will provide a consistent scope.\n * Use new block syntax \n\n```handlebars\n  {{! GOOD }}\n  {{#each posts as |post|}}\n\n  {{! BAD - Using old non-block syntax}}\n  {{#each post in posts}}\n```\n\n * Use components in `{{#each}}` blocks. Contents of your each blocks should ideally be a single line. This will allow you to test the contents in isolation via unit tests, as your loop will likely contain more complex logic in this case.\n\n```handlebars\n  {{! GOOD }}\n  {{#each posts as |post|}}\n    {{post-summary post=post}}\n  {{/each}}\n\n  {{! BAD - Should be extracted out into a component }}\n  {{#each posts as |post|}}\n    \u003carticle\u003e\n      \u003cimg src={{post.image}} /\u003e\n      \u003ch1\u003e{{post.title}}\u003c/h2\u003e\n      \u003cp\u003e{{post.summary}}\u003c/p\u003e\n    \u003c/article\u003e\n  {{/each}}\n```\n\n * Prefer double quotes to single quotes in **templates only**\n\n```handlebars\n  {{! GOOD }}\n  \u003cbutton {{action \"doThing\"}}\u003eDo Thing\u003c/button\u003e\n\n  {{! BAD }}\n  \u003cbutton {{action 'doThing'}}\u003eDo Thing\u003c/button\u003e\n```\n\n * Multi-line expressions should specify attributes starting on the second line, and should be indented one deeper than the start of the component or helper name.\n\n```handlebars\n  {{! GOOD }}\n  {{x-thing\n      value=blah\n      options=options\n      label=\"thing\"}}\n\n  {{! BAD }}\n  {{x-thing\n    value=blah\n    options=options\n    label=\"thing\"}}\n\n  {{! BAD - This will be annoying to re-indent if you rename your component }}\n  {{x-thing value=blah\n            options=options\n            label=\"thing\"}}\n```\n\n### Routing\n * [Dynamic segments](https://guides.emberjs.com/v2.14.0/routing/defining-your-routes/#toc_dynamic-segments) should be underscored. This will allow Ember to resolve promises without extra serialization work.\n\n```javascript\n  // GOOD\n  this.route('foo', { path: ':foo_id' });\n\n  //////////////////////////////////////////////////////////////////\n\n  // BAD\n  this.route('foo', { path: ':fooId' });\n```\n\n## Git\nUse the [Gitflow Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow-workflow) model.\n\n### Creating Feature Branches\n```bash\n# Start the feature\ngit checkout -b feature/my-new-feature\n\n# Sync a copy of the branch on the remote server\ngit push -u origin feature/my-new-feature\n\n# Make individual atomic commits then push\ngit commit\ngit commit\ngit commit\n# ...\ngit push\n\n# For completing a feature get the most recent version of all the code.\ngit pull\n\n# Merge the develop branch into the feature branch to make sure that nothing is outdated\ngit merge develop\n\n# Finish the feature and Create PR\ngit push\n\n# After the feature is merged, delete and prune the remote branch\ngit push origin --delete feature/my-new-feature\ngit remote prune origin\n```\n\n### Commit Contents\n- Every commit should be constrained to a single piece of functionality and its dependencies. (Atomicity)\n- Find good points in the development process to pause and commit pieces of your effort – a good rule of thumb is that any time you feel pleased that you're making progress you should commit your changes.\n- Don't make changes to unrelated functionality inside of a single commit.\n- If you encounter a bug when developing a new feature or another issue that needs to be addressed you can follow the example below.\n\n### Commit Messages\nWrite [good commit messages](http://robots.thoughtbot.com/post/48933156625/5-useful-tips-for-a-better-commit-message). Every commit message should explain in detail what it is the commit is trying to accomplish. The people reviewing the commit should be able to identify whether or not they should be the person reviewing it based solely upon the commit message.\n\nThis means that you should include:\n\n- What types of functionality you worked on (JS, CSS, HBS). This doesn't have to be explicit, \"update the login route event handler\" would work to identify that you worked on JS.\n- Explanations of why you used that particular approach to solve the problem, if necessary.\n- A brief description of next steps if there is additional work that needs to be done.\n- Do not remove default populated contents from commit messages. For example, merge commits will by default say what branch it was and what conflicts occurred during the merge.\n\n### Example Bug Workflow\n```bash\n# Store your current working state in your feature branch\ngit stash save \"currently working on foo\"\n\n# Move to the develop branch or a feature branch to address the issue\ngit checkout develop\n\n# Fix Code and Commit the change\ngit add my-fix.js\ngit commit\n\n# Write a good commit message.\n\n# Push the new version to the origin server.\ngit push\n\n# Get back to what it is you were working on.\ngit checkout feature/feature-name\n\n# If you need the fix in your current branch in order to move forward.\ngit merge develop\n\n# Add back your work in progress.\ngit stash pop\n```\n\n## Text Editor\nChoose your favorite text editor. Some great options include:\n\n - [Atom](https://atom.io/) (*my personal favorite*)\n - [Sublime Text](https://www.sublimetext.com/)\n - [VIM](http://www.vim.org/)\n\n### Atom\nFor Atom users, I'm including my base `config.cson` file located at `~/.atom/config.cson`:\n\n```json\n\"*\":\n  core:\n    telemetryConsent: \"no\"\n    themes: [\n      \"atom-dark-ui\"\n      \"monokai\"\n    ]\n    whitespace:\n      removeTrailingWhitespace: false\n  editor:\n    fontFamily: \"Menlo\"\n    fontSize: 14\n    invisibles: {}\n    nonWordCharacters: \"/\\\\()\\\"':,.;\u003c\u003e~!@#$%^\u0026*|+=[]{}`?…\"\n    preferredLineLength: 120\n    showIndentGuide: true\n    softWrap: true\n    softWrapAtPreferredLineLength: true\n  \"exception-reporting\":\n    userId: \"884440fb-9e84-fcf9-8239-ecee423c921e\"\n  \"linter-eslint\":\n    fixOnSave: true\n  \"linter-ui-default\":\n    panelHeight: 81\n  welcome:\n    showOnStartup: false\n```\n\n### Sublime Text\nFor Sublime Text 2 users, I'm including a nice starting point for your user-specific `Preferences.sublime-settings` file:\n\n```json\n{\n  \"auto_complete_commit_on_tab\": true,\n  \"bold_folder_labels\": true,\n  \"color_scheme\": \"Packages/Color Scheme - Default/Monokai.tmTheme\",\n  \"default_encoding\": \"UTF-8\",\n  \"default_line_ending\": \"unix\",\n  \"detect_indentation\": false,\n  \"draw_minimap_border\": true,\n  \"draw_white_space\": \"all\",\n  \"ensure_newline_at_eof_on_save\": true,\n  \"file_exclude_patterns\":\n  [\n    \".DS_Store\",\n    \"Desktop.ini\",\n    \"*.pyc\",\n    \"._*\",\n    \"Thumbs.db\",\n    \".Spotlight-V100\",\n    \".Trashes\"\n  ],\n  \"folder_exclude_patterns\":\n  [\n    \".git\"\n  ],\n  \"font_size\": 13,\n  \"highlight_line\": true,\n  \"highlight_modified_tabs\": true,\n  \"hot_exit\": false,\n  \"ignored_packages\":\n  [\n    \"Vintage\"\n  ],\n  \"match_brackets\": true,\n  \"match_brackets_angle\": true,\n  \"open_files_in_new_window\": false,\n  \"remember_open_files\": true,\n  \"rulers\":\n  [\n    120\n  ],\n  \"save_on_focus_lost\": true,\n  \"shift_tab_unindent\": true,\n  \"show_encoding\": true,\n  \"show_line_endings\": true,\n  \"tab_size\": 2,\n  \"translate_tabs_to_spaces\": true,\n  \"trim_trailing_white_space_on_save\": true,\n  \"word_separators\": \"./\\\\()\\\"':,.;\u003c\u003e~!@#$%^\u0026*|+=[]{}`~?\",\n  \"word_wrap\": true,\n  \"wrap_width\": 120\n}\n```\n\n### VIM\nFor VIM users, the following is a great learning resource:\n\n[Vim Adventures](http://vim-adventures.com/)\n\n## JavaScript\n\n### JS Style\n- Use soft-tabs with a **2** space indent.\n- Be generous with well-written and clear comments.\n- Each line should be no longer than **120** characters.\n  - Using *Sublime Text 2*, you can enforce this rule visually with a vertical ruler at 120 characters by customizing your **User Settings** file. *(Shown above greater detail below in the `Sublime Text 2` section)*\n\n### JS Naming\n- For variables and functions, names should be limited to alphanumeric characters and, in some cases, the underscore character.\n  - Do **NOT** use: the dollar sign (\"$\") in any names.\n- Variable names should be formatted in camel case.\n- The first word of a boolean variable name will be \"is\".\n- The first word of a variable name should be a noun (not a verb).\n\n```javascript\n  // GOOD\n  const accountNumber = \"8401-1\";\n\n  // BAD - Not camel case\n  const AccountNumber = \"8401-1\";\n  const account_number = \"8401-1\";\n\n  // BAD - Begins with a verb\n  const getAccountNumber = \"8401-1\";\n```\n\n- Function names should also be formatted using camel case.\n- The first word of a function should be a verb (not a noun).\n\n```javascript\n  // GOOD\n  function doSomething() {\n    // code\n  }\n\n  // BAD - Not camel case\n  function Do_Something() {\n    // code\n  }\n\n  // BAD - Begins with a noun\n  function car() {\n    // code\n  }\n```\n\n### Variable Declarations\n- Never use `var`. Prefer [`let`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let) to declare a block scope local variable. Use [`const`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const) to declare a constant whose value can not be re-assigned in the given scope (global or local).\n\n```javascript\n  // GOOD\n  const car = new Mustang();\n\n  // BAD - Global variable\n  car = new Mustang();\n```\n\n- All variables should be declared before used.\n- Always use one `const` declaration per variable.\n\n```javascript\n  // GOOD\n  const store;\n  const count = 10;\n  const name  = \"Alex\";\n  const found = false;\n  const empty;\n\n  // BAD - One `const` for multiple variables (much harder to spot global variable errors)\n  const store,\n      count = 10,\n      name  = \"Alex\",\n      found = false;\n      empty;\n\n  // BAD - Improper initialization alignment, Incorrect indentation\n  const count       =10;\n  const name = \"Alex\";\n  const found  =    false;\n  const empty;\n\n  // BAD - Multiple declarations on one line\n  const count = 10;\n  const name  = \"Alex\";\n  const found = false, empty;\n```\n\n- Keep variable declarations as the first statements of a function's body.\n- Group `const` declarations, then group `let` declarations\n- Never initialize a variable to `null` if it does not have an initial value. In this case you will **ONLY** declare the variable.\n\n```javascript\n  // GOOD\n  const hogwarts = \"Hogwarts School of Witchcraft and Wizardry\";\n  const Gryffindor = \"Gryffindor\";\n  const Slytherin = \"Slytherin\";\n  let quidditchMatchTime = new Date();\n  let i;\n  let length;\n  \n  // BAD - Improper Alignment. Multiple variables declared per line.\n  const hogwarts = \"Hogwarts School of Witchcraft and Wizardry\", Gryffindor = \"Gryffindor\", Slytherin = \"Slytherin\";\n  let quidditchMatchTime = new Date(),\n    i;\n  let length;\n  \n  // BAD - Not using `const` when appropriate. Initialized variables to `null`.\n  let hogwarts = \"Hogwarts School of Witchcraft and Wizardry\";\n  let Gryffindor = \"Gryffindor\";\n  let Slytherin = \"Slytherin\";\n  let quidditchMatchTime = new Date();\n  let i = null;\n  let length = null;\n```\n\n- Do not use global variables. Implied global variables should also never be used.\n\n```javascript\n  // BAD - Improper initialization alignment, Incorrect indentation\n  const count       =10;\n  const name = \"Alex\";\n  const found  =    false;\n  const empty;\n\n  // BAD - Multiple variable statements, Multiple declarations on one line\n  const count = 10;\n  const name  = \"Alex\";\n  const found = false, empty;\n```\n\n### Function Declarations\n- All functions should be declared before they are used to avoid hoisting confusion.\n- There should be no space between the name of a function and the left parenthesis of its parameter list.\n  - For anonymous functions, there should be no space between the `function` keyword and the parentheses.\n- There should be one space between the right parenthesis and the left curly brace that begins the statement body.\n- The body itself is indented two spaces and the closing right curly brace is aligned with the line containing the beginning of the declaration of the function.\n- When a function is to be invoked immediately, the entire invocation expression should be wrapped in parens so that it is clear that the value being produced is the result of the function and not the function itself.\n\n```javascript\n  // GOOD\n  function outer(c, d) {\n    const e = c * d;\n\n    function inner(a, b) {\n      return (e * a) + b;\n    }\n\n    return inner(0, 1);\n  }\n\n  // GOOD\n  div.onclick = function() {\n    return false;\n  };\n\n  // BAD - Improper spacing of first line, left brace on wrong line\n  function doSomething (arg1, arg2)\n  {\n    return arg1 + arg2;\n  }\n```\n\n- Immediately invoked function expression format\n\n```javascript\n  // GOOD\n  (() =\u003e {\n    console.log('Herp Derp');\n  })();\n```\n\n- Never user `arguments`, instead use the rest syntax `...`\n\n```javascript\n  // GOOD\n  function concatAll(...args) {\n    return args.join('');\n  }\n  \n  // BAD - `arguments` is not explicit and not an actual JS `Array`\n  function concatAll() {\n    const args = [].slice.call(arguments);\n    return args.join('');\n  }\n```\n\n- Use the default parameter syntax rather than manipulating function arguments within the function body.\n\n```javascript\n  // GOOD\n  function foo(opts = {}) {\n    //...\n  }\n  \n  // BAD - Mutating function arguments in the body\n  function foo(opts) {\n    opts = opts || {};\n    //...\n  }\n```\n\n- Use arrow functions notation in place of a normally used anonymous function. Arrow functions will execute with the correct context of `this`.\n- If the function body is small and will cleanly fit on one-line, the you may omit the braces and use the implicit return value.\n- Always use parentheses around the arguments (including single arguments) for readability\n\n```javascript\n  // GOOD\n  [1,2,3].map((x) =\u003e {\n    return x * x;\n  });\n  \n  // GOOD (Even Better)\n  [1,2,3].map((x) =\u003e x * x);\n  \n  // BAD\n  [1,2,3].map(function(number) {\n    return number * number;\n  });\n```\n\n### Primitive Literals\n- Strings should appear on a single line. Don't use a slash to create a new line in a string.\n- If you need multi-line strings use the template literal format.\n\n```javascript\n  // GOOD\n  const name = \"Alex DiLiberto\";\n\n  // GOOD\n  const greeting = `Hello, my name\n  is ${name}`;\n\n  // BAD\n  const greeting = \"Hello, my name \\\n  is Alex DiLiberto.\";\n```\n\nNumbers should be written as decimal integers, e-notation integers, hexadecimal integers, or floating-point decimals with at least one digit before and one digit after the decimal point. Do **NOT** use octal literals.\n\n```javascript\n  // GOOD\n  let count = 10;\n\n  // GOOD\n  let price = 10.0;\n  let price = 10.00;\n\n  // GOOD\n  let num = 0xA2;\n\n  // GOOD\n  let num = 1e23;\n\n  // BAD - Hanging decimal point\n  let price = 10.;\n\n  // BAD - Leading decimal point\n  let price = .1;\n\n  // BAD - Octal (base 8) is deprecated\n  let num = 010;\n```\n\n- `null` should be used only in the following situations:\n\n  1. To compare against an initialized variable that may or may not have an object value\n  1. To pass into a function where an object is expected\n  1. To return from a function where an object is expected\n\n```javascript\n  // GOOD\n  function getPerson() {\n    if (condition) {\n      return new Person(\"Alex\");\n    } else {\n      return null;\n    }\n  }\n\n  // BAD - Testing against an uninitialized variable\n  let person;\n  if (person != null) {\n    doSomething();\n  }\n\n  // BAD - Testing to see if an argument was passed\n  function doSomething(arg1, arg2, arg3, arg4) {\n    if (arg4 != null) {\n      doSomethingElse();\n    }\n  }\n```\n\n- Never use `undefined` as a literal. To test if a variable has been defined, use the `typeof` operator.\n\n```javascript\n// GOOD\nif (typeof variable == \"undefined\") {\n  doSomething();\n}\n\n// BAD - Using undefined literal\nif (variable == undefined) {\n  doSomething();\n}\n```\n\n### Operator Spacing\n- Operators with two operands must be preceded and followed by a single space to make the expression clear.\n- When parentheses are used, there should be no white space immediately after the opening paren or immediately before the closing paren.\n\n```javascript\n// GOOD\nconst found = (values[i] === item);\n\n// GOOD\nif (found \u0026\u0026 (count \u003e 10)) {\n  doSomething();\n}\n\n// BAD - Missing spaces, Extra space after opening paren, Extra space around argument\nfor ( i=0; i\u003ccount; i++) {\n  process( i );\n}\n```\n\n### Object Literals\n- The opening brace should be on the same line as the containing statement.\n- Each property-value pair should be indented one level with the first property appearing on the next line after the opening brace.\n- If the value is a function, it should wrap under the property name and should have a blank line both before and after the function.\n\n```javascript\n// GOOD\nlet object = {\n  key1: value1,\n  key2: value2,\n\n  func: function() {\n    doSomething();\n  },\n\n  key3: value3\n};\n\n// Bad: Improper indentation, Missing blank lines around function\nlet object = {\n               key1: value1,\n               key2: value2,\n               func: function() {\n                 doSomething();\n               }\n          };\n```\n\n### Comment Annotations\nComments may be used to annotate pieces of code with additional information. The acceptable annotations are:\n\n1. `TODO` - Indicates that the code is not yet complete. Information about the next steps should be included.\n\n2. `HACK` - Indicates that the code is using a shortcut to achieve its results.\n\n3. `XXX` - Indicates that the code is problematic and should be fixed as soon as possible.\n\n4. `FIXME` - Indicates that the code is problematic and should be fixed soon. Less important than `XXX`.\n\n5. `REVIEW` - Indicates that the code needs to be reviewed for potential changes.\n\n### Rules of Thumb\n- Always use `===` and `!==` to avoid type coercion errors.\n- Blank lines improve readability by setting off sections of code that are logically related. Use as needed.\n- A `return` statement with a value should not use parentheses unless they make the return value more obvious in some way.\n- The `if` class of statements should have the following form:\n\n```javascript\n  if (condition) {\n    statements\n  } else if (condition) {\n    statements\n  } else {\n    statements\n  }\n```\n\n\n## CSS\n\n### CSS Style\n- Use soft-tabs with a **two** space indent.\n- Put spaces after `:` in property declarations.\n- Put spaces before `{` in rule declarations.\n- Use hex color codes with each letter capitalized `#123ABC` unless using `rgba()`.\n- Any `$variable` or `@mixin` that is used in more than one file should be put in `globals/`. Others should be put at the top of the file where they're used.\n\n```scss\n  /* Good coding style example! */\n  .styleguide-format {\n    border: 1px solid #0F0;\n    color: #000;\n    background: rgba(0,0,0,0.5);\n  }\n```\n\n### File Structure\nIn general, the CSS file organization should use the following format:\n\n```bash\n  css/\n  ├── global/\n  │   ├── components/\n  │   │   ├── button.scss\n  │   │   └── checkbox.scss\n  │   ├── header.scss\n  │   └── footer.scss\n  ├── layout/\n  │   ├── _base.scss\n  │   └── _login.scss\n  ├── mixins/\n  │   ├── _font.scss\n  │   └── _navigator.scss\n  └── vendor/\n      └── _media-queries.scss\n```\n\n### CSS Naming\nUse ID and class names that are as short as possible but as long as necessary.\n\n```scss\n  .nav {\n    /* Instead of .navigation */\n  }\n  .author {\n    /* Instead of .atr */\n  }\n```\n\nDo not concatenate words and abbreviations in selectors by any characters other than hyphens.\n\n```scss\n  .demo-image {\n    /* Instead of .demoimage or .demo_image */\n  }\n```\n\nID names should be in lowerCamelCase (although, as mentioned above, this should be **AVOIDED** for CSS styling hooks)\n\n```scss\n  #pageContainer {\n  }\n```\n\nClass names should be in lowercase, with words separated by hyphens. (as mentioned above).\n\n```scss\n  .my-class-name {\n  }\n```\n\nHTML elements should be in all lowercase.\n\n```scss\n  body,\n  div {\n    /* Instead of BODY, DIV */\n  }\n```\n\n### CSS Rules of Thumb\n- As a rule of thumb, do **NOT** nest further than 3 levels deep.\n  - If you find yourself going further, consider reorganizing your rules (specificity needed or the layout of the nesting).\n- Unit-less line-height is preferred because it does not inherit a percentage value of its parent element, but instead is based on a multiplier of the font-size.\n- Long, comma-separated property values (such as collections of gradients or shadows) should be arranged across multiple lines.\n- Avoid using ID selectors.\n- Include a snippet of HTML in a CSS comment for situations where it would be useful for a developer to know exactly how a chunk of CSS applies to some HTML.\n- Comments that refer to selector blocks should be on a separate line immediately before the block to which they refer.\n\n```scss\n  /* Comment about this selector block. */\n  selector {\n    property: value; /* Comment about this property-value pair. */\n  }\n```\n\n- Multiple selectors should each be on a single line, with no space after each comma.\n\n```scss\n  selector1,\n  selector2,\n  selector3,\n  selector4 {\n  }\n```\n\n- Broad selectors allow us to be efficient, yet can have adverse consequences if not tested. Location-specific selectors can save us time, but will quickly lead to a cluttered stylesheet. Exercise your best judgement.\n- Always avoid \"Magic Numbers\".\n  - These are numbers that are used as quick fixes on a one-off basis.\n  - Just because if works for your one scenario, doesn't mean it will work for all examples and permutations.\n\n```scss\n  /*\n    Magic Number example.\n    AVOID this whenever possible!\n  */\n  .box {\n    margin-top: 37px;\n  }\n```\n\n- Strive to only include selectors that include semantics.\n  - A `span` or `div` holds none.\n  - A `heading` has some.\n  - A class defined on an element has plenty.\n\n## HTML\n\n### Indentation and Line Breaks\nBreak to a new line if the tag contains another element.\n\n```html\n  \u003c!-- GOOD --\u003e\n  \u003cp\u003e\n    This is a\n    \u003ca href=\"#\"\u003elink\u003c/a\u003e.\n  \u003c/p\u003e\n\n  \u003c!-- BAD - All tags are grouped on a single line --\u003e\n  \u003cp\u003eThis is a \u003ca href=\"#\"\u003elink\u003c/a\u003e.\u003c/p\u003e\n```\n\nIn the above Good example note the period needs to be right after the anchor tag here because we do not want an extra space when the browser renders the HTML.\n\nThis also makes sense:\n\n```html\n  \u003ch2\u003eJune 16\u003csup\u003eth\u003c/sup\u003e\u003c/h2\u003e\n```\n\nbecause there shouldn’t be a space or possibility of line break between the date and its ordinal indicator.\n\n### Escaping Characters\nEscape the following characters with HTML entity encoding to prevent context switching into any execution context, such as script, style, or event handlers.\n\n```md\n \u0026 --\u003e \u0026amp;\n \u003c --\u003e \u0026lt;\n \u003e --\u003e \u0026gt;\n \" --\u003e \u0026quot;\n ' --\u003e \u0026#x27;\n / --\u003e \u0026#x2F;\n```\n\n### Smart Quotes\nUse [Smart Quotes](http://smartquotesforsmartpeople.com/) when appropriate.\n\n## Resources\n\n### JS Resources\n1. *Maintainable Javascript* by Nicholas C. Zakas\n1. [Code Conventions for the JavaScript Programming Language](http://javascript.crockford.com/code.html) by Douglas Crockford\n1. [AirBnB Javascript Styleguide](https://github.com/airbnb/javascript)\n\n### CSS Resources\n1. [GitHub CSS Styleguide](https://github.com/styleguide/css)\n1. [Google HTML/CSS Style Guide](http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml)\n1. [Principles of writing consistent, idiomatic CSS](https://github.com/necolas/idiomatic-css) by Nicolas Gallagher\n1. [My HTML/CSS coding style](http://csswizardry.com/2012/04/my-html-css-coding-style/) by Harry Roberts\n1. [Improving Code Readability With CSS Styleguides](http://coding.smashingmagazine.com/2008/05/02/improving-code-readability-with-css-styleguides/) by Vitaly Friedman\n1. [ThinkUp Code Style Guide: CSS](https://github.com/ginatrapani/ThinkUp/wiki/Code-Style-Guide:-CSS) by Gina Trapani\n1. [Wordpress CSS Coding Standards Handbook](http://make.wordpress.org/core/handbook/coding-standards/css/)\n1. [CSS Style Guides](http://css-tricks.com/css-style-guides/) by Chris Coyier\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falexdiliberto%2Fcode-conventions","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Falexdiliberto%2Fcode-conventions","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falexdiliberto%2Fcode-conventions/lists"}