index.html

---
layout: default
---


<div class="heading" id="toc">
  <h2>Table of contents</h2>
</div>
<div class="section toc">
  <div class="col">
    <h4><a href="#pxu">Shop Talk</a></h4>
    <ul>
      <li><a href="#pxu-golden-rule">The Golden Rule</a></li>
      <li><a href="#pxu-browser-support">Browser Support</a></li>
      <li><a href="#pxu-peer-review">Peer Review</a></li>
    </ul>
  </div>
  <div class="col">
    <h4><a href="#html">HTML</a></h4>
    <ul>
      <li><a href="#html-syntax">Syntax</a></li>
      <li><a href="#html-doctype">HTML5 doctype</a></li>
      <li><a href="#html-lang">Language attribute</a></li>
      <li><a href="#html-encoding">Character encoding</a></li>
      <li><a href="#html-ie-compatibility-mode">Internet Explorer compatibility mode</a></li>
      <li><a href="#html-style-script">CSS and JavaScript includes</a></li>
      <li><a href="#html-practicality">Practicality over purity</a></li>
      <li><a href="#html-attribute-order">Attribute order</a></li>
      <li><a href="#html-boolean-attributes">Boolean attributes</a></li>
      <li><a href="#html-reducing-markup">Reducing markup</a></li>
      <li><a href="#html-javascript">JavaScript generated markup</a></li>
    </ul>
  </div>
  <div class="col">
    <h4><a href="#liquid">Liquid</a></h4>
    <ul>
      <li><a href="#liquid-intro">An Introduction to Shopify</a></li>
      <li><a href="#liquid-syntax">Syntax</a></li>
      <li><a href="#liquid-whitespace">Whitespace in Expressions and Statements</a></li>
      <li><a href="#liquid-variables">Variables</a></li>
      <li><a href="#liquid-debugging">Debugging Tips</a></li>
    </ul>
  </div>
  <div class="col">
    <h4><a href="#sass">Sass</a></h4>
    <ul>
      <li><a href="#sass-syntax">Syntax</a></li>
      <li><a href="#sass-selectors">Selectors</a></li>
      <li><a href="#sass-nesting">Nesting</a></li>
      <li><a href="#sass-variables">Variables</a></li>
      <li><a href="#sass-includes-extends">@includes vs @extends</a></li>
      <li><a href="#sass-comments">Comments</a></li>
      <li><a href="#sass-media-queries">Media query placement</a></li>
      <li><a href="#sass-single-declarations">Rules with single declarations</a></li>
      <li><a href="#sass-shorthand">Shorthand notation</a></li>
      <li><a href="#sass-classes">Classes</a></li>
      <li><a href="#sass-organization">Organization</a></li>
      <li><a href="#sass-maintainability">Maintainability</a></li>
      <li><a href="#sass-declaration-order">Declaration order</a></li>
    </ul>
  </div>
</div>
<div class="section toc">
  <div class="col">
    <h4><a href="#javascript">JavaScript (ES6)</a></h4>
    <ul>
      <li><a href="#javascript-whitespace">Syntax</a></li>
      <li><a href="#javascript-variables">Variables</a></li>
      <li><a href="#javascript-comparison">Comparison</a></li>
      <li><a href="#javascript-typecasting">Type casting</a></li>
      <li><a href="#javascript-naming">Naming conventions</a></li>
      <li><a href="#javascript-comments">Comments</a></li>
      <li><a href="#javascript-destructuring">Destructuring</a></li>
      <li><a href="#javascript-modules">Modules</a></li>
      <li><a href="#javascript-strings">Strings</a></li>
      <li><a href="#javascript-arrays">Arrays</a></li>
      <li><a href="#javascript-functions">Functions</a></li>
      <li><a href="#javascript-objects">Objects</a></li>
      <li><a href="#javascript-classes">Classes</a></li>
      <li><a href="#javascript-events">Events</a></li>
      <li><a href="#javascript-jquery">jQuery</a></li>
    </ul>
  </div>
  <div class="col">
    <h4><a href="#coffee">CoffeeScript</a></h4>
    <ul>
      <li><a href="#coffee-code-layout">Code layout</a></li>
      <li><a href="#coffee-imports">Module Imports</a></li>
      <li><a href="#coffee-whitespace">Whitespace in Expressions and Statements</a></li>
      <li><a href="#coffee-comments">Comments</a></li>
      <li><a href="#coffee-naming">Naming Conventions</a></li>
      <li><a href="#coffee-functions">Functions</a></li>
      <li><a href="#coffee-strings">Strings</a></li>
      <li><a href="#coffee-conditionals">Conditionals</a></li>
      <li><a href="#coffee-looping">Looping and Comprehensions</a></li>
      <li><a href="#coffee-annotations">Annotations</a></li>
      <li><a href="#coffee-miscellaneous">Miscellaneous</a></li>
    </ul>
  </div>
  <div class="col">
    <h4><a href="#php">PHP</a></h4>
    <ul>
      <li><a href="#php-introduction">Introduction</a></li>
      <li><a href="#php-quotes">Single and Double Quotes</a></li>
      <li><a href="#php-indentation">Indentation</a></li>
      <li><a href="#php-brace-style">Brace Style</a></li>
      <li><a href="#php-function-guards">Function Guards</a></li>
      <li><a href="#php-regular-expressions">Regular Expressions</a></li>
      <li><a href="#php-spaces">Space Usage</a></li>
      <li><a href="#php-sql-statements">Formatting SQL statements</a></li>
      <li><a href="#php-database-queries">Database Queries</a></li>
      <li><a href="#php-naming">Naming Conventions</a></li>
      <li><a href="#php-self-explanatory">Self-Explanatory Flag Values for Function Arguments</a></li>
      <li><a href="#php-ternary-operator">Ternary Operator</a></li>
      <li><a href="#php-yoda-conditions">Yoda Conditions</a></li>
      <li><a href="#php-miscellaneous">Miscellaneous</a></li>
    </ul>
  </div>

  <div class="col">
    <h4><a href="#git">Git</a></h4>
    <ul>
      <li><a href="#git-introduction">An introduction to Git</a></li>
      <li><a href="#git-repos">Repo Naming</a></li>
      <li><a href="#git-setup">Setup</a></li>
      <li><a href="#git-branches">Branches and Pull Requests</a></li>
      <li><a href="#git-commits">Commits</a></li>
      <li><a href="#git-pushing">Pushing</a></li>
      <li><a href="#git-merging">Merging</a></li>
      <li><a href="#git-tagging">Tagging and Releasing</a></li>
    </ul>
  </div>
</div>

<div class="heading" id="pxu">
  <h2>Shop Talk</h2>
</div>

<div class="section" id="pxu-golden-rule">
  <div class="col">
    <h2>Golden rule</h2>
    <p>For additions or contributions to this Code Guide, please <a href="https://github.com/ShopPad/code-guide/issues/new">open an issue on GitHub</a>.</p>
  </div>
  <div class="col">
    <blockquote>
      <p>Every line of code should appear to be written by a single person, no matter the number of contributors.</p>
    </blockquote>
  </div>
</div>

<div class="section" id="pxu-browser-support">
  <div class="col">
    <h3>Browser Support</h3>
    <ul>
      <li>Internet Explorer 10+</li>
      <li>Chrome 45+</li>
      <li>Mobile Safari 8.4+</li>
      <li>Firefox 41+</li>
      <li>Safari 8+</li>
      <li>Chrome for Android 45+</li>
      <li>Android Browser 4.4.4+</li>
    </ul>
    
    <p>We do not "support" the following browsers:</p>
    <ul>
      <li>Opera</li>
      <li>Anything not listed above</li>
    </ul>
    <p>Not supporting doesn't mean a broken website, it means a lack of testing.</p>
  </div>

</div>

