AngularJS is what HTML would have been, had it been designed for building web-apps. Declarative templates with data-binding, MVW, MVVM, MVC, extensibility, use of controllers, directives, and other reusable components has made it the must-have tool for every web developer out there.
As beautiful as it sounds, one must be aware that, such a great tool can be abused by developers who blindly write code without peering into the future to determine the potential implications of their code changes or patterns used. That is why I chose to briefly discuss about some of the best practises that lead to the development of efficient AngularJS apps.
From my experience, I have found this John Papa Style Guide, to be an invaluable document, which should be read a couple of times to fully ingest the principles exposed and their potential benefits.
A simple principle recommended by the guide regarding Naming, suggests that we should use consistent names for all components following a pattern that describes the component’s feature then (optionally) its type. This would look like this: feature.type.js. An example of recommended names can be:
orders.controller.js orders.module.js orders.routes.js orders.config.js order-list.directive.js
Another principle suggested is the LIFT principle. It stands for:
L: Locating our code is easy I: Identify code at a glance F: Flat strucure as long as we can T: Try to stay DRY (Don't Repeat Yourself) or T-DRY
The LIFT principle encourages developers to arrange projects in a way where files can easily be located for future updates, using intuitive locations, storing files that are related next to each other. It also suggests that developers refactor their codebase to ensure that potential reusable components are created to replace repetitive codes. Following such a guide would serve as a check and balance tool for every developer who wishes to speed up his continous delivery rate.
It is highly important that new developers pick up the guide and read it in and out. This would save the project tons of technical debt that could have been introduced if the guide wasn’t followed.