AngularJS has grown in popularity over the years. There are a huge number of blogs,videos and tutorials all over the web that delve into finer topics on AngularJS. Here is a list of AngularJS Best Practices and Notes as mentioned on AngularJS Developer Guide

1. Custom directives to access the DOM: In Angular, the only place where an application should access the DOM is within directives. This is important because artifacts that access the DOM are hard to test. If you need to access the DOM directly you should write a custom directive for this. The
   directives guide explains how to do this.
2. AngularJS folks have used an inline injection annotation to explicitly specify the dependency of the Controller on the $scope service provided by Angular. See the guide on
   Dependency Injection for more information.
3. Note: Like other core Angular identifiers, built-in services always start with $ (e.g. $http).
4. Note: Angular uses
   constructor injection.
5. What does it mean to “compile” an HTML template? For AngularJS, “compilation” means attaching event listeners to the HTML to make it interactive. The reason we use the term “compile” is that the recursive process of attaching directives mirrors the process of compiling source code in
   compiled programming languages.

6. Best Practice: Prefer using the dash-delimited format (e.g. ng-bind for ngBind). If you want to use an HTML validating tool, you can instead use the data-prefixed version (e.g.
   data-ng-bind for ngBind). The other forms are accepted for legacy reasons but we advise you to avoid them.

7. Best Practice: 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.

8. Best Practice: Comment directives were commonly used in places where the DOM API limits the ability to create directives that spanned multiple elements (e.g. inside <table> elements). AngularJS 1.2 introduces ng-repeat-start and ng-repeat-end as a better solution to this problem. Developers are encouraged to use this over custom comment directives when possible.

9. Best Practice: Prefer using the definition object over returning a function.

10. Best Practice: In order to avoid collisions with some future standard, it’s best to prefix your own directive names. For instance, if you created a <carousel> directive, it would be problematic if HTML7 introduced the same element. A two or three letter prefix (e.g. btfCarousel) works well. Similarly, do not prefix your own directives with ng or they might conflict with directives included in a future version of Angular.

11. Best Practice: Unless your template is very small, it’s typically better to break it apart into its own HTML file and load it with the templateUrl option.

12. When should I use an attribute versus an element? Use an element when you are creating a component that is in control of the template. The common case for this is when you are creating a Domain-Specific Language for parts of your template. Use an attribute when you are decorating an existing element with new functionality.

13. Best Practice: Use the scope option to create isolate scopes when making components that you want to reuse throughout your app.

14. Best Practice: Directives should clean up after themselves. You can use
    element.on('$destroy', ...) or scope.$on('$destroy', ...) to run a clean-up function when the directive is removed.

15. Best Practice: only use transclude: true when you want to create a directive that wraps arbitrary content.

16. Best Practice: use &attr in the scope option when you want your directive to expose an API for binding to behaviors.

17. Best Practice: use controller when you want to expose an API to other directives. Otherwise use link.
18. When bootstrapping, first Angular applies all constant definitions. Then Angular applies configuration blocks in the same order they were registered.
19. Best Practice: Any operation which can be shared among the instance of directives should be moved to the compile function for performance reasons.
20. Best Practice: name the factory functions as <serviceId>Factory (e.g., apiTokenFactory). While this naming convention is not required, it helps when navigating the codebase or looking at stack traces in the debugger.

21. Underscore notation: The use of the underscore notation (e.g.: _$rootScope_) is a convention wide spread in AngularJS community to keep the variable names clean in your tests. That’s why the
    $injector strips out the leading and the trailing underscores when matching the parameters. The underscore rule applies only if the name starts and ends with exactly one underscore, otherwise no replacing happens.

22. Best Practice: If your app will be used only in one locale, it is fine to rely on the default currency symbol. If you anticipate that viewers in other locales might use your app, you should explicitly provide a currency symbol.

23. Angular Prefixes $ and $$: To prevent accidental name collisions with your code, Angular prefixes names of public objects with $ and names of private objects with $$. Please do not use the $ or $$ prefix in your code.