<div class="section" id="pxu-peer-review">
  <div class="col">
    <h3>Peer Review</h3>

    <p>We don't release code that hasn't been peer reviewed. Whether it's a two line change to some CSS or a complete refactoring of a JavaScript function, your pull request will always be reviewed by one of your peers.</p>

    <p>Since all of your code is written on a <a href="#git-branches">different branch</a> than master anyways, peer review is as simple as opening up a pull request and assigning it to somebody to review.<p>

    <h4>The Exception</h4>

    <p>The <em>only</em> exception to committing code that isn't up to the standards in this document is when working on an older theme. It's preferable to keep code consistent to the theme that you're working on even if that code isn't up to our current standards (within reason). It's important to document these decisions in your Pull Request.</p>

    <p>If the theme still has shelf life (not going to be archived any time soon), create a new task detailing the changes that should be made to bring the theme up to our current standards.</p>
  </div>

</div>


<div class="heading" id="html">
  <h2>HTML</h2>
</div>

<div class="section" id="html-syntax">
  <div class="col">
    <h3>Syntax</h3>
    <ul>
      <li>Use soft tabs with two spaces—they're the only way to guarantee code renders the same in any environment.</li>
      <li>Nested elements should be indented once (two spaces).</li>
      <li>Always use double quotes, never single quotes, on attributes.</li>
      <li>Don't include a trailing slash in self-closing elements—the <a href="http://dev.w3.org/html5/spec-author-view/syntax.html#syntax-start-tag">HTML5 spec</a> says they're optional.</li>
      <li>Don’t omit optional closing tags (e.g. <code>&lt;/li&gt;</code> or <code>&lt;/body&gt;</code>).</li>
    </ul>
  </div>
  <div class="col">
    {% highlight html %}{% include html/syntax.html %}{% endhighlight %}
  </div>
</div>

<div class="section" id="html-doctype">
  <div class="col">
    <h3>HTML5 doctype</h3>
    <p>Enforce standards mode and more consistent rendering in every browser possible with this simple doctype at the beginning of every HTML page.</p>
  </div>
  <div class="col">
    {% highlight html %}{% include html/doctype.html %}{% endhighlight %}
  </div>
</div>

<div class="section" id="html-lang">
  <div class="col">
    <h3>Language attribute</h3>
    <p>From the HTML5 spec:</p>
    <blockquote>
      <p>Authors are encouraged to specify a lang attribute on the root html element, giving the document's language. This aids speech synthesis tools to determine what pronunciations to use, translation tools to determine what rules to use, and so forth.</p>
    </blockquote>
    <p>Read more about the <code>lang</code> attribute <a href="http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-html-element">in the spec</a>.</p>
    <p>Head to Sitepoint for a <a href="http://reference.sitepoint.com/html/lang-codes">list of language codes</a>.</p>
  </div>
  <div class="col">
    {% highlight html %}{% include html/lang.html %}{% endhighlight %}
  </div>
</div>

<div class="section" id="html-ie-compatibility-mode">
  <div class="col">
    <h3>IE compatibility mode</h3>
    <p>Internet Explorer supports the use of a document compatibility <code>&lt;meta&gt;</code> tag to specify what version of IE the page should be rendered as. Unless circumstances require otherwise, it's most useful to instruct IE to use the latest supported mode with <strong>edge mode</strong>.</p>
    <p>For more information, <a href="http://stackoverflow.com/questions/6771258/whats-the-difference-if-meta-http-equiv-x-ua-compatible-content-ie-edge-e">read this awesome Stack Overflow article</a>.</p>
  </div>
  <div class="col">
    {% highlight html %}{% include html/ie-compatibility-mode.html %}{% endhighlight %}
  </div>
</div>

<div class="section" id="html-encoding">
  <div class="col">
    <h3>Character encoding</h3>
    <p>Quickly and easily ensure proper rendering of your content by declaring an explicit character encoding. When doing so, you may avoid using character entities in your HTML, provided their encoding matches that of the document (generally UTF-8).</p>
  </div>
  <div class="col">
    {% highlight html %}{% include html/encoding.html %}{% endhighlight %}
  </div>
</div>

<div class="section" id="html-style-script">
  <div class="col">
    <h3>CSS and JavaScript includes</h3>
    <p>Per HTML5 spec, typically there is no need to specify a <code>type</code> when including CSS and JavaScript files as <code>text/css</code> and <code>text/javascript</code> are their respective defaults.</p>
    <h4>HTML5 spec links</h4>
    <ul>
      <li><a href="http://www.w3.org/TR/2011/WD-html5-20110525/semantics.html#the-link-element">Using link</a></li>
      <li><a href="http://www.w3.org/TR/2011/WD-html5-20110525/semantics.html#the-style-element">Using style</a></li>
      <li><a href="http://www.w3.org/TR/2011/WD-html5-20110525/scripting-1.html#the-script-element">Using script</a></li>
    </ul>
  </div>
  <div class="col">
    {% highlight html %}{% include html/style-script.html %}{% endhighlight %}
  </div>
</div>

<div class="section" id="html-practicality">
  <div class="col">
    <h3>Practicality over purity</h3>
    <p>Strive to maintain HTML standards and semantics, but not at the expense of practicality. Use the least amount of markup with the fewest intricacies whenever possible.</p>
  </div>
</div>

<div class="section" id="html-attribute-order">
  <div class="col">
    <h3>Attribute order</h3>
    <p>HTML attributes should come in this particular order for easier reading of code.</p>
    <ul>
      <li><code>class</code></li>
      <li><code>id</code>, <code>name</code></li>
      <li><code>data-*</code></li>
      <li><code>src</code>, <code>for</code>, <code>type</code>, <code>href</code></li>
      <li><code>title</code>, <code>alt</code></li>
      <li><code>aria-*</code>, <code>role</code></li>
    </ul>
    <p>Classes make for great reusable components, so they come first. Ids are more specific and should be used sparingly (e.g., for in-page bookmarks), so they come second.</p>
  </div>
  <div class="col">
    {% highlight html %}{% include html/attribute-order.html %}{% endhighlight %}
  </div>
</div>

<div class="section" id="html-boolean-attributes">
  <div class="col">
    <h3>Boolean attributes</h3>
    <p>A boolean attribute is one that needs no declared value. XHTML required you to declare a value, but HTML5 has no such requirement.</p>
    <p>For further reading, consult the <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#boolean-attributes">WhatWG section on boolean attributes</a>:</p>
    <blockquote>
      <p>The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.</p>
    </blockquote>
    <p>If you <em>must</em> include the attribute's value, and <strong>you don't need to</strong>, follow this WhatWG guideline:</p>
    <blockquote>
      <p>If the attribute is present, its value must either be the empty string or [...] the attribute's canonical name, with no leading or trailing whitespace.</p>
    </blockquote>
    <p><strong>In short, don't add a value.</strong></p>
  </div>
  <div class="col">
    {% highlight html %}{% include html/boolean-attributes.html %}{% endhighlight %}
  </div>
</div>

<div class="section" id="html-reducing-markup">
  <div class="col">
    <h3>Reducing markup</h3>
    <p>Whenever possible, avoid superfluous parent elements when writing HTML. Many times this requires iteration and refactoring, but produces less HTML. Take the following example:</p>
  </div>
  <div class="col">
    {% highlight html %}{% include html/reducing-markup.html %}{% endhighlight %}
  </div>
</div>

<div class="section" id="html-javascript">
  <div class="col">
    <h3>JavaScript generated markup</h3>
    <p>Writing markup in a JavaScript file makes the content harder to find, harder to edit, and less performant. Avoid it whenever possible.</p>
  </div>
</div>

<div class="heading" id="liquid">
  <h2>Liquid</h2>
</div>

<div class="section" id="liquid-intro">
  <div class="col">
    <h3>In Introduction to Shopify</h3>
    <p>Shopify is the only platform that we develop for that uses Liquid. Fortunately, they've done a great job on <a href="http://docs.shopify.com/themes">documentation</a> and almost all of the info that you need can be found there.</p>

    <ul>
      <li><a href="http://docs.shopify.com/themes/liquid-documentation/basics">Basics</a></li>
      <li><a href="http://docs.shopify.com/themes/liquid-documentation/tags">Tags</a></li>
      <li><a href="http://docs.shopify.com/themes/liquid-documentation/objects">Objects</a></li>
      <li><a href="http://docs.shopify.com/themes/liquid-documentation/filters">Filters</a></li>
    </ul>

    <p>The <strong>Objects</strong> link above is almost certainly the most important resource available to you when writing code for Shopify. It contains every single object you might come across during development and all of the values attached to them.</p>
  </div>
