<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>https://wiki.openstack.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Aaron+Sahlin</id>
		<title>OpenStack - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="https://wiki.openstack.org/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Aaron+Sahlin"/>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/wiki/Special:Contributions/Aaron_Sahlin"/>
		<updated>2026-06-30T19:41:46Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.28.2</generator>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71992</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71992"/>
				<updated>2015-01-16T21:55:56Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* AngularJS */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
The following standards are divided into required and recommended sections. Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
*  The code has to work on the stable and latest versions of Firefox, Chrome, Safari, and Opera web browsers, and on Microsoft Internet Explorer 9 and later.&lt;br /&gt;
*  If you turned compression off during development via 'COMPRESS_ENABLED = False' in local_settings.py, re-enable compression and test your code before submitting.&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Avoid statements such as 'element.css({property1,property2...})' they belong in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Avoid statements such as &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; they belong&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
* Use CamelCase. &amp;quot;HelloWorld&amp;quot; for classes or object prototype functions, and &amp;quot;helloWorld&amp;quot; for other uses (function declarations etc.)&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model. Forms must operate on properties objects on the scope, not on properties of the $scope directly (that is, ng-model must operate on dotted names). This holds for other directives modifying model data as well.&lt;br /&gt;
&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of text in JavaScript files use either 'gettext(&amp;quot;translatable text&amp;quot;)' or 'ngettext(&amp;quot;translatable text&amp;quot;)'.   Only those two methods are recognized by our tools and will be included in the '.po' file after running './run_tests --makemessages'.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
  // Recognized by our tooling                               // Not recognized&lt;br /&gt;
  gettext(&amp;quot;translatable text&amp;quot;);                              var _ = gettext;&lt;br /&gt;
  ngettext(&amp;quot;translatable text&amp;quot;);                             _('translatable text');&lt;br /&gt;
  &lt;br /&gt;
                                                             $window.gettext('translatable text');&lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }).service('my_service', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  });&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71979</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71979"/>
				<updated>2015-01-16T20:08:22Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
The following standards are divided into required and recommended sections. Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
*  The code has to work on the stable and latest versions of Firefox, Chrome, Safari, and Opera web browsers, and on Microsoft Internet Explorer 9 and later.&lt;br /&gt;
*  If you turned compression off during development via 'COMPRESS_ENABLED = False' in local_settings.py, re-enable compression and test your code before submitting.&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Avoid statements such as 'element.css({property1,property2...})' they belong in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Avoid statements such as &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; they belong&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
* Use CamelCase. &amp;quot;HelloWorld&amp;quot; for classes or object prototype functions, and &amp;quot;helloWorld&amp;quot; for other uses (function declarations etc.)&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model. Forms must operate on properties objects on the scope, not on properties of the $scope directly (that is, ng-model must operate on dotted names). This holds for other directives modifying model data as well.&lt;br /&gt;
&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of text in JavaScript files use either 'gettext(&amp;quot;translatable text&amp;quot;)' or 'ngettext(&amp;quot;translatable text&amp;quot;)'.   Only those two methods are recognized by our tools and will be included in the '.po' file after running './run_tests --makemessages'.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }).service('my_service', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  });&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71978</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71978"/>
				<updated>2015-01-16T20:07:43Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
The following standards are divided into required and recommended sections. Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
*  The code has to work on the stable and latest versions of Firefox, Chrome, Safari, and Opera web browsers, and on Microsoft Internet Explorer 9 and later.&lt;br /&gt;
*  If you turned compression off during development via 'COMPRESS_ENABLED = False' in local_settings.py, re-enable compression and test your code before submitting.&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Avoid statements such as 'element.css({property1,property2...})' they belong in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Avoid statements such as &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; they belong&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
* Use CamelCase. &amp;quot;HelloWorld&amp;quot; for classes or object prototype functions, and &amp;quot;helloWorld&amp;quot; for other uses (function declarations etc.)&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model. Forms must operate on properties objects on the scope, not on properties of the $scope directly (that is, ng-model must operate on dotted names). This holds for other directives modifying model data as well.&lt;br /&gt;
&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of text in JavaScript files use 'gettext(&amp;quot;translatable text&amp;quot;)' or 'ngettext(&amp;quot;translatable text&amp;quot;)'.   Only those methods are recognized by our tools and will be included in the '.po' file after running './run_tests --makemessages'.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }).service('my_service', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  });&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71974</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71974"/>
				<updated>2015-01-16T18:10:50Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
The following standards are divided into required and recommended sections. Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
*  The code has to work on the stable and latest versions of Firefox, Chrome, Safari, and Opera web browsers, and on Microsoft Internet Explorer 9 and later.&lt;br /&gt;
*  If you turned compression off during development via 'COMPRESS_ENABLED = False' in local_settings.py, re-enable compression and test your code before submitting.&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Avoid statements such as 'element.css({property1,property2...})' they belong in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Avoid statements such as &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; they belong&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
* Use CamelCase. &amp;quot;HelloWorld&amp;quot; for classes or object prototype functions, and &amp;quot;helloWorld&amp;quot; for other uses (function declarations etc.)&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model. Forms must operate on properties objects on the scope, not on properties of the $scope directly (that is, ng-model must operate on dotted names). This holds for other directives modifying model data as well.&lt;br /&gt;
&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of text in JavaScript files use 'gettext(&amp;quot;translatable text&amp;quot;)'.   Only 'gettext' is recognized by our tools and will be included in the '.po' file after running './run_tests --makemessages'.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }).service('my_service', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  });&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71973</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71973"/>
				<updated>2015-01-16T18:08:36Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
