Request a Call Back
Fields marked with an * are required
Angular Guidelines: You Should Check Before Start - Habilelabs

Angular Guidelines before start coding:

You should know angular guidelines, If you are planning to start coding with angular (2/4). I will talk about the Angular guidelines we follow at habilelabs.

Let’s start with file naming.

1. File Naming conventions

1. Separate file names with dots and dashes
Eg. hero.component.ts, hero.component.html, tree-structure.directive.js

2. Create files in groups as per requirement

2. Single Responsibility

Define 1 component per file, recommended being less than 400 lines of code
– Why?: One component per file promotes easier unit testing and mocking.
– Why?: One component per file makes it far easier to read, maintain, and avoid collisions with teams in source control.
– Why?: One component per file avoids hidden bugs that often arise when combining components in a file where they may share variables, create unwanted closures, or unwanted coupling with dependencies.

3. Small Functions

Define small functions, no more than 75 Lines of Code (less is better)
– Why?: Small functions are easier to test, especially when they do one thing and serve one purpose.
– Why?: Small functions promote reuse.
– Why?: Small functions are easier to read.
– Why?: Small functions are easier to maintain.

4. Service names

– Do use consistent names for all services named after their feature.
– Do suffix a service class name with Service. For example, something that gets data or hero should be called a DataService or a HeroService.
– A few terms are unambiguously services. They typically indicate agency by ending in “-er”. You may prefer to name a service that logs messages Logger rather than LoggerService. Decide if this exception is agreeable in your project. As always, strive for consistency.
1) Why? Provides a consistent way to quickly identify and reference services.
2) Why? Clear service names such as Logger do not require a suffix.
3) Why? Service names such as Credit are nouns and require a suffix and should be named with a suffix when it is not obvious if it is a service or something else

5. Custom prefix for components

– Do use a hyphenated, lowercase element selector value (e.g. admin-users).
– Do use a custom prefix for a component selector. For example, the prefix to represents from Tour of Heroes and the prefix admin represents an admin feature area.
– Do use a prefix that identifies the feature area or the app itself.
1) Why? Prevents element name collisions with components in other apps and with native HTML elements.
2) Why? Makes it easier to promote and share the component in other apps.
3) Why? Components are easy to identify in the DOM

6. Angular Coding conventions


Do use upper camel case when naming classes.
– Why? Follows conventional thinking for class names.
– Why? Classes can be instantiated and construct an instance. By convention, upper camel case indicates a constructible asset.


Do declare variables with const if their values should not change during the application lifetime.
1) Why? Conveys to readers that the value is invariant.
2) Why? TypeScript helps enforce that intent by requiring immediate initialization and by preventing subsequent re-assignment.

Consider spelling const variables in lower camel case.
1) Why? Lower camel case variable names (heroRoutes) are easier to read and understand than the traditional UPPER_SNAKE_CASE names (HERO_ROUTES).
2) Why? The tradition of naming constants in UPPER_SNAKE_CASE reflects an era before the modern IDEs that quickly reveal the const declaration. TypeScript prevents accidental reassignment.

Do tolerate existing const variables that are spelled in UPPER_SNAKE_CASE.
– Why? The tradition of UPPER_SNAKE_CASE remains popular and pervasive, especially in third-party modules. It is rarely worth the effort to change them at the risk of breaking existing code and documentation.

7. Properties and methods

– Do use lower camel case to name properties and methods.
– Avoid prefixing private properties and methods with an underscore.

8. Import line spacing

– Consider leaving one empty line between third-party imports and application imports.
– Consider listing import lines alphabetized by the module.
– Consider listing destructured imported symbols alphabetically.
– Why? The empty line separates your stuff from their stuff.
– Why? Alphabetizing makes it easier to read and locate symbols

9. Folders-by-feature structure

– Do create folders named for the feature area they represent.
– Why? A developer can locate the code and identify what each file represents at a glance. The structure is as flat as it can be and there are no repetitive or redundant names.
– Why? The LIFT guidelines are all covered.
– Why? Helps reduce the app from becoming cluttered through organizing the content and keeping them aligned with the LIFT guidelines.
– Why? When there are a lot of files, for example, 10+, locating them is easier with a consistent folder structure and more difficult in a flat structure.
– Do create NgModule for each feature area.
– Why? NgModules make it easy to lazy load routable features.
– Why? NgModules make it easier to isolate, test, and reuse features.

10. Services

– Do use services as singletons within the same injector. Use them for sharing data and functionality.
– Why? Services are ideal for sharing methods across a feature area or an app.
– Why? Services are ideal for sharing stateful in-memory data.

– Do create services with a single responsibility that is encapsulated by its context.
– Do create a new service once the service begins to exceed that singular purpose.
– Why? When a service has multiple responsibilities, it becomes difficult to test.
– Why? When a service has multiple responsibilities, every component or service that injects it now carries the weight of them all.

Habilelabs provides Angular JS development services with the best quality and latest standard. Contact Us to discuss your project.

I covered most of the things in this article about “Angular Guidelines”. If you have anything to discuss then ask in the comment section.

Hope you enjoy this post, so don’t forget to share with friends.

Shankar is CTO and Software Architect at Habilelabs. He is passionate about JavaScript, Node.js, Angular.js, Meteorjs and cutting-edge front-end technologies. He also enjoys mathematics, he is constantly finding new ways to apply maths theory to web development for improving performance.