</div>

<div class="section" id="liquid-syntax">
  <div class="col">
    <h3>Syntax</h3>
    <ul>
      <li>Use soft tabs with two spaces—they're the only way to guarantee code renders the same in any environment.</li>
      <li>Nested elements should be indented once (two spaces).</li>
    </ul>
  </div>
  <div class="col">
    {% highlight liquid %}{% include liquid/syntax.liquid %}{% endhighlight %}
  </div>
</div>

<div class="section" id="liquid-whitespace">
  <div class="col">
    <h3>Whitespace in Expressions and Statements</h3>
    <ul>
      <li>Always surround these binary operators with a single space on either side:
        <ul>
          <li>assignment: <code>=</code></li>
          <li>comparisons: <code>==</code>, <code>!=</code>, <code><</code>, <code>></code>, etc.</li>
          <li>conditionals: <code>if</code>, <code>unless</code>, <code>and</code>, <code>or</code></li>
          <li>filters: <code>|</code>, <code>minus:</code>, <code>divided_by:</code>, <code>strip</code></li>
          <li>braces: <code>{% raw %}{{ }}{% endraw %}</code>, <code>{% raw %}{% %}{% endraw %}</code></li>
        </ul>
      </li>
    </ul>
  </div>
  <div class="col">
    {% highlight liquid %}{% include liquid/whitespace.liquid %}{% endhighlight %}
  </div>
</div>

<div class="section" id="liquid-variables">
  <div class="col">
    <h3>Variables</h3>
    <ul>
      <li>always assign and capture variables in camelCase</li>
      <li>only assign a variable if it:
        <ol>
          <li>is used more than once on a page</li>
          <li>reduces line length and confusion where it gets outputted</li>
        </ol>
      </li>
    </ul>
  </div>
  <div class="col">
    {% highlight liquid %}{% include liquid/variables.liquid %}{% endhighlight %}
  </div>
</div>

<div class="section" id="liquid-debugging">
  <div class="col">
    <h3>Debugging Tips</h3>

    <ul>
      <li>double check that Shopify is returning the correct data with the <code>json</code> filter</li>
      <li>make sure the theme settings page isn't lying to you by creating a Theme Settings Javascript object</li>
    </ul>
  </div>
  <div class="col">
    {% highlight liquid %}{% include liquid/debugging.liquid %}{% endhighlight %}
  </div>
</div>

<div class="heading" id="sass">
  <h2>Sass</h2>
</div>

