An opinion about Coding Style for Angular

An opinion about Coding Style for Angular

Coding Style is an important rule that any development team should define and provide to unify for everyone in the team to follow so that the code is written in a standard way, easier to maintain and use. again, ... If you have professionally coded, you will know very well how important coding style is for many people and many developers

An opinion about Coding Style for Angular

Coding Style is an important rule that any development team should define and provide to unify for everyone in the team to follow so that the code is written in a standard way, easier to maintain and use. again, ... If you have professionally coded, you will know very well how important coding style is for many people and many developers. Countless hours of my career have been devoted to debating coding styles .

Consensus is important before writing the first line of code in the project, but this should not be fixed throughout the project life cycle. It is a continuous set of lessons that stem from my testing and experience.

That doesn't mean you should change your mind every day, but you should evaluate, discuss and decide with your team as your project develops.

After writing Angular apps since the beginning, I have developed my coding style , influenced by the people I work with, read a lot of code or simply from my test projects.

In this article, I want to show my style for my Angular applications so that the code looks more aesthetically pleasing, easy to read, maintain, reuse and the reason behind my decisions. Hopefully, it will inspire you and your team to apply some or to make your own.

Any suggestions from you will always be extremely welcome on how to improve it!

HTML Wrapping

Angular templates have quite a bit of additional syntax besides regular HTML syntax and are sometimes relatively difficult to read.

And my first suggestion concerns wrapping. I usually leave no more than 80 characters per column for all files, to make it much simpler and more readable than putting too many characters on one line.

This is an elemant written without any convention :

Everything looked messy. Almost every project I work while consulting is written in the same way. We will rewrite the excerpt above using a simple set of rules to make it more readable.

Define rules for writing HTML tags

  • When an element has two or more properties, normally I only write one attribute per line.
  • Attributes must be written in a particular order
  • Unless a single attribute is used, the closing tag must be written on the next line

I suggest defining a specific order as follows:

  1. Structural directives
  2. Animations
  3. Static properties
  4. Dynamic properties
  5. Events

Let's take a look at a personal example of how I write according to the above rule: 

Even better, I've always used these structural directivesreserved for ng-container

Although I think you can mix up the order of attributes based on subjective perspectives, I feel quite strongly about displaying structural directives before anything else.

One structural directiveslet me know (before I need to know anything else):

  • Is this elemant being displayed? And why?
  • Is this elemant being repeated?

In my opinion, this can facilitate the reading and understanding of your structure templates.


PipesVery powerful: they can transform values ​​in templates and avoid duplication / logic in our components. They can be reused and mixed easily, and are easy to write.

But are they easy to read and detect? Yes and no

This is very subjective and a small point but I still think it might be worth sharing. Whenever I see a pipe in my template, I tend to wrap it in parentheses ("()"). The sense of division provided by parentheses gives me a clue that the value is being converted and is generally easier to see: 

When using multiple pipes, it may be even more important: 

Lifecycle Hooks


Adding interfaces with lifecycle hooks is optional but based on experience, I recommend that you follow.


When I search for lifecycle hooksclasses, I often look to constructors and expect them to see them all together and not mix with other class methods. Ideally, they should be identified in the same order they were performed.

And what I recommend is:

  • Always add interfaces
  • Add public and private properties above the constructor
  • Add methods right below the constructor and on component methods
  • Add them all together
  • Add them in the order they are executed. Admittedly, though, it's a bit difficult to track consistently, so I guess it's one of the least important.


I often avoid writing any logic directly in lifecycle hooks, my suggestion is to encapsulate logic in private methods and call them in lifecycle hooks: 

Methods and properties of components

Angular uses decorators for methods and properties of components to enhance its functionality.

There are many of them defining a specific order to follow would be overwhelming, but the important thing I try to follow is to locate the properties and methods with the same decoratorsproximity.

The following is what I would consider as a bad example: 

And here is how I will write it. Also, notice there is a blank line in the middle of the attribute group with the same decorator - I think it makes it easy to read: 

I have no strong opinion on this, but try to define private and public component properties that are not marked with any separate decorator with attributes decorator. In my experience, mixing them up only leads to confusion and chaos.


I know naming things is relatively difficult.

When it comes to naming, I always have to think twice or more to come up with a name that's easy to understand, vague and easy to find:

  • Understand: what does this do, in a flash?
  • Not clear: for example, if we have multiple click events on a component, which one does it refer to? So yes, naming it on Click is not the way to go
  • Easy to find: I find the naming code to be a bit like SEO: my users (teammates or me) will be looking for something special - and how can I write code to ensure they can find it? easier?

Route Components

I tend to name Component Routes with a suffix page.

For example, authentication page is often called auth-page.component.ts- tell me it is a routed component and I often use it to wrap and display other components through router-outlet.

Some of the rules I tend to follow when naming components are:

  • Try to use no more than 3 words (excluding prefixes). There is no specific reason why. Of course, sometimes, it is simply not easy to respect this rule.
  • Try to avoid repeating words or contexts that have been used with other components, as it will slow down while using my IDE's search function and also result in the wrong opening of other files, which is last. waste time and source of frustration.
  • At the same time, try not to be too general. For example, if we call a component installation - what is an installation? Help a little bit here and provide some extra context (for example, installing apps, setting up profiles, organizing settings, etc.).

ES Imports

Keeping your file imports organized and tidy is a challenge, especially when using the IDE to automatically add them as you import. As your files grow, they tend to be quite messy.

Here is how I am going to arrange my import:

  1. Angular imports are always on top.
  2. Rx imports.
  3. Third party (not core).
  4. Local / Project imports are always at the bottom.

It is also a good practice to leave comments on each group: 

angular angularjs javascript

What's new in Bootstrap 5 and when Bootstrap 5 release date?

How to Build Progressive Web Apps (PWA) using Angular 9

What is new features in Javascript ES2020 ECMAScript 2020

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Random Password Generator Online

HTML Color Picker online | HEX Color Picker | RGB Color Picker

Migrating from AngularJS to Angular

Migrating from AngularJS to Angular a hybrid system architecture running both AngularJS and Angular

What is the difference between JavaScript and AngularJS?

JavaScript is a client-side programming language used for creating dynamic websites and apps to run in the client's browser whereas AngularJS is a fully featured web app framework established on JavaScript and managed by Google.

What’s the difference between AngularJS and Angular?

Angular vs Angularjs - key differences, performance, and popularity

The essential JavaScript concepts that you should understand

The essential JavaScript concepts that you should understand - For successful developing and to pass a work interview

Build an App with Angular and the Angular CLI

In this tutorial, we’re going to look at managing user authentication in the MEAN stack. We’ll use the most common MEAN architecture of having an Angular single-page app using a REST API built with Node, Express and MongoDB