The following standards are divided into required and recommended sections. Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
*  The code has to work on the stable and latest versions of Firefox, Chrome, Safari, and Opera web browsers, and on Microsoft Internet Explorer 9 and later.&lt;br /&gt;
*  If you turned compression off during development via 'COMPRESS_ENABLED = False' in local_settings.py, re-enable compression and test your code before submitting.&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Avoid statements such as 'element.css({property1,property2...})' they belong in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Avoid statements such as &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; they belong&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
* Use CamelCase. &amp;quot;HelloWorld&amp;quot; for classes or object prototype functions, and &amp;quot;helloWorld&amp;quot; for other uses (function declarations etc.)&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model. Forms must operate on properties objects on the scope, not on properties of the $scope directly (that is, ng-model must operate on dotted names). This holds for other directives modifying model data as well.&lt;br /&gt;
&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of text in JavaScript files use 'gettext(&amp;quot;translatable text&amp;quot;)'.   Only 'gettext' is recognized by our tools and will be included in the po file after running './run_tests --makemessages'.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }).service('my_service', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  });&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71969</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=71969"/>
				<updated>2015-01-16T18:01:49Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
The following standards are divided into required and recommended sections. Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
*  The code has to work on the stable and latest versions of Firefox, Chrome, Safari, and Opera web browsers, and on Microsoft Internet Explorer 9 and later.&lt;br /&gt;
*  If you turned compression off during development via 'COMPRESS_ENABLED = False' in local_settings.py, re-enable compression and test your code before submitting.&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Avoid statements such as 'element.css({property1,property2...})' they belong in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Avoid statements such as &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; they belong&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
* Use CamelCase. &amp;quot;HelloWorld&amp;quot; for classes or object prototype functions, and &amp;quot;helloWorld&amp;quot; for other uses (function declarations etc.)&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model. Forms must operate on properties objects on the scope, not on properties of the $scope directly (that is, ng-model must operate on dotted names). This holds for other directives modifying model data as well.&lt;br /&gt;
&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of text in JavaScript files use 'gettext(&amp;quot;translatable text&amp;quot;)'.   Only 'gettext' is recognized by our tools and will be included in the po file after running './run_tests --makemessages'.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }).service('my_service', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  });&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Meetings/Horizon&amp;diff=67398</id>
		<title>Meetings/Horizon</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Meetings/Horizon&amp;diff=67398"/>
				<updated>2014-11-06T20:48:16Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Agenda for next meeting (Nov 11) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;br /&gt;
The [[OpenStack]] [[Horizon]] Team holds public meetings in #openstack-meeting-3. Everyone is encouraged to attend. &lt;br /&gt;
* Tuesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&amp;amp;min=0&amp;amp;sec=0 16:00 UTC]&lt;br /&gt;
&lt;br /&gt;
== Apologies for absence ==&lt;br /&gt;
&lt;br /&gt;
== No Meeting Nov 4 ==&lt;br /&gt;
== Agenda for next meeting (Nov 11) ==&lt;br /&gt;
What is Horizon's accessibility statement?   Do we have one?&lt;br /&gt;
I ran across https://wiki.openstack.org/wiki/Horizon/WebAccessibility, who is author any follow up?    (asahlin)&lt;br /&gt;
&lt;br /&gt;
== Previous meetings ==&lt;br /&gt;
&lt;br /&gt;
http://eavesdrop.openstack.org/meetings/horizon/&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=67272</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=67272"/>
				<updated>2014-11-04T19:21:36Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Code Style */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
The following standards are divided into required and recommended sections. Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
*  The code has to work on the stable and latest versions of Firefox, Chrome, Safari, and Opera web browsers, and on Microsoft Internet Explorer 9 and later.&lt;br /&gt;
*  If you turned compression off during development via 'COMPRESS_ENABLED = False' in local_settings.py, re-enable compression and test your code before submitting.&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Avoid statements such as 'element.css({property1,property2...})' they belong in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Avoid statements such as &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; they belong&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', ['$scope', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=67271</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=67271"/>
				<updated>2014-11-04T19:20:48Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Code Style */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
The following standards are divided into required and recommended sections. Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
*  The code has to work on the stable and latest versions of Firefox, Chrome, Safari, and Opera web browsers, and on Microsoft Internet Explorer 9 and later.&lt;br /&gt;
*  If you turned compression off during development via 'COMPRESS_ENABLED = False' in local_settings.py, re-enable compression and test your code before submitting.&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Avoid statements such as 'element.css({property1,property2...})' they belong in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Avoid statements such as &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; they belong&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
----&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', ['$scope', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=67270</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=67270"/>
				<updated>2014-11-04T19:10:52Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Code Style Guidelines */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', ['$scope', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=67269</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=67269"/>
				<updated>2014-11-04T19:10:10Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