<div class="section" id="sass-syntax">
  <div class="col">
    <h3>Syntax</h3>
    <ul>
      <li>Use soft tabs with two spaces—they're the only way to guarantee code renders the same in any environment.</li>
      <li>When grouping selectors, keep individual selectors to a single line.</li>
      <li>Include one space before the opening brace of declaration blocks for legibility.</li>
      <li>Place closing braces of declaration blocks on a new line.</li>
      <li>Include one space after <code>:</code> for each declaration.</li>
      <li>Each declaration should appear on its own line for more accurate error reporting.</li>
      <li>End all declarations with a semi-colon, even the last one</li>
      <li>Comma-separated property values should include a space after each comma (e.g., <code>box-shadow</code>).</li>
      <li>Don't include spaces after commas <em>within</em> <code>rgb()</code>, <code>rgba()</code>, <code>hsl()</code>, <code>hsla()</code>, or <code>rect()</code> values. This helps differentiate multiple color values (comma, no space) from multiple property values (comma with space).</li>
      <li>Prefix property values or color parameters with a leading zero (e.g., <code>0.5</code> instead of <code>.5</code> and <code>-0.5px</code> instead of <code>-.5px</code>).</li>
      <li>Lowercase all hex values, e.g., <code>#fff</code>. Lowercase letters are much easier to discern when scanning a document as they tend to have more unique shapes.</li>
      <li>Use shorthand hex values where available, e.g., <code>#fff</code> instead of <code>#ffffff</code>.</li>
      <li>Quote attribute values in selectors, e.g., <code>input[type="text"]</code>. <a href="http://mathiasbynens.be/notes/unquoted-attribute-values#css">They’re only optional in some cases</a>, and it’s a good practice for consistency.</li>
      <li>Avoid specifying units for zero values, e.g., <code>margin: 0;</code> instead of <code>margin: 0px;</code>.</li>
    </ul>
    <p>Questions on the terms used here? See the <a href="http://en.wikipedia.org/wiki/Cascading_Style_Sheets#Syntax">syntax section of the Cascading Style Sheets article</a> on Wikipedia.</p>
  </div>
  <div class="col">
    {% highlight css %}{% include css/syntax.css %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-selectors">
  <div class="col">
    <h3>Selectors</h3>
    <ul>
      <li>Use classes over generic element tag or IDs for optimum rendering performance.</li>
      <li>Prefer descriptive class names to descendent selectors.</li>
      <li>Avoid using several attribute selectors (e.g., <code>[class^="..."]</code>) on commonly occuring components. Browser performance is known to be impacted by these.</li>
      <li>Keep selectors short and strive to limit the number of elements in each selector to three.</li>
      <li>Scope classes to the closest parent <strong>only</strong> when necessary (e.g., when not using prefixed classes).</li>
    </ul>
    <p>Additional reading:</p>
    <ul>
      <li><a href="http://markdotto.com/2012/02/16/scope-css-classes-with-prefixes/">Scope CSS classes with prefixes</a></li>
      <li><a href="http://markdotto.com/2012/03/02/stop-the-cascade/">Stop the cascade</a></li>
    </ul>
  </div>
  <div class="col">
    {% highlight css %}{% include css/selectors.css %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-nesting">
  <div class="col">
    <h3>Nesting</h3>
    <p>Nesting is very helpful to define element states such as active and hover, pseudo elements like before and after, and minimal child selectors that don't justify an additional class name.</p>
    <ul>
      <li>Avoid unnecessary nesting. Just because you can nest, doesn't mean you always should.</li>
      <li>At a maximum, nesting should only go three levels deep.</li>
      <li>Maximum amount of nested lines is 60. Your entire nest should be visible on a laptop's screen.</li>
    </ul>
  </div>
  <div class="col">
    {% highlight scss %}{% include css/nesting.scss %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-variables">
  <div class="col">
    <h3>Variables</h3>
    <p>Variables in Sass are a powerful way to define values in one place that can be reused in multiple places in your project. They allow you to make changes from a central point without needing to use find and replace across multiple files and directories. <a href="http://thesassway.com/beginner/variable-naming">[ref]</a></p>
    <ul>
      <li>Names should be descriptive of purpose or function, not of the value.</li>
      <li>Multi-word variables should be separated by hyphens.</li>
      <li>Keep variables in a centralized file. For our Shopify themes, that's <code>_user-settings.scss</code>.</li>
    </ul>
  </div>
  <div class="col">
    {% highlight scss %}{% include css/sass-variables.scss %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-includes-extends">
  <div class="col">
    <h3>@include vs @extend</h3>

    <p>First, some basics:</p>

    <ul>
      <li>The <strong>@extend</strong> directive tells Sass that one selector should inherit the styles of another selector.</li>
      <li>The <strong>@include</strong> directive takes the name of a mixin and optionally arguments to pass to it, and includes the styles defined by that mixin into the current rule.</li>
    </ul>

    <h4>When to use @extend</h4>

    <p>This should be your first plan of attack. Using an @extend limits customizability but produces a more efficient CSS file. Smaller is better.</p>

    <h4>When to use @include</h4>

    <p>If you need to overwrite declarations of an @extend or need to pass values to it then you'll want to set up a mixin and use @include instead. Mixins are powerful and are generally used to accomplish complicated or labor-intensive tasks. Some examples:</p>

    <ul>
      <li>wrapping content in another class / query (IE, retina, etc)</li>
      <li><a href="http://bourbon.io/docs/#placeholder">placeholders</a></li>
      <li>avoiding browser prefixes new CSS3 properties, such as:
        <ul>
          <li><a href="http://bourbon.io/docs/#animation">animations</a></li>
          <li><a href="http://bourbon.io/docs/#transitions">transitions</a></li>
          <li><a href="http://bourbon.io/docs/#flexbox">flexbox</a></li>
        </ul>
      </li>
    </ul>

  </div>
  <div class="col">
    {% highlight scss %}{% include css/includes_extends.scss %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-comments">
  <div class="col">
    <h3>Comments</h3>
    <p>Code is written and maintained by people. Ensure your code is descriptive, well commented, and approachable by others. Great code comments convey context or purpose. Do not simply reiterate a component or class name.</p>
    <p>Be sure to write in complete sentences for larger comments and succinct phrases for general notes.</p>
  </div>
  <div class="col">
    {% highlight css %}{% include css/comments.css %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-media-queries">
  <div class="col">
    <h3>Media query placement</h3>
    <p>Place media queries inside their respective selector. Don't have entire blocks of code dedicated to a single media query.</p>

    <p>Feel free to create a media query mixin to simplify modifying your queries.</p>
  </div>
  <div class="col">
    {% highlight scss %}{% include css/media-queries.scss %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-single-declarations">
  <div class="col">
    <h3>Single declarations</h3>
    <p>In instances where a rule set includes <strong>only one declaration</strong>, consider removing line breaks for readability and faster editing. Any rule set with multiple declarations should be split to separate lines.</p>
    <p>The key factor here is error detection—e.g., a CSS validator stating you have a syntax error on Line 183. With a single declaration, there's no missing it. With multiple declarations, separate lines is a must for your sanity.</p>
  </div>
  <div class="col">
    {% highlight css %}{% include css/single-declarations.css %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-shorthand">
  <div class="col">
    <h3>Shorthand notation</h3>
    <p>Strive to limit use of shorthand declarations to instances where you must explicitly set all the available values. Common overused shorthand properties include:</p>
    <ul>
      <li><code>padding</code></li>
      <li><code>margin</code></li>
      <li><code>font</code></li>
      <li><code>background</code></li>
      <li><code>border</code></li>
      <li><code>border-radius</code></li>
    </ul>
    <p>Often times we don't need to set all the values a shorthand property represents. For example, HTML headings only set top and bottom margin, so when necessary, only override those two values. Excessive use of shorthand properties often leads to sloppier code with unnecessary overrides and unintended side effects.</p>
    <p>The Mozilla Developer Network has a great article on <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Shorthand_properties">shorthand properties</a> for those unfamiliar with notation and behavior.</p>
  </div>
  <div class="col">
    {% highlight css %}{% include css/shorthand.css %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-classes">
  <div class="col">
    <h3>Class names</h3>
    <ul>
      <li>Keep classes lowercase and use dashes (not underscores or camelCase). Dashes serve as natural breaks in related class (e.g., <code>.btn</code> and <code>.btn-danger</code>).</li>
      <li><a href="http://markdotto.com/2012/02/16/scope-css-classes-with-prefixes/">Scope CSS classes with prefixes</a>.</li>
      <li>Avoid excessive and arbitrary shorthand notation. <code>.btn</code> is useful for <em>button</em>, but <code>.s</code> doesn't mean anything.</li>
      <li>Keep classes as short and succinct as possible.</li>
      <li>Use meaningful names; use structural or purposeful names over presentational.</li>
      <li>Use <code>.js-*</code> classes to denote behavior (as opposed to style), but keep these classes out of your CSS.</li>
    </ul>
  </div>
  <div class="col">
    {% highlight css %}{% include css/class-names.css %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-organization">
  <div class="col">
    <h3>Organization</h3>
    <p>Thanks to compilation and compression, we're able to organize styles into many small files without impacting the end user. Rules should be organized into small sets corresponding to the elements they style. Styles of unrelated elements should never be in the same file.</p>
    <ul>
      <li>Organize sections of code by component.</li>
      <li>Develop a consistent commenting hierarchy.</li>
    </ul>
  </div>
</div>

<div class="section" id="sass-maintainability">
  <div class="col">
    <h3>Maintainability</h3>
    <p>Consider the example on the right.</p>

    <p>This rule obviously hides something, but it's not clear what it's hiding, or why. This code is unmaintainable, because its purpose is not obvious. Strive to write selectors and styles whose purpose and relationship is intuitive and obvious.</p>
  </div>
  <div class="col">
    {% highlight scss %}{% include css/maintainability.scss %}{% endhighlight %}
  </div>
</div>

<div class="section" id="sass-declaration-order">
  <div class="col">
    <h3>Declaration order</h3>
    <p><strong>Recommended</strong> only. During the course of development this might not be realistic. Try to keep the following recommendations in mind.</p>
    <p>Related property declarations should be grouped together following the order:</p>
    <ol>
      <li>Positioning</li>
      <li>Box model</li>
      <li>Typographic</li>
      <li>Visual</li>
    </ol>
    <p>Positioning comes first because it can remove an element from the normal flow of the document and override box model related styles. The box model comes next as it dictates a component's dimensions and placement.</p>
    <p>Everything else takes place <em>inside</em> the component or without impacting the previous two sections, and thus they come last.</p>
    <p>For a complete list of properties and their order, please see <a href="http://twitter.github.com/recess">Recess</a>.</p>
  </div>
  <div class="col">
    {% highlight css %}{% include css/declaration-order.css %}{% endhighlight %}
  </div>
</div>




<div class="heading" id="javascript">
  <h2>JavaScript (ES6)</h2>
</div>

<div class="section" id="javascript-whitespace">
  <div class="col">
    <h3>Syntax</h3>

    <p>Use spaces only, with <strong>2 spaces</strong> per indentation level. Never mix tabs and spaces.</p>
    <p>Try your best to limit all lines to a maximum of 80 characters. Do not ever go over 120.</p>
    <p>Do not include trailing whitespace on any lines.</p>
    <p>Use only unix-style newlines. <code>\n</code> not <code>\r\n</code>.</p>
    <p>Use UTF-8 as the source file encoding.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Place <strong>1</strong> space before the leading brace.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Place <strong>1</strong> space before the opening parenthesis in control statements (<code>if</code>, <code>while</code> etc.). Place no space before the argument list in function calls and declarations.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-3.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Set off operators with spaces.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-4.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>End files with a single newline character.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-5.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Leave a blank line after blocks and before the next statement.</p>
    <p>Use a single blank line within the bodies of methods or functions in cases where this improves readability (e.g., for the purpose of delineating logical sections).</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-6.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Do not use leading commas.</p>
    <p>Use additional trailing commas.</p>
    <p>This leads to cleaner git diffs. Also, transpilers like Babel will remove the additional trailing comma in the transpiled code which means you don't have to worry about the <a href="https://github.com/airbnb/javascript/blob/master/es5/README.md#commas">trailing comma problem</a> in legacy browsers.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-7.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Always use explicit semicolons.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-8.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use braces with all multi-line blocks.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-9.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>If you're using multi-line blocks with if and else, put else on the same line as your if block's closing brace.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/whitespace-10.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-variables">
  <div class="col">
    <h3>Variables</h3>

    <p>Use <code>const</code> for all of your references; avoid using <code>var</code>.</p>
    <p>This ensures that you can't reassign your references (mutation), which can lead to bugs and difficult to comprehend code.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/variables-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>If you must mutate references, use <code>let</code> instead of <code>var</code>.</p>
    <p><code>let</code> is block-scoped rather than function-scoped like <code>var</code>.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/variables-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Note that both <code>let</code> and <code>const</code> are block-scoped.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/variables-3.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use one <code>const</code>/<code>let</code> declaration per variable.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/variables-4.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Group all your <code>const</code>s and then group all your <code>let</code>s.</p>
    <p>This is helpful when later on you might need to assign a variable depending on one of the previous assigned variables.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/variables-5.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-comparison">
  <div class="col">
    <h3>Comparison Operators &amp; Equality</h3>

    <p>Use <code>===</code> and <code>!==</code> over <code>==</code> and <code>!=</code>.</p>

    <p>Conditional statements such as the if statement evaulate their expression using coercion with the <code>ToBoolean</code> abstract method and always follow these simple rules:</p>

    <ul>
      <li>Objects evaluate to <code>true</code></li>
      <li>Undefined evaluates to <code>false</code></li>
      <li>Null evaluates to <code>false</code></li>
      <li>Booleans evaluate to the value of the boolean</li>
      <li>Numbers evaluate to false if <code>+0</code>, <code>-0</code>, or <code>NaN</code>, otherwise <code>true</code></li>
      <li>Strings evaluate to false if an empty string <code>''</code>, otherwise <code>true</code></li>
    </ul>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/comparison-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use shortcuts when possible.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/comparison-2.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-typecasting">
  <div class="col">
    <h3>Type Casting &amp; Coercion</h3>

    <p>Strings:</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/typecasting-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use <code>parseInt</code> for Numbers and <strong>always with a radix</strong> for type casting.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/typecasting-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Booleans:</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/typecasting-3.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-naming">
  <div class="col">
    <h3>Naming Conventions</h3>

    <p>Avoid single letter names. Be descriptive with your naming.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/naming-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use camelCase when naming objects, functions, and instances.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/naming-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use PascalCase when naming constructors or classes.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/naming-3.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use a leading underscore <code>_</code> when naming private properties or methods.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/naming-4.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Don't save references to <code>this</code>. Use arrow functions or <code>Function#bind</code>.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/naming-5.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>If your file exports a single class, your filename should be exactly the name of the class.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/naming-6.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use camelCase when you export-default a function. Your filename should be identical to your function's name.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/naming-7.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-comments">
  <div class="col">
    <h3>Comments</h3>

    <p>Use <code>/** ... */</code> for multi-line comments. Include a description, specify types and values for all parameters and return values.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/comments-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use <code>//</code> for single line comments. Place single line comments on a newline above the subject of the comment. Put an empty line before the comment.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/comments-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Prefixing your comments with <code>FIXME</code> or <code>TODO</code> helps other developers quickly understand if you're pointing out a problem that needs to be revisited, or if you're suggesting a solution to the problem that needs to be implemented. These are different than regular comments because they are actionable.</p>
    <p>Use <code>// FIXME:</code> to annotate problems.</p>
    <p>Use <code>// TODO:</code> to annotate solutions to problems.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/comments-3.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-destructuring">
  <div class="col">
    <h3>Destructuring</h3>

    <p>Use object destructuring when accessing and using multiple properties of an object.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/destructuring-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use array destructuring.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/destructuring-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use object destructuring for multiple return values, not array destructuring.</p>
    <p>You can add new properties over time or change the order of things without breaking call sites.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/destructuring-3.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-modules">
  <div class="col">
    <h3>Module Imports</h3>

    <p>Always use modules (<code>import</code>/<code>export</code>) over a non-standard module system. You can always transpile to your preferred module system.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/modules-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Do not use wildcard imports.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/modules-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Import statements should be grouped in the following order:</p>
    <ol>
      <li>Standard library imports <em>(if a standard library exists)</em></li>
      <li>Third party library imports</li>
      <li>Local imports <em>(imports specific to this application or library)</em></li>
    </ol>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/modules-3.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-strings">
  <div class="col">
    <h3>Strings</h3>

    <p>Use single quotes <code>''</code> for strings.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/strings-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>When programmatically building up strings, use template strings instead of concatenation.</p>
    <p>Template strings give you a readable, concise syntax with proper newlines and string interpolation features.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/strings-2.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-arrays">
  <div class="col">
    <h3>Arrays</h3>

    <p>Use the literal syntax for array creation.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/arrays-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use <code>Array#push</code> instead of direct assignment to add items to an array.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/arrays-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use array spreads <code>...</code> to copy arrays.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/arrays-3.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>To convert an array-like object to an array, use <code>Array#from</code>.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/arrays-4.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-functions">
  <div class="col">
    <h3>Functions</h3>

    <p>Use function declarations instead of function expressions.</p>
    <p>Function declarations are named, so they're easier to identify in call stacks. Also, the whole body of a function declaration is hoisted, whereas only the reference of a function expression is hoisted. This rule makes it possible to always use Arrow Functions in place of function expressions.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/functions-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Immediately-invoked function expressions:</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/functions-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Never declare a function in a non-function block (<code>if</code>, <code>while</code>, etc). Assign the function to a variable instead. Browsers will allow you to do it, but they all interpret it differently.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/functions-3.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Never name a parameter <code>arguments</code>. This will take precedence over the <code>arguments</code> object that is given to every function scope.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/functions-4.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Never use <code>arguments</code>, opt to use rest syntax <code>...</code> instead.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/functions-5.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use default parameter syntax rather than mutating function arguments.</p>
    <p>Use <code>Object#assign</code> or <code>jQuery#extend</code> to set default object values.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/functions-6.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>When you must use function expressions (as when passing an anonymous function), use <strong>arrow function notation</strong>.</p>
    <p>It creates a version of the function that executes in the context of <code>this</code>, which is usually what you want, and is a more concise syntax.</p>
    <p>If you have a fairly complicated function, you might move that logic out into its own function declaration.</p>
    <p>If the function body fits on one line and there is only a single argument, feel free to omit the braces and parentheses, and use the implicit return. Otherwise, add the parentheses, braces, and use a return statement.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/functions-7.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-objects">
  <div class="col">
    <h3>Objects</h3>

    <p>Use the literal syntax for object creation.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/objects-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Don't use <a href="http://es5.github.io/#x7.6.1">reserved words</a> as keys. It won't work in IE8. <a href="https://github.com/airbnb/javascript/issues/61">More info</a>.</p>
    <p>Use readable synonyms in place of reserved words.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/objects-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use computed property names when creating objects with dynamic property names.</p>
    <p>They allow you to define all the properties of an object in one place.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/objects-3.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use object method shorthand.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/objects-4.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use property value shorthand.</p>
    <p>Group your shorthand properties at the beginning of your object declaration.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/objects-5.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use dot notation when accessing properties.</p>
    <p>Use subscript notation <code>[]</code> when accessing properties with a variable.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/objects-6.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-classes">
  <div class="col">
    <h3>Classes</h3>

    <p>Always use <code>class</code>. Avoid manipulating <code>prototype</code> directly.</p>
    <p><code>class</code> syntax is more concise and easier to reason about.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/classes-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Use <code>extends</code> for inheritance.</p>
    <p>It is a built-in way to inherit prototype functionality without breaking <code>instanceof</code>.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/classes-2.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>It's okay to write a custom <code>toString()</code> method, just make sure it works successfully and causes no side effects.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/classes-3.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Accessor functions for properties are not required.</p>
    <p>If you do make accessor functions use <code>getVal()</code> and <code>setVal('hello')</code>.</p>
    <p>If the property is a boolean, use <code>isVal()</code> or <code>hasVal()</code>.</p>
    <p>It's okay to create <code>get()</code> and <code>set()</code> functions, but be consistent.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/classes-4.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Getters and setters should not be used when <a href="https://babeljs.io/docs/advanced/caveats/#getters-setters-8-and-below-">supporting IE8 and below</a>.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/classes-5.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-events">
  <div class="col">
    <h3>Events</h3>

    <p>When attaching data payloads to events (whether DOM events or something more proprietary like Backbone events), pass a hash instead of a raw value. This allows a subsequent contributor to add more data to the event payload without finding and updating every handler for the event.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/events-1.js %}{% endhighlight %}
  </div>
</div>


<div class="section" id="javascript-jquery">
  <div class="col">
    <h3>jQuery</h3>

    <p>Prefix jQuery object variables with a <code>$</code>.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/jquery-1.js %}{% endhighlight %}
  </div>
</div>

<div class="section">
  <div class="col">
    <p>Cache jQuery lookups.</p>
  </div>

  <div class="col">
    {% highlight js %}{% include javascript/jquery-2.js %}{% endhighlight %}
  </div>
</div>




<div class="heading" id="coffee">
  <h2>CoffeeScript</h2>
</div>

<div class="section" id="coffee-code-layout">
  <div class="col">
    <h3>Code layout</h3>
    <ul>
      <li>Use spaces only, with <strong>4 spaces</strong> per indentation level. Never mix tabs and spaces.</li>
      <li>Try your best to limit all lines to a maximum of 79 characters. Do not ever go over 120.</li>
    </ul>

    <h4>Blank lines</h4>
    <ul>
      <li>Separate top-level function and class definitions with a single blank line.</li>
      <li>Separate method definitions inside of a class with a single blank line.</li>
      <li>Use a single blank line within the bodies of methods or functions in cases where this improves readability (e.g., for the purpose of delineating logical sections).</li>
    </ul>

    <h4>Trailing Whitespace</h4>
    <ul>
      <li>Do not include trailing whitespace on any lines.</li>
    </ul>

    <h4>Encoding</h4>
    <ul>
      <li>UTF-8 is the only source file encoding.</li>
    </ul>
  </div>
</div>

<div class="section" id="coffee-imports">
  <div class="col">
    <h3>Module Imports</h3>

    <p>If using a module system (CommonJS Modules, AMD, etc.), require statements should be placed on separate lines at the top of the file.</p>

    <p>These statements should be grouped in the following order:</p>

    <ol>
      <li>Standard library imports <em>(if a standard library exists)</em></li>
      <li>Third party library imports</li>
      <li>Local imports <em>(imports specific to this application or library)</em></li>
    </ol>
  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/imports.coffee %}{% endhighlight %}
  </div>
</div>

<div class="section" id="coffee-whitespace">
  <div class="col">
    <h3>Whitespace in Expressions and Statements</h3>

    <p>Avoid extraneous whitespace in the following situations:</p>

    <ul>
      <li>Immediately inside parentheses, brackets or braces</li>
      <li>Immediately before a comma</li>
    </ul>

    <p>Additional recommendations::</p>

    <ul>
      <li>Always surround these binary operators with a single space on either side
        <ul>
          <li>assignment: <code>=</code></li>
          <li>augmented assignment: <code>+=</code>, <code>-=</code>, etc.</li>
          <li>comparisons: <code>==</code>, <code><</code>, <code>></code>, <code><=</code>, <code>>=</code>, <code>unless</code>, etc.</li>
          <li>arithmetic operators: <code>+</code>, <code>-</code>, <code>*</code>, <code>/</code>, etc.</li>
          <li><em>(Do not use more than one space around these operators)</em></li>
        </ul>
      </li>
    </ul>
  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/whitespace.coffee %}{% endhighlight %}
  </div>
</div>

<div class="section" id="coffee-comments">
  <div class="col">
    <h3>Comments</h3>

    <p>If modifying code that is described by an existing comment, update the comment such that it accurately reflects the new code. (If possible, improve the code to be clear and concise, and delete the comment entirely.)</p>

    <p>The first word of the comment should be capitalized, unless the first word is an identifier that begins with a lower-case letter.</p>

    <p>If a comment is short, the period at the end can be omitted.</p>

    <h4>Block Comments</h4>

    <ul>
      <li>Block comments apply to the block of code that follows them.</li>
      <li>Each line of a block comment starts with a <code>#</code> and a single space, and should be indented at the same level of the code that it describes.</li>
      <li>Paragraphs inside of block comments are separated by a line containing a single <code>#</code>.</li>
      <li>Use Markdown in your block comments, if applicable.</li>
    </ul>

    <h4>Inline Comments</h4>

    <ul>
      <li>Inline comments are placed on the line immediately above the statement that they are describing. If the inline comment is sufficiently short, it can be placed on the same line as the statement (separated by a single space from the end of the statement).</li>
      <li>All inline comments should start with a <code>#</code> and a single space.</li>
      <li>Do not use inline comments when they state the obvious. Only include them when they can be useful to the developer reading them.</li>
    </ul>

  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/comments.coffee %}{% endhighlight %}
  </div>
</div>

<div class="section" id="coffee-naming">
  <div class="col">
    <h3>Naming Conventions</h3>

    <p>Use <code>camelCase</code> (with a leading lowercase character) to name all variables, methods, and object properties.</p>

    <p>Use <code>UpperCamelCase</code> (with a leading uppercase character) to name all classes.</p>

    <p><em>(The <strong>official</strong> CoffeeScript convention is camelCase, because this simplifies interoperability with JavaScript. For more on this decision, see [here][coffeescript-issue-425].)</em></p>

    <p>Methods and variables that are intended to be "private" should begin with a leading underscore.</p>

  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/naming.coffee %}{% endhighlight %}
  </div>
</div>

<div class="section" id="coffee-functions">
  <div class="col">
    <h3>Functions</h3>

    <p><em>(These guidelines also apply to the methods of a class.)</em></p>

    <ul>
      <li>When declaring a function that takes arguments, always use a single space after the closing parenthesis of the arguments list</li>
      <li>Do not use parentheses when declaring functions that take no arguments</li>
      <li>In cases where method calls are being chained and the code does not fit on a single line, each call should be placed on a separate line and indented by one level (i.e., two spaces), with a leading <code>.</code></li>
      <li>Most importantly, be consistent</li>
    </ul>

  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/functions.coffee %}{% endhighlight %}
  </div>
</div>

<div class="section" id="coffee-strings">
  <div class="col">
    <h3>Strings</h3>

    <ul>
      <li>Use string interpolation instead of string concatenation</li>
      <li>Prefer double quoted strings (<code>""</code>) instead of single quoted (<code>''</code>) strings</li>
    </ul>

  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/strings.coffee %}{% endhighlight %}
  </div>
</div>

<div class="section" id="coffee-conditionals">
  <div class="col">
    <h3>Conditionals</h3>

    <ul>
      <li>Favour <code>unless</code> over <code>if</code> for negative conditions, especially for trailing conditions</li>
      <li>Instead of using <code>unless...else</code>, use <code>if...else</code></li>
      <li>Multi-line if/else clauses should use indentation</li>
    </ul>

  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/conditionals.coffee %}{% endhighlight %}
  </div>
</div>

<div class="section" id="coffee-looping">
  <div class="col">
    <h3>Looping and Comprehensions</h3>

    <ul>
      <li>Take advantage of comprehensions whenever possible</li>
    </ul>

  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/looping.coffee %}{% endhighlight %}
  </div>
