Initial Stakeholders: @Rishiraj Shukla (Unlicensed) @Anup Kumar (Unlicensed)

GENERAL

Consider limiting files to 400 lines of code.
Break down the application into small reusable components. Make sure you do not have the same code copied into different places in the codebase. Extract the repeating code and use it in place of the repeated code. Follow DRY (Do Not Repeat Yourself) Coding Practice
Use a standard naming convention, Names of variables/files/functions should clearly convey their intent.
Refer General Naming Guidelines.
Use ES6 Features.
Every Function should have a description on top clearly stating the purpose. It will help the new developer involved in a project to understand its logic and readability.
Remove all console statement’s, unused imports and commented line of codes before merging into stable branch, If you feel this may be required in future add tags - @FutureScope
Try Defining small functions and limit them to no more than 75 lines.
Avoid writing the logic in templates
Use Single Responsibility Principle - Every module, class, or function should have responsibility over a single part of the functionality provided by the software.

LOOPS

When using ngFor to loop an array in templates, use it with a trackBy function which will return a unique identifier for each item.

Variables

When declaring the variables, use const when the value is not going to be reassigned.
Declare variables or constants with proper types other than any. @Varun Mittal (Unlicensed)

RXJS

Use pipeable operators when using RxJs operators. Pipeable operators are tree-shakable meaning only the code we need to execute will be included when they are imported. This also makes it easy to identify unused operators in the file.
Avoid subscribing to observables from components and instead subscribe to the observables from the template using async pipe.
In situations when you need to consume data from multiple observable streams try to avoid nested subscriptions, we should instead use chain able methods like switchMap, forkJoin , etc. @Varun Mittal (Unlicensed)
When subscribing to observables, always make sure you unsubscribe from them appropriately by using operators like take, takeUntil, etc.

Using takeUntil when you want to listen to the changes until another observable emits a value:

private _destroyed$ = new Subject();

public ngOnInit (): void {
    iAmAnObservable
    .pipe(
       map(value => value.item)
      // We want to listen to iAmAnObservable until the component is destroyed,
       takeUntil(this._destroyed$)
     )
    .subscribe(item => this.textToDisplay = item);
}

public ngOnDestroy (): void {
    this._destroyed$.next();
    this._destroyed$.complete();
}

Using a private subject like this is a pattern to manage unsubscribing many observables in the component.

Using take when you want only the first value emitted by the observable:

iAmAnObservable
    .pipe(
       map(value => value.item),
       take(1),
       takeUntil(this._destroyed$)
    )
    .subscribe(item => this.textToDisplay = item);

Note the usage of takeUntil with take here. This is to avoid memory leaks caused when the subscription hasn’t received a value before the component got destroyed. Without takeUntil here, the subscription would still hang around until it gets the first value, but since the component has already gotten destroyed, it will never get a value — leading to a memory leak.

COMPONENTS

Not all APIs are bulletproof, sometimes we need to add some logic in the code to make up for bugs in the APIs. Instead of having the hacks in components where they are needed, it is better to isolate them in one place, like in service, and use the service from the component. This helps keep the hacks “closer to the API”, so as to close to where the network request is made as possible. This way, less of your code is dealing with the un-hacked code. Also, it is one place where all the hacks live and it is easier to find them. When fixing the bugs in the APIs, it is easier to look for them in one file rather than looking for the hacks that could be spread across the codebase.
You can also create custom tags like API_FIX similar to TODO and tag the fixes with it so it is easier to find.

MODULES

When possible, try to lazy load the modules in your Angular application. Lazy loading is when you load something only when it is used, for example, loading a component only when it is to be seen.

Software Development