----&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', ['$scope', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62951</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62951"/>
				<updated>2014-09-17T18:49:16Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* ****** Under Construction ****** */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', ['$scope', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62950</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62950"/>
				<updated>2014-09-17T18:48:47Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Recommended: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
  angular.module('_module').controller('_controller', ['$scope', function($scope) {&lt;br /&gt;
     // controller code&lt;br /&gt;
  }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
    // service code&lt;br /&gt;
  }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62949</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62949"/>
				<updated>2014-09-17T18:47:28Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* JSHint */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks. Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed. Since JSHint has a ton of configuration options to choose from, links are provided below to the options Horizon wants enforced along with the instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62948</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62948"/>
				<updated>2014-09-17T18:45:19Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using 'gettext' or 'ngettext' function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use '{% trans %}' and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62947</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62947"/>
				<updated>2014-09-17T18:42:13Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses '{{ }}', use '{$ $}' or '{% verbatim %}' instead.&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62946</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62946"/>
				<updated>2014-09-17T18:41:08Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described in the Recommended section.&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62945</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62945"/>
				<updated>2014-09-17T18:39:32Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such as 'horizon/static/horizon/js/angular/hz.table.js'). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62944</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62944"/>
				<updated>2014-09-17T18:36:54Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Recommended: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommended but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use '{ }' for 'if', 'for', 'while' statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62943</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62943"/>
				<updated>2014-09-17T18:35:06Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Recommended: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;br /&gt;
&lt;br /&gt;
===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62942</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62942"/>
				<updated>2014-09-17T18:34:29Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Code Style Guidelines */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;br /&gt;