</div>

<div class="section" id="coffee-annotations">
  <div class="col">
    <h3>Annotations</h3>

    <ul>
      <li>Use annotations when necessary to describe a specific action that must be taken against the indicated block of code</li>
      <li>Write the annotation on the line immediately above the code that the annotation is describing.</li>
      <li>The annotation keyword should be followed by a colon and a space, and a descriptive note.</li>
    </ul>

    <p>Annotation types:</p>

    <ul>
      <li><code>TODO</code>: describe missing functionality that should be added at a later date</li>
      <li><code>FIXME</code>: describe broken code that must be fixed</li>
      <li><code>OPTIMIZE</code>: describe code that is inefficient and may become a bottleneck</li>
      <li><code>HACK</code>: describe the use of a questionable (or ingenious) coding practice</li>
      <li><code>REVIEW</code>: describe code that should be reviewed to confirm implementation</li>
    </ul>

    <p>If a custom annotation is required, the annotation should be documented in the project's README.</p>

  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/annotations.coffee %}{% endhighlight %}
  </div>
</div>

<div class="section" id="coffee-miscellaneous">
  <div class="col">
    <h3>Miscellaneous</h3>

    <ul>
      <li>Prefer shorthand notation (::) for accessing an object's prototype</li>
      <li>Prefer <code>@property</code> over <code>this.property</code></li>
      <li>However, avoid the use of <strong>standalone</strong> <code>@</code></li>
      <li>Avoid <code>return</code> where not required, unless the explicit return increases clarity</li>
      <li>Use splats (<code>...</code>) when working with functions that accept variable numbers of arguments</li>
    </ul>

  </div>

  <div class="col">
    {% highlight coffee %}{% include coffee/miscellaneous.coffee %}{% endhighlight %}
  </div>
