Angular JS Best Practices

1. Create one directive per file
2. Create one controller per file
3. Create one service per file
4. Have only routes and general usablility code on app.js
5. Don’t ever user $rootScope, rather make use of Angular services
6. Prefer Restangular for complex API calls, $http for simple API calls, avoid $resource.
7. Don’t use {{ }} on view files, rather use either ng-bind (or) data-prefixed version
8. Use native for loops than angular.forEach
9. Only for a small storage purpose go for $cookieStore, for storing medium and large informations use $localStorage or $sessionStorage according to the need


UpperCamelCase for Controllers and constructor Services, lowerCamelCase everywhere else.


The naming of the controller is done using the controller’s functionality (for example shopping cart, homepage, admin panel) and the substring Ctrl in the end. The controllers are named UpperCamelCase (HomePageCtrl, ShoppingCartCtrl, AdminPanelCtrl, etc.).


Name your directives with lowerCamelCase.


Name your filters with lowerCamelCase.


Use camelCase to name your services.

  • UpperCamelCase (PascalCase) for naming your services, used as constructor functions
  • lowerCamelCase for all other services.

Note that Services always return singletons. Unless you create a special service to return a newed object each time it gets called–in this case, and only in this case should you use PascalCase naming.


├── index.html
├── scripts
   ├── controllers
      └── main.js
      └── ...
   ├── directives
      └── myDirective.js
      └── ...
   ├── filters
      └── myFilter.js
      └── ...
   ├── services
      └── myService.js
      └── ...
   ├── vendor
      ├── angular.js
      ├── angular.min.js
      ├── es5-shim.min.js
      └── json3.min.js
   └── app.js
├── styles
   └── ...
└── views
    ├── main.html
    └── ...



  • One should try and place the <script> tag including the angular.js and related angular scripts at the bottom of the page to improve the app load time. This is because the HTML loading would then not be blocked by loading of angular.js and related scripts.


  • Complex javascript code should be made as a method in the controller (added as a method to the $scope) and then, should be called from the view. This is unlike putting the complex Javascript code as Angular expressions, right, in the view.


  • With real applications, one should avoid creating controllers in the global scope. Rather, one should use “.controller” method of the Angular Module to work with $scope object. Take a look at the sample code below illustrating this point:

Controller defined in the Global Scope:

function HelloController( $scope ) { 
      $ = "Guest";
  • The controllers should only be used to setup initial state of the $scope object and add one or more behaviour to this object. One should avoid using controllers to do some of the following:
    • Manipulate DOM,
    • Format input,
    • Filter output,
    • Share code or state across different controllers
    • Manage the life-cycle of other components (for example, to create service instances)
  • A controller should contain only the business logic needed for a single view. The functionality should rather be moved to services and these services should be injected into the controllers using dependency injection.
  • The recommended way to declare the controller function is to use the array notation such as following because it protects against minification.

Controller defined using “.controller” method (Recommended way)

var helloApp = angular.module( "helloApp", [] ); 
helloApp.controller( "HelloController", function($scope){ 
$ = "Guest"; 


  • While writing unit tests for controllers, one of the recommended ways is to inject $rootScope & $controller. Take a look at the sample unit tests on this page: The following is the sample code representing injection of $rootScope and $controller objects.
    function( $rootScope, $controller ){ 
    scopeMock = $rootScope.$new(); 
    $controller( 'CompanyCtrl', {$scope: scopeMock} ); 


  • One should prefer using the dash-delimited format (e.g. ng-model for ngModel). While working with an HTML validating tool, one could instead use the data-prefixed version (e.g. data-ng-model for ngModel).
  • Prefer using directives via tag name and attributes over comment and class names. Doing so generally makes it easier to determine what directives a given element matches.
  • While creating directives, it is recommended to prefix your own directive names to avoid collisions with future standard.


  • With large templates (HTML content with Angular directives) within an HTML file, it is recommended to break it apart into its own HTML file and load it with the templateUrl option.

Dependency Injection

The preferred way of injecting the dependencies is by passing the dependency to the constructor function rather than using one of the following other ways. In this way, the responsibility of creating the dependency object lies with other objects or function. This is straight forward for those who have worked with one or more dependency injection framework in the past. However, this could be useful information for the beginners. Following are other ways of doing dependency injection in Angular:

  • Create it using the new operator.
  • Look for it in a well-known place, also known as a global singleton.
  • Ask a registry (also known as service registry) for it.

Also Refer :