&lt;br /&gt;
'===JSHint===&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62941</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62941"/>
				<updated>2014-09-17T18:33:37Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62940</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62940"/>
				<updated>2014-09-17T18:32:36Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
 &lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62939</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62939"/>
				<updated>2014-09-17T18:32:01Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if &lt;br /&gt;
          dynamic content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to&lt;br /&gt;
          attributes.&lt;br /&gt;
           For example to find a div: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62938</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62938"/>
				<updated>2014-09-17T18:30:50Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
 &lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
 &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
          class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to attributes.&lt;br /&gt;
           For example to find a div: &lt;br /&gt;
           &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
           $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62937</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62937"/>
				<updated>2014-09-17T18:28:20Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate&lt;br /&gt;
     style elements. &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
           class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
           in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content&lt;br /&gt;
           is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to attributes.&lt;br /&gt;
           For example to find a div: &lt;br /&gt;
           &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
           $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62936</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62936"/>
				<updated>2014-09-17T18:27:28Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
          instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
           class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
           in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content&lt;br /&gt;
           is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to attributes.&lt;br /&gt;
           For example to find a div: &lt;br /&gt;
           &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
           $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62935</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62935"/>
				<updated>2014-09-17T18:27:08Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
           instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
           class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
           in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content&lt;br /&gt;
           is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to attributes.&lt;br /&gt;
           For example to find a div: &lt;br /&gt;
           &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
           $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62934</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62934"/>
				<updated>2014-09-17T18:26:37Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&amp;lt;nowiki&amp;gt;&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
           instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
           class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
           in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content&lt;br /&gt;
           is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to attributes.&lt;br /&gt;
           For example to find a div: &lt;br /&gt;
           &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
           $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62933</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62933"/>
				<updated>2014-09-17T18:25:57Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
       1. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
       2. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
           instead&lt;br /&gt;
 &lt;br /&gt;
   * In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
       1. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
           class.&lt;br /&gt;
       2. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
           in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content&lt;br /&gt;
           is required.&lt;br /&gt;
       3. Avoid using classes for detection purposes only, instead, defer to attributes.&lt;br /&gt;
           For example to find a div: &lt;br /&gt;
           &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
           $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
           Is better found like: &lt;br /&gt;
             &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
             $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62930</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62930"/>
				<updated>2014-09-17T18:24:35Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   * In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
         instead&lt;br /&gt;
 &lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
         class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content&lt;br /&gt;
          is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.&lt;br /&gt;
          For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62927</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62927"/>
				<updated>2014-09-17T18:23:55Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes&lt;br /&gt;
         instead&lt;br /&gt;
 &lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like 'element.css({property1,property2...})' belongs in a CSS&lt;br /&gt;
         class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs&lt;br /&gt;
          in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content&lt;br /&gt;
          is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.&lt;br /&gt;
          For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62924</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62924"/>
				<updated>2014-09-17T18:22:17Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like 'element.css({property1,property2...})' belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62923</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62923"/>
				<updated>2014-09-17T18:20:42Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random '&amp;lt;script&amp;gt;' and '&amp;lt;style&amp;gt;' elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like 'element.css({property1,property2...})' belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;'$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)'&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use 'show' | 'hide' | 'clone' elements if dynamic content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62922</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62922"/>
				<updated>2014-09-17T18:18:03Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put 'var' in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'eval( )'''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The 'with' statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62921</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62921"/>
				<updated>2014-09-17T18:14:21Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
     (function(){&lt;br /&gt;
        'use strict'; &lt;br /&gt;
         // code...&lt;br /&gt;
     }) ();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62920</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62920"/>
				<updated>2014-09-17T18:13:22Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: &lt;br /&gt;
            (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62919</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62919"/>
				<updated>2014-09-17T18:10:18Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  Note:  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript/EditorConfig&amp;diff=62468</id>
		<title>Horizon/Javascript/EditorConfig</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript/EditorConfig&amp;diff=62468"/>
				<updated>2014-09-11T21:13:23Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Notepad++ */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== JavaScript Editor Configuration ==&lt;br /&gt;
&lt;br /&gt;
The following instructions set up several popular editors to develop JavaScript according to Horizon practices. The instructions set up JSHint and source code formatting for each editor.&lt;br /&gt;
&lt;br /&gt;
=== Eclipse ===&lt;br /&gt;
1. To set the formatter for JavaScript, first go [[Horizon/Javascript/EditorConfig/Settings#Horizon_JS_Formatter.xml|here]] and copy the content and save to Horizon_JS_Formatter.xml.&lt;br /&gt;
&lt;br /&gt;
2. Window &amp;gt; Preferences, JavaScript &amp;gt; Code Style &amp;gt; Formatter.&lt;br /&gt;
&lt;br /&gt;
3. Import Horizon_JS_Formatter.xml.&lt;br /&gt;
&lt;br /&gt;
  This formatter is the Eclipse default for JS, with only the following changes:&lt;br /&gt;
  - Indentation is 2 spaces&lt;br /&gt;
  - Indentation inside switch statements&lt;br /&gt;
  - White Space &amp;gt; Expressions &amp;gt; Object initializers: no space before colon&lt;br /&gt;
  - No formatting of comments&lt;br /&gt;
  - This formatter is close to the Sublime formatter, though further tweaking could make it closer. Eclipse is a bit more aggressive than Sublime's “JavaScript Beautification” in   adding/removing newlines in source.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
4. Find JSHint in the Eclipse Marketplace (Help -&amp;gt; Eclipse Marketplace...). Search for jshint and install the plugin.&lt;br /&gt;
&lt;br /&gt;
5. Go [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|here]] and copy contents of .jshintrc, and copy its contents to the clipboard.&lt;br /&gt;
&lt;br /&gt;
6. Open Window-&amp;gt;Preferences and select JSHint-&amp;gt;Configuration.  Paste in the contents of .jshintrc. Save it.&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Note that it is possible to have different JSHint configurations for each project in Eclipse. To do this, open the project's properties and click JSHint on the left.&lt;br /&gt;
&lt;br /&gt;
=== Sublime ===&lt;br /&gt;
Before you begin:&lt;br /&gt;
Sublime Text 3 should already be installed. See http://www.sublimetext.com/3.&lt;br /&gt;
If you do not see “Package Control” under Preferences in Sublime, then install Package Control: https://sublime.wbond.net/installation&lt;br /&gt;
&lt;br /&gt;
Node should already be installed. If not: &lt;br /&gt;
&lt;br /&gt;
'''sudo apt-get install nodejs&lt;br /&gt;
&lt;br /&gt;
sudo apt-get install npm&lt;br /&gt;
&lt;br /&gt;
sudo ln -s /usr/bin/nodejs /usr/bin/node'''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Here we go:&lt;br /&gt;
&lt;br /&gt;
1. Install jshint using Node. Assuming you are in the ~ directory:&lt;br /&gt;
&lt;br /&gt;
npm install jshint&lt;br /&gt;
&lt;br /&gt;
sudo ln -s ~/node_modules/jshint/bin/jshint /usr/bin/jshint&lt;br /&gt;
&lt;br /&gt;
At a command line, type “where jshint” (Windows) or “which jshint” (Linux) to be sure it is available on the path.&lt;br /&gt;
&lt;br /&gt;
2. Go [[Horizon/Javascript/EditorConfig/EclipseFormatter#.jshintrc|here]] and copy contents of .jshintrc, and save to file .jshintrc in a directory at some level above the files you will be editing—for example, the top horizon directory. For Windows, rename it to jshint.conf.&lt;br /&gt;
&lt;br /&gt;
3. In Sublime, Preferences &amp;gt; Package Control &amp;gt; Install Package. Wait a moment for the list of all packages, then search and select Javascript Beautify.&lt;br /&gt;
&lt;br /&gt;
4. Preferences &amp;gt; Package Settings &amp;gt; JavaScript Beautify &amp;gt; Settings – User. Paste in the following and save it:&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
 &amp;quot;indent_size&amp;quot;: 2,&lt;br /&gt;
 &amp;quot;use_original_indentation&amp;quot;: true,&lt;br /&gt;
 &amp;quot;format_on_save&amp;quot;: false&lt;br /&gt;
 }&lt;br /&gt;
 &lt;br /&gt;
 use_original_indentation will allow you to format non-Horizon js files without changing their indentation to 2.&lt;br /&gt;
 &lt;br /&gt;
 format_on_save is a very nice feature. However, it is set to false to safeguard against accidentally reformatting an entire file when you are making a surgical change to it. See the   notes above on formatting.&lt;br /&gt;
&lt;br /&gt;
5. Preferences &amp;gt; Package Control &amp;gt; Install Package &amp;gt; (Wait a moment for the list) &amp;gt; SublimeLinter.&lt;br /&gt;
&lt;br /&gt;
6. Preferences &amp;gt; Package Control &amp;gt; Install Package &amp;gt; Wait a moment for the list &amp;gt; SublimeLinter-jshint.&lt;br /&gt;
&lt;br /&gt;
7. Make sure JSHint is working now. Type the following in a .js file, and see if it complains:&lt;br /&gt;
eval(“i=1”);&lt;br /&gt;
&lt;br /&gt;
If you get a warning, then it is working and you are done.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If JSHint is not working, you can try the following trouble-shooting steps.&lt;br /&gt;
&lt;br /&gt;
1. Preferences &amp;gt; Package Settings &amp;gt; SublimeLinter &amp;gt; Settings-User&lt;br /&gt;
&lt;br /&gt;
2. Make sure it finds .jshintrc by setting the “args” appropriately. For example:&lt;br /&gt;
&amp;quot;linters&amp;quot;: {&lt;br /&gt;
   &amp;quot;jshint&amp;quot;: {&lt;br /&gt;
   &amp;quot;@disable&amp;quot;: false,&lt;br /&gt;
   &amp;quot;args&amp;quot;: [&lt;br /&gt;
     &amp;quot;--config&amp;quot;,&lt;br /&gt;
     &amp;quot;/home/randy/horizon/.jshintrc&amp;quot;&lt;br /&gt;
   ],&lt;br /&gt;
   &amp;quot;excludes&amp;quot;: []&lt;br /&gt;
&lt;br /&gt;
For windows, the path would look like:&lt;br /&gt;
 &amp;quot;args&amp;quot;: [&lt;br /&gt;
      &amp;quot;--config&amp;quot;,&lt;br /&gt;
      &amp;quot;C:\\tools\\jshint.conf&amp;quot;&lt;br /&gt;
  ],&lt;br /&gt;
&lt;br /&gt;
3. Make sure it finds jshint by setting the “paths” appropriately to match “which jshint”. For example:&lt;br /&gt;
&amp;quot;paths&amp;quot;: {&lt;br /&gt;
 &amp;quot;linux&amp;quot;: [&lt;br /&gt;
 &amp;quot;/home/randy/ibm/node/bin&amp;quot;&lt;br /&gt;
 ],&lt;br /&gt;
&lt;br /&gt;
4. After you make changes and save the settings, you must clear the SublimeLinter cache for the changes to take effect: Tools &amp;gt; SublimeLinter &amp;gt; Clear Caches. Then close and reopen Sublime.&lt;br /&gt;
&lt;br /&gt;
While you are at it, you may also want to install some more good plugins: SublimeLinter-pep8, SideBarEnhancements, Git, and GitGutter.&lt;br /&gt;
&lt;br /&gt;
=== PyCharm and WebStorm ===&lt;br /&gt;
1. From the Welcome screen, Configure &amp;gt; Settings; JavaScript &amp;gt; Code Quality Tools &amp;gt; JSHint. Go [[Horizon/Javascript/EditorConfig/EclipseFormatter#.jshintrc|here]] and copy contents of .jshintrc, and save to file .jshintrc in a directory at some level above the files you will be editing—for example, the top horizon directory. For Windows, rename it to jshint.conf.&lt;br /&gt;
&lt;br /&gt;
2. From the Welcome screen, Configure &amp;gt; Settings; JavaScript &amp;gt; Code Quality Tools &amp;gt; JSHint.&lt;br /&gt;
&lt;br /&gt;
3. Check Enable.&lt;br /&gt;
&lt;br /&gt;
4. Check “Use config files.” It will default to .jshintrc, which it will find in a super-directory of the code you are editing.&lt;br /&gt;
&lt;br /&gt;
5. Click Apply. &lt;br /&gt;
&lt;br /&gt;
6. Ensure that JSLint is not enabled (above JSHint), and click OK.&lt;br /&gt;
&lt;br /&gt;
7. See if jshint is working by typing:&lt;br /&gt;
&lt;br /&gt;
eval(“i=1”);&lt;br /&gt;
&lt;br /&gt;
If PyCharm complains about not finding the config file, return to settings and locate the file manually.&lt;br /&gt;
For more detail, see http://www.jetbrains.com/pycharm/webhelp/using-javascript-code-quality-tools.html.&lt;br /&gt;
&lt;br /&gt;
8. From the Welcome screen, Configure &amp;gt; Settings; Code Style &amp;gt; JavaScript. &lt;br /&gt;
&lt;br /&gt;
 The following minor changes to the default settings will bring the JetBrain formatter into closer alignment with the others.&lt;br /&gt;
 In the “Tabs and Indents” tab, change the three tabbing numbers to “2”.&lt;br /&gt;
 In the Spaces tab, uncheck “In function expression”.&lt;br /&gt;
&lt;br /&gt;
9. Click OK.&lt;br /&gt;
&lt;br /&gt;
=== Notepad++ ===&lt;br /&gt;
1. Go [[Horizon/Javascript/EditorConfig/EclipseFormatter#.jshintrc|here]] and copy contents of .jshintrc, paste into text editor and concatenate all the lines.  (You might do this by a global change of all newline characters to nothing or doing Join Lines by selecting the lines you want to join then Choose Edit → Line Operations → Join Lines.) Delete the opening and closing braces, and the “freeze” option. Copy the resulting long line into the clipboard.&lt;br /&gt;
&lt;br /&gt;
2. Open Plugins &amp;gt; Plugin Manager &amp;gt; Show Plugin Manager&lt;br /&gt;
&lt;br /&gt;
3. Select JSLint and JSTool; click Install.&lt;br /&gt;
&lt;br /&gt;
4. Plugins &amp;gt; JSTool &amp;gt; Options. Sent Indent o “2” spaces instead of tab, and click OK.&lt;br /&gt;
&lt;br /&gt;
 Use Plugins &amp;gt; JSTool &amp;gt; JSFormat to reformat.&lt;br /&gt;
 &lt;br /&gt;
 Be warned that this formatter is significantly different from the others, with no options to customize it. If anyone knows of a better plugin for Notepad++ formatting, let me know.&lt;br /&gt;
&lt;br /&gt;
5. Plugins &amp;gt; JSLint &amp;gt; Options.&lt;br /&gt;
&lt;br /&gt;
6. Select JSHint in the top dropdown.&lt;br /&gt;
&lt;br /&gt;
7. Click “Clear All Options”.&lt;br /&gt;
&lt;br /&gt;
8. Paste the string from the clipboard from step 1 into the “Additional” field. Click OK.&lt;br /&gt;
&lt;br /&gt;
 Use Plugins &amp;gt; JSLint &amp;gt; “JSLint current file” to check a file.&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62161</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62161"/>
				<updated>2014-09-05T21:04:06Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  If typecasting is desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62160</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62160"/>
				<updated>2014-09-05T21:03:35Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Code Style Guidelines */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.  If typecasting is&lt;br /&gt;
desired, explicit casting is preferred to keep the meaning of your code clear.&lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62134</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62134"/>
				<updated>2014-09-05T16:35:54Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.   &lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is passed from server to client. However, this depends on the catalog object that is also passed from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62133</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62133"/>
				<updated>2014-09-05T16:34:30Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.   &lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects).  The scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is pass from server to client. However, this depends on the catalog object that is also pass from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62132</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62132"/>
				<updated>2014-09-05T16:30:19Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Recommended: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.   &lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements'', and don't combine them on one line.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects), the scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is pass from server to client. However, this depends on the catalog object that is also pass from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62131</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62131"/>
				<updated>2014-09-05T16:29:35Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Recommended: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.   &lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* ''Use { } for if, for, while statements&amp;quot;, and don't combine them on one line for code maintainability / readability.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects), the scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is pass from server to client. However, this depends on the catalog object that is also pass from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62130</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62130"/>
				<updated>2014-09-05T16:28:32Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Code Style Guidelines */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.   &lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* ''Use 2 space for code Indentation.''&lt;br /&gt;
&lt;br /&gt;
* '''Use { }''' for if, for, while statements, and don't combine them on one line for code maintainability / readability.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects), the scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is pass from server to client. However, this depends on the catalog object that is also pass from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62128</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62128"/>
				<updated>2014-09-05T16:06:15Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Recommended: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.   &lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* ''Source-code formatting'' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* '''Use { }''' for if, for, while statements, and don't combine them on one line for code maintainability / readability.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects), the scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is pass from server to client. However, this depends on the catalog object that is also pass from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62127</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62127"/>
				<updated>2014-09-05T16:05:06Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Code Style Guidelines */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.   &lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* '''Source-code formatting''' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* '''Use { }''' for if, for, while statements, and don't combine them on one line for code maintainability / readability.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects), the scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is pass from server to client. However, this depends on the catalog object that is also pass from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62126</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62126"/>
				<updated>2014-09-05T16:04:23Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Required: */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.   &lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* '''Source-code formatting''' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* '''Use { }''' for if, for, while statements, and don't combine them on one line for code maintainability / readability.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects), the scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is pass from server to client. However, this depends on the catalog object that is also pass from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	<entry>
		<id>https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62125</id>
		<title>Horizon/Javascript</title>
		<link rel="alternate" type="text/html" href="https://wiki.openstack.org/w/index.php?title=Horizon/Javascript&amp;diff=62125"/>
				<updated>2014-09-05T16:04:08Z</updated>
		
		<summary type="html">&lt;p&gt;Aaron Sahlin: /* Code Style Guidelines */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== ****** Under Construction ****** ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Code Style Guidelines ==&lt;br /&gt;
&lt;br /&gt;
As a project, Horizon adheres to code quality standards.  The following standards are divided into required and recommended sections.  Our main goal in establishing these best practices is to have code that is reliable, readable, and maintainable.&lt;br /&gt;
&lt;br /&gt;
=== JavaScript ===&lt;br /&gt;
==== Required: ====&lt;br /&gt;
Before committing your code, please review the following checklists: 'Reliable' and 'Readable and Maintainable'. Though we all have our preferences, these are the most commonly accepted guidelines. &lt;br /&gt;
&lt;br /&gt;
'''Reliable'''  -&lt;br /&gt;
&lt;br /&gt;
*  ''Use '===' as opposed to '==' for equality checks''.  The '==' will do a type cast before comparing, which can lead to unwanted results.   &lt;br /&gt;
&lt;br /&gt;
* ''Keep document reflows to a minimum''.  DOM manipulation is expensive, and can become a performance issue.  If you are accessing the DOM, make sure that you are doing it in the most optimized way.  One example is to build up a document fragment and then append the fragment to the DOM in one pass instead of doing multiple smaller DOM updates.&lt;br /&gt;
&lt;br /&gt;
* ''Use “strict”, enclosing each JavaScript file inside a self-executing function.  The self-executing function keeps the strict scoped to the file, so its variables and methods are not exposed to other JavaScript files in the product.  Note: Using strict will throw exceptions for common coding errors, like accessing global vars, that normally are not flagged.&lt;br /&gt;
   Example: (function(){&lt;br /&gt;
               'use strict'; &lt;br /&gt;
                // code...&lt;br /&gt;
             })();&lt;br /&gt;
&lt;br /&gt;
* ''Use for each when looping whenever possible''.   AngularJS, and jQuery both provide for each loops that provide both iteration and scope.&lt;br /&gt;
   AngularJS:&lt;br /&gt;
     angular.forEach(objectToIterateOver, function(value, key) {&lt;br /&gt;
         // loop logic&lt;br /&gt;
     });&lt;br /&gt;
 &lt;br /&gt;
   jQuery:&lt;br /&gt;
     $.each(objectToIterateOver, function( key, value ) {&lt;br /&gt;
        // loop logic&lt;br /&gt;
     });&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
* ''Do not put variables or functions in the global namespace''.   There are several reasons why globals are bad, one being that all JavaScript included in an application runs in the same scope.  The issue with that is if another script has the same method or variable names they overwrite each other.&lt;br /&gt;
&lt;br /&gt;
* ''Always put var in front of your variables''.  Not putting var in front of a variable puts that variable into the global space, see above.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use eval( )''.  The eval (expression) evaluates the expression passed to it.    This can open up your code to security vulnerabilities and other issues.&lt;br /&gt;
&lt;br /&gt;
* ''Do not use 'with object {code}'''.   The with statement is used to access properties of an object.   The issue with 'with' is that its execution is not consistent, so by reading the statement in the code it is not always clear how it is being used.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Give meaningful names to methods and variables''&lt;br /&gt;
&lt;br /&gt;
* ''Avoid excessive nesting''.&lt;br /&gt;
&lt;br /&gt;
* ''Avoid HTML and CSS in JS code''.   HTML and CSS belong in templates and stylesheets respectively.  For example:&lt;br /&gt;
   1. In our HTML file, we should focus on layout.&lt;br /&gt;
      i. Reduce the small/random &amp;lt;script&amp;gt; and &amp;lt;style&amp;gt; elements in HTML.&lt;br /&gt;
      ii. Avoid in-lining styles into element in HTML. Use attributes and classes instead&lt;br /&gt;
   2. In our JS files, we should focus on logic rather than attempting to manipulate/style elements. &lt;br /&gt;
      i. Something like element.css({property1,property2...}) belongs in a CSS class.&lt;br /&gt;
      ii. Something like &amp;lt;nowiki&amp;gt;$(&amp;quot;&amp;lt;div&amp;gt;&amp;lt;span&amp;gt;abc&amp;lt;/span&amp;gt;&amp;lt;/div&amp;gt;&amp;quot;)&amp;lt;/nowiki&amp;gt; belongs in a HTML template file. Use show/hide/clone elements if dynamic&lt;br /&gt;
          content is required.&lt;br /&gt;
      iii. Avoid using classes for detection purposes only, instead, defer to attributes.  For example to find a div: &lt;br /&gt;
          &amp;lt;nowiki&amp;gt;&amp;lt;div class=&amp;quot;something&amp;quot;&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
          $(&amp;quot;.something&amp;quot;).html(&amp;quot;Don't find me this way!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
           &lt;br /&gt;
          Is better found like: &lt;br /&gt;
            &amp;lt;nowiki&amp;gt;&amp;lt;div data-something&amp;gt;&amp;lt;/div&amp;gt; &lt;br /&gt;
            $(&amp;quot;div[data-something]&amp;quot;).html(&amp;quot;You found me correctly!&amp;quot;);&amp;lt;/nowiki&amp;gt;&lt;br /&gt;
&lt;br /&gt;
* ''Avoid commented-out code''. &lt;br /&gt;
    &lt;br /&gt;
* ''Avoid dead code''.&lt;br /&gt;
   &lt;br /&gt;
&lt;br /&gt;
'''JSHint'''&lt;br /&gt;
&lt;br /&gt;
''JSHint'' is a great tool to be used during your code editing to improve JavaScript quality by checking your code against a configurable list of checks.  Therefore, JavaScript developers should configure their editors to use JSHint to warn them of any such errors so they can be addressed.  Since JSHint has a ton of configuration options to choose from, here are the [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|options]] Horizon wants enforced.  Here are  [[Horizon/Javascript/EditorConfig|instructions]] for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm.&lt;br /&gt;
&lt;br /&gt;
JSHint configuration file:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig/Settings#.jshintrc|.jshintrc]]&lt;br /&gt;
&lt;br /&gt;
Instructions for setting up JSHint:&lt;br /&gt;
 [[Horizon/Javascript/EditorConfig|JSHint setup instructions]]&lt;br /&gt;
&lt;br /&gt;
Note:  JSHint is part of the automated unit tests performed by Jenkins.   The automated test uses the default configurations, which are less strict than the configurations we are recommending to run in your local development environment.&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
'''Readable &amp;amp; Maintainable'''&lt;br /&gt;
&lt;br /&gt;
* ''Put a comment at the top of every file'' explaining what the purpose of this file is when the naming is not obvious.  This guideline also applies to methods and variables. &lt;br /&gt;
&lt;br /&gt;
* '''Source-code formatting''' – (or “beautification”) is recommend but should be used with caution. Keep in mind that if you reformat an entire file that was not previously formatted the same way, it will mess up the diff during the code review.  It is best to use a formatter when you are working on a new file by yourself, or with others who are using the same formatter.  You can also choose to format a selected portion of a file only.   Instructions for setting up JSHint for Eclipse, Sublime Text, Notepad++ and WebStorm/PyCharm are [[Horizon/Javascript/EditorConfig|provided]].&lt;br /&gt;
&lt;br /&gt;
* '''Use { }''' for if, for, while statements, and don't combine them on one line for code maintainability / readability.&lt;br /&gt;
&lt;br /&gt;
 // Do this          //Not this          // Not this&lt;br /&gt;
 if(x) {             if(x)               if(x) y =x;&lt;br /&gt;
    y=x;                y=x;                          &lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
=== AngularJS ===&lt;br /&gt;
&lt;br /&gt;
==== Required: ====&lt;br /&gt;
* Organization:  Define your angular app under the root angular folder (such horizon/static/horizon/js/angular/hz.table.js). If your application is small enough you can choose to lump your Controllers, Directives, Filters,  etc.. all in the one file.  But if you find your file is growing too large and readability is becoming an issue, consider moving functionality into their own files under sub folders as described [[Horizon/Javascript#Recommended:_2|below]].&lt;br /&gt;
&lt;br /&gt;
* Separate presentation and business logic.  Controllers are for business logic, and directives for presentation.&lt;br /&gt;
   &lt;br /&gt;
# Controllers and Services should not contain DOM references. Directives should.&lt;br /&gt;
# Services are singletons and contain logic independent of view&lt;br /&gt;
&lt;br /&gt;
* Scope is not the model (model is your JavaScript Objects), the scope references the model.&lt;br /&gt;
# Read-only in templates, &lt;br /&gt;
# Write-only in controllers&lt;br /&gt;
&lt;br /&gt;
* Since Django already uses {{ }}, use {$ $} instead or {% verbatim %}&lt;br /&gt;
&lt;br /&gt;
* For localization of AngularJS templates in Horizon, there are a couple of ways to do it.&lt;br /&gt;
&lt;br /&gt;
# Using gettext or ngettext function that is pass from server to client. However, this depends on the catalog object that is also pass from server to client. If you're only translating a few things, this methodology is ok to use. &lt;br /&gt;
# Use an angular directive that will fetch a django template instead of a static HTML file. The advantage here is that you can now use {% trans %} and anything else Django has to offer. You can also cache the page according to the locale if you know that the content is static.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==== Recommended: ====&lt;br /&gt;
&lt;br /&gt;
* Use these directories: filters, directives, controllers, and templates. Note: When you use the directory name, the file name does not have to include words like &amp;quot;directive&amp;quot; or &amp;quot;filter&amp;quot;.&lt;br /&gt;
&lt;br /&gt;
* Put &amp;quot;Ctrl&amp;quot; on the end of a controller file name&lt;br /&gt;
&lt;br /&gt;
* Don't use variables like &amp;quot;app&amp;quot; that are at the highest level in the file, when Angular gives an alternative.  For example use function chaining:&lt;br /&gt;
   angular.module('my_module').controller('my_controller', ['$scope', function($scope) {&lt;br /&gt;
      // controller code&lt;br /&gt;
   }]).service('my_service', ['$scope', function($scope) {&lt;br /&gt;
     // service code&lt;br /&gt;
   }]);&lt;/div&gt;</summary>
		<author><name>Aaron Sahlin</name></author>	</entry>

	</feed>