</div>


<div class="heading" id="php">
  <h2>PHP</h2>
</div>

<div class="section" id="php-introduction">
  <div class="col">
    <h3>PHP</h3>
  </div>

</div>

<div class="section" id="php-quotes">
  <div class="col">
    <h3>Single and Double Quotes</h3>

    <p>Use single and double quotes when appropriate. If you’re not evaluating anything in the string, use single quotes. You should almost never have to escape quotes in a string, because you can just alternate your quoting style.</p>
    <p>Text that goes into attributes should be run through <code>esc_attr()</code> so that single or double quotes do not end the attribute value and invalidate the HTML and cause a security issue. See <a href="http://codex.wordpress.org/Data_Validation">Data Validation</a> in the Codex for further details.</p>
  </div>

  <div class="col">
    {% highlight php %}{% include php/quotes.php %}{% endhighlight %}
  </div>

</div>

<div class="section" id="php-indentation">
  <div class="col">
    <h3>Indentation</h3>

    <ul>
      <li>Use soft tabs with two spaces—they're the only way to guarantee code renders the same in any environment.</li>
      <li>Nested elements should be indented once (two spaces).</li>
    </ul>
  </div>

</div>

<div class="section" id="php-brace-style">
  <div class="col">
    <h3>Brace Style</h3>

    <ul>
      <li>Braces should always be used, even when they are not required</li>
      <li>If you have a really long block, consider whether it can be broken into two or more shorter blocks or functions. If you consider such a long block unavoidable, please put a short comment at the end so people can tell at glance what that ending brace ends – typically this is appropriate for a logic block, longer than about 35 rows, but any code that’s not intuitively obvious can be commented</li>
      <li>Template files should use the <a href="http://www.php.net//manual/en/control-structures.alternative-syntax.php">alternative syntax for control structures</a>.
    </ul>
  </div>

  <div class="col">
    {% highlight php %}{% include php/braces.php %}{% endhighlight %}
  </div>

