...

• If you find yourself manipulating DOM in a controller, STOP!!! DOM manipulation should really only be done in Directives and possibly in Filters.
• Keep Filters lean and mean. They get executed many times and can become a performance issue.
• Use angular-supplied versions of common javascript/jquery methods/objects
  • $timeout instead of setTimeout
  • $window instead of window
  • $document instead of document
  • $http instead of $.ajax, or better yet use $resource
• Get to know the Angular API, don't rely on jQuery
  • angular.copy
  • angular.element
  • angular.equals
  • angular.extend
  • angular.forEach
  • angular.fromJson
  • angular.identity
  • angular.isArray
  • angular.isDate
  • angular.isDefined
  • angular.isElement
  • angular.isFunction
  • angular.isNumber
  • angular.isObject
  • angular.isString
  • angular.isUndefined
  • angular.lowercase
  • angular.noop
  • angular.toJson
  • angular.uppercase

• App Structure

  Stick to the one file equals one AngularJS module principle. This will allow you to maintain relatively small, focused files and modules. Additionally you won't be concerned with the load order of those files. Also it will be possible to load individual modules under unit tests

  General

  • AngularJS is not suited for applications with a strong graphical component: ones that do many different heavy DOM modifications or games.
  • Do not attempt to write a general-purpose JavaScript library in AngularJS; it's meant for writing applications, not libraries. You can write modules to be reused by other AngularJS applications, but anything intended to be standalone or used with another library is not a good candidate.

• App Structure

  • Stick to the one file equals one AngularJS module principle. This will allow you to maintain relatively small, focused files and modules. Additionally you won't be concerned with the load order of those files. Also it will be possible to load individual modules under unit tests.

• Scopes

  • The $rootScope object is the closest object we have to the global context in an angular app. It's a bad idea to attach too much logic to this global context, just like it's not a good idea to dirty the javascript global scope.
  • A model refers to a traditional JavaScript object {} where transient state should be stored. Persistent state should be bound to a service, which is then responsible for dealing with persisting that model.

• Data Binding

  • Due to the nature of javascript itself and how it passes by value vs. reference, it's considered a best- practice in Angular to bind references in the views by an attribute on an object, rather than the raw object itself.

...

• Controllers

  • Create variables inside the controller to be explicit.
  • It is considered a best-practice to name our controllers NameCtrl in camelcase.
  • Keep controllers slim by using the dependency injection feature of AngularJS to access services.
  • Controllers should not own the domain model. If something is needed by two controllers then make it available via a service.

• Dependency Injection

  • Implicit dependency injection works fine until you minimize your code and then it falls apart. For production use, it is recommended to explicitly annotate injections with $inject.

• Spreading route definitions among several modules

...

• Directives

  • While declaring an AngularJS directive, the naming convention followed is camelCase. For example, we would define the name of the directive as 'myDatePicker'. But when you actually use the directive in your HTML, it is the dash-separated version (my-date-picker).
  • To make your directives and attributes HTML5 compliant, you can prefix all AngularJS attributes with "data-" or "x-". That is, "x-ng-show" or "data-date-picker", and AngularJS will treat it just like you wrote it like a normal HTML element.

Plugging-In

...