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!
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.
I suggest defining a specific order as follows:
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
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.
structural directiveslet me know (before I need to know anything else):
In my opinion, this can facilitate the reading and understanding of your structure
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:
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:
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:
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
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:
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
Some of the rules I tend to follow when naming components are:
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:
It is also a good practice to leave comments on each group:
Migrating from AngularJS to Angular a hybrid system architecture running both AngularJS and Angular
Angular vs Angularjs - key differences, performance, and popularity
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