</div>

<div class="section" id="php-function-guards">
  <div class="col">
    <h3>Function Guards</h3>

    <p>Most theme-specific functions should be wrapped in a <code>function_exists</code> test to allow child themes to override them. The function guard should use the alternative <code>if endif</code> syntax.</p>
  </div>

  <div class="col">
  {% highlight php %}{% include php/guards.php %}{% endhighlight %}
  </div>

</div>

<div class="section" id="php-regular-expressions">
  <div class="col">
    <h3>Regular Expressions</h3>

    <p>Perl compatible regular expressions (<a href="http://php.net/pcre">PCRE</a>, <code>preg_</code> functions) should be used in preference to their POSIX counterparts. Never use the <code>/e</code> switch, use <code>preg_replace_callback</code> instead.</p>
    <p>It’s most convenient to use single-quoted strings for regular expressions since, contrary to double-quoted strings, they have only two metasequences: <code>\'</code> and <code>\\</code>.</p>

  </div>

</div>

<div class="section" id="php-spaces">
  <div class="col">
    <h3>Space Usage</h3>

    <ul>
      <li>Always put spaces after commas, and on both sides of logical, comparison, string and assignment operators.</li>
      <li>Put spaces on both sides of the opening and closing parenthesis of <code>if</code>, <code>elseif</code>, <code>foreach</code>, <code>for</code>, and <code>switch</code> blocks.</li>
      <li>When referring to array items, only include a space around the index if it is a variable.</li>
    </ul>
  </div>

  <div class="col">
    {% highlight php %}{% include php/spaces.php %}{% endhighlight %}
  </div>

</div>

<div class="section" id="php-sql-statements">
  <div class="col">
    <h3>Formatting SQL statements</h3>

    <p>When formatting SQL statements you may break it into several lines and indent if it is sufficiently complex to warrant it. Most statements work well as one line though. Always capitalize the SQL parts of the statement like <code>UPDATE</code> or <code>WHERE</code>.</p>

    <p>Functions that update the database should expect their parameters to lack SQL slash escaping when passed. Escaping should be done as close to the time of the query as possible, preferably by using <code>$wpdb-&gt;prepare()</code></p>

    <p><code>$wpdb-&gt;prepare()</code> is a method that handles escaping, quoting, and int-casting for SQL queries. It uses a subset of the <code>sprintf()</code> style of formatting.</p>

    <p><code>%s</code> is used for string placeholders and <code>%d</code> is used for integer placeholders. Note that they are not ‘quoted’! <code>$wpdb-&gt;prepare()</code> will take care of escaping and quoting for us. The benefit of this is that we don’t have to remember to manually use <code><a href="http://codex.wordpress.org/Function_Reference/esc_sql">esc_sql</a>()</code>, and also that it is easy to see at a glance whether something has been escaped or not, because it happens right when the query happens.</p>

    <p>See <a title="Data Validation" href="http://codex.wordpress.org/Data_Validation" target="_blank">Data Validation</a> in the Codex for more information.</p>
  </div>

  <div class="col">
    {% highlight php %}{% include php/sql-statements.php %}{% endhighlight %}
  </div>

</div>

<div class="section" id="php-database-queries">
  <div class="col">
    <h3>Database Queries</h3>

    <p>Avoid touching the database directly. If there is a defined function that can get the data you need, use it. Database abstraction (using functions instead of queries) helps keep your code forward-compatible and, in cases where results are cached in memory, it can be many times faster.</p>

    <p>If you must touch the database, get in touch with some developers by posting a message to the <a title="wp-hackers mailing list" href="http://codex.wordpress.org/Mailing_Lists#Hackers" target="_blank">wp-hackers mailing list</a>. They may want to consider creating a function for the next WordPress version to cover the functionality you wanted.</p>

  </div>
</div>

<div class="section" id="php-naming">
  <div class="col">
    <h3>Naming Conventions</h3>

    <p>Use lowercase letters in variable, action, and function names (never <code>camelCase</code>). Separate words via underscores. Don’t abbreviate variable names un-necessarily; let the code be unambiguous and self-documenting.</p>

    <ul>
      <li>Class names should use capitalized words separated by underscores. Any acronyms should be all upper case.</li>
      <li>Files should be named descriptively using lowercase letters. Hyphens should separate words.</li>
    </ul>

    <p>Class file names should be based on the class name with <code>class-</code> prepended and the underscores in the class name replaced with hyphens.</p>

    <p>This file-naming standard is for all current and new files with classes. There is one exception for three files that contain code that got ported into BackPress: class.wp-dependencies.php, class.wp-scripts.php, class.wp-styles.php. Those files are prepended with <code>class.</code>, a dot after the word class instead of a hyphen.</p>

    <p>Files containing template tags in <code>wp-includes</code> should have <code>-template</code> appended to the end of the name so that they are obvious.</p>
  </div>

  <div class="col">
    {% highlight php %}{% include php/naming.php %}{% endhighlight %}
  </div>

</div>

<div class="section" id="php-self-explanatory">
  <div class="col">
    <h3>Self-Explanatory Flag Values for Function Arguments</h3>

    <p>Prefer string values to just <code>true</code> and <code>false</code> when calling functions.</p>

    <p>Since PHP doesn’t support named arguments, the values of the flags are meaningless, and each time we come across a function call like the examples above, we have to search for the function definition. The code can be made more readable by using descriptive string values, instead of booleans.</p>

  </div>

  <div class="col">
    {% highlight php %}{% include php/self-explanatory.php %}{% endhighlight %}
  </div>

</div>

<div class="section" id="php-ternary-operator">
  <div class="col">
    <h3>Ternary Operator</h3>

    <p><a title="Ternary" href="http://en.wikipedia.org/wiki/Ternary_operation" target="_blank">Ternary</a> operators are fine, but always have them test if the statement is true, not false. Otherwise, it just gets confusing. (An exception would be using <code>! empty()</code>, as testing for false here is generally more intuitive.)</p>

  </div>

  <div class="col">
    {% highlight php %}{% include php/ternary.php %}{% endhighlight %}
  </div>

</div>

<div class="section" id="php-yoda-conditions">
  <div class="col">
    <h3>Yoda Conditions</h3>

    <p>When doing logical comparisons, always put the variable on the right side, constants or literals on the left.</p>

    <p>In the above example, if you omit an equals sign (admit it, it happens even to the most seasoned of us), you’ll get a parse error, because you can’t assign to a constant like <code>true</code>. If the statement were the other way around <code>( $the_force = true )</code>, the assignment would be perfectly valid, returning <code>1</code>, causing the if statement to evaluate to <code>true</code>, and you could be chasing that bug for a while.</p>

    <p>A little bizarre, it is, to read. Get used to it, you will.</p>

    <p>This applies to <code>==</code>, <code>!=</code>, <code>===</code>, and <code>!==</code>. Yoda conditions for <code>&lt;</code>, <code>&gt;</code>, <code>&lt;=</code> or <code>&gt;=</code> are significantly more difficult to read and are best avoided.</p>

  </div>

  <div class="col">
    {% highlight php %}{% include php/yoda-conditions.php %}{% endhighlight %}
  </div>

</div>

<div class="section" id="php-miscellaneous">
  <div class="col">
    <h3>Miscellaneous</h3>

    <ul>
      <li>Never use shorthand PHP start tags</li>
      <li>Always use full PHP tags</li>
      <li>Remove trailing whitespace at the end of each line of code</li>
      <li>Omitting the closing PHP tag at the end of a file is preferred</li>
      <li>In general, readability is more important than cleverness or brevity</li>
    </ul>
  </div>

  <div class="col">
    {% highlight php %}{% include php/miscellaneous.php %}{% endhighlight %}
  </div>

</div>



<div class="heading" id="git">
  <h2>Git</h2>
</div>

<div class="section" id="git-introduction">
  <div class="col">
    <h3>An introduction to Git</h3>

    <p>At its most basic, source control gives us the ability to store, share, and transport code and code changes, but the real value comes from the ability to record and replay the stories behind each change during the lifetime of a project.</p>

    <p>This is <em>not</em> an intro to source control or a git how-to: we assume that you have an intermediate understanding of how to use git. If you’re new to git, chapters 2, 3, and 6 (through the section on interactive rebasing) of Scott Chacon’s <a href="http://git-scm.com/book">git book</a> will tell you the how.</p>

    <p>It doesn’t matter if you use git’s commands or a GUI (see <a href="http://mac.github.com">GitHub for Mac</a> and <a href="http://gitboxapp.com">Gitbox</a>), but you need a confident understanding of what’s happening regardless. Knowing the commands often helps.</p>
  </div>
</div>

<div class="section" id="git-repos">
  <div class="col">
    <h3>Repo Naming</h3>
    <p>To keep our many repositories easy to find we follow a simple naming convention:</p>
    <ul>
      <li>Names are all lowercase, with hyphens as separators.</li>
      <li>Themes are suffixed by their platform: -shopify, -wp, -tumblr, -ghost.</li>
      <li>Tools are prefixed by their platform: wp-calcium, shopify-skeleton.</li>
      <li>Theme forks for client customizations are named theme-client-platform.</li>
    </ul>
  </div>

  <div class="col">
    {% highlight bash %}{% include git/repos.txt %}{% endhighlight %}
  </div>
</div>

<div class="section" id="git-setup">
  <div class="col">
    <h3>Setup</h3>

    <p>Things to do right away:</p>

    <ul>
      <li>Set your author metadata</li>
      <li>Set branch.autosetuprebase</li>
      <li>Set push.default</li>
      <li>Set core.editor (optional)</li>
    </ul>
  </div>

  <div class="col">
    {% highlight bash %}{% include git/setup.txt %}{% endhighlight %}
  </div>
</div>

<div class="section" id="git-branches">
  <div class="col">
    <h3>Branches and Pull Requests</h3>

    <p><strong>Never commit directly to master.</strong> Instead, create small branches for each and every topic you work on (such as a feature or bug fix), and create a pull request into master when the branch is complete.</p>

    <p><em>The exception to this rule is <a href="#git-tagging">version commits and tags</a>.</em></p>

    <h4>Naming</h4>

    <ul>
      <li>Name branches as concisely as possible, separated by <strong>underscores</strong>.</li>
      <li>Don't use version numbers</li>
    </ul>

    <h4>Long-Running Branches</h4>

    <p>If your branch cannot be named as a specific function/feature/bug then you can create a long-running branch with a name like <code>multiple_fixes</code>.</p>

    <p>When using this method, it's important that the commits are <em>clear</em> and minimal (see <a href="#git-comments">Commits</a>).</p>
  </div>

  <div class="col">
    {% highlight bash %}{% include git/branches.txt %}{% endhighlight %}
  </div>
</div>

<div class="section" id="git-commits">
  <div class="col">
    <h3>Commits</h3>

    <p>Please read Stephen Ball’s Steel City Ruby 2013 presentation, <a href="http://rakeroutes.com/blog/deliberate-git/">Deliberate Git</a>. It covers this topic very well.</p>

    <p>Once you’ve read it, you’ll understand why you should:</p>

    <ul>
      <li>Commit small changes frequently. Only you see your local commits, so <code>WIP</code> is fine.</li>
      <li>Rebase local commits before pushing &amp; pull requesting.</li>
      <li>Write commit subjects in the present tense and as a command.</li>
      <li>Describe what the code <em>change</em> does, not what the code does.</li>
      <li>Explain why the change is necessary.</li>
      <li>Mention alternatives you considered and potential consequences of your solution.</li>
    </ul>

    <p>When writing commits:</p>

    <ul>
      <li>Start with a capitalized word</li>
      <li>Wrap at 70 characters (tell your editor to do this for you)</li>
      <li>Spell correctly (optionally, install a precommit spell-checker hook)</li>
      <li>Include blank lines after the first line and between paragraphs in multi-line messages</li>
    </ul>
  </div>

  <div class="col">
    {% highlight bash %}{% include git/commits.txt %}{% endhighlight %}
  </div>
</div>

<div class="section" id="git-pushing">
  <div class="col">
    <h3>Pushing</h3>

    <p>If you’re pushing a new branch, use the <code>--set-upstream</code> (<code>-u</code>) flag to automatically set the remote branch as your local branch’s tracking branch.</p>
  </div>

  <div class="col">
    {% highlight bash %}{% include git/pushing.txt %}{% endhighlight %}
  </div>
</div>

<div class="section" id="git-merging">
  <div class="col">
    <h3>Merging</h3>

    <p>So your pull request has been peer-reviewed and approved – nice work! Now it's time to merge your changes into master.</p>

    <p>You want to use a fast-forward merge (<code>git merge --ff-only</code>). Merging this way prevents "merge bubbles" where commit messages are created that say that a branch has been merged. This is called a recursive merge and it muddies up the commit history.</p>
  </div>

  <div class="col">
    {% highlight bash %}{% include git/merging.txt %}{% endhighlight %}
  </div>
</div>

<div class="section" id="git-tagging">
  <div class="col">
    <h3>Tagging and Releasing</h3>

    <p>Versioned libraries, both internal and public, should follow these practices:</p>

    <ul>
      <li>Use a <code>major_feature.minor_feature/major_bugfix.minor_bugfix</code> numbering scheme</li>
      <li>Remember to update documentation and version constants</li>
      <li>Always create and push a tag with the version number, prefixed with a <code>v</code></li>
    </ul>
  </div>

  <div class="col">
    {% highlight bash %}{% include git/tagging.txt %}{% endhighlight %}
  </div>
</div>