---
tags: Notes
---
<img src="https://bankaks.com/wp-content/uploads/2020/03/bankaks_logo_menu.png" width="20%"/>

# General Style and Coding Standards Template(Angular)

## 1. Introduction
### 1.1 Purpose
The primary goal of these guidelines is to inculcate uniform coding practices among the software and engineering professionals in the IT department of Bankaks, so that the reading, checking and maintaining the code for others becomes easier. The presented guidelines are not meant to burden the code authors with stringent practices, leaving them the freedom practice their craft without hurdles.

When a project adheres to common standards many good things happen:
* Programmers can go into any code and figure out what’s going on, so maintainability, readability, and reusability are increased. Code walk throughs become less painful.
* New people can get up to speed quickly.
* People new to a language are spared the need to develop a personal style and defend it to death.
* People new to a language are spared making the same mistakes over and over again, so reliability is increased.
* People make fewer mistakes in consistent environments.
* Idiosyncratic styles and college-learned behaviors are replaced with an emphasis on business concerns - high productivity, maintainability, shared authorship, etc.

### 1.2 Scope
> Angular 8 is a client-side TypeScript based framework which is used to create dynamic web applications. It is very similar to its previous versions except having some extensive features.
>

## 2. Project Dependent Standards
> Framework: Angular 8
> Code Editor: VS code
>

### 2.1 Naming Conventions
* Camel case for variables names
* Camel case for methods.

### 2.2 File Organization
1. All of the app's code goes in a folder named src.
2. All feature areas are in their own folder, with their own NgModule.
3. All content is one asset per file.
4. Each component, service, and pipe is in its own file.
5. All third party vendor scripts are stored in another folder and not in the src folder.

### 2.3 Development Environment Setup
* Download VS code from here: [Visual Studio Code](https://code.visualstudio.com/download)
* Download Node.js from here: [Node.js](https://nodejs.org/en/download/)
* After installing Node.js, Open Command prompt and run the following command:
> npm install -g @angular/cli

## 3. Style Guide and Coding Conventions

### 3.1 Naming a variable
* Camel case for variables names

| Field type | Field name | Example |
| -------- | -------- | -------- |
| Date | fieldNameDate | fromDate |
|Datetime |fieldNameDateT | startDateT |
| One-To-One / Many-To-One|objectName|partner|
|Many-To-Many| objectNameSet| partnerList|
|One-To-Many| objectNameList| partnerSet|
|Boolean| isFieldName| isInvoiced|

### 3.2 Function
* Camel case for methods.
* Define small functions, no more than 75 LOC (less is better).
* Small functions promote reuse.
* Small functions are easier to maintain.

### 3.3 Modules
* Do give the file name the .module.ts extension.
* One module – app.module.ts (main module).
* Multiple modules – admin.module.ts and app.ts
* Routing module – app-routing.module.ts

### 3.4 Components
* A component contains styling file, template(html), testing and typescript file:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a. dashboard.component.css
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b. dashboard.component.html
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c. dashboard.component.spec.ts
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d. dashboard.component.ts
* Name of the component should be Pascal Case : DashboardComponent

### 3.5 Services
* File name : name.service.ts
* Service Class name : NameService
* Shared : name.shared.ts

### 3.6 Component Selector
* Do use dashed-case or kebab-case for naming the element selectors of components.

## 4. Design Principles to Keep in Mind

1. Follow LIFT : Locate, Identify, Flat, T-DRY(Try to be DRY)

1.1. **Locate**
* Do make locating code intuitive, simple, and fast.
* Why? To work efficiently you must be able to find files quickly, especially when you do not know (or do not remember) the file names.
* Keeping related files near each other in an intuitive location saves time. A descriptive folder structure makes a world of difference to you and the people who come after you.

1.2. **Identify**
* Do name the file such that you instantly know what it contains and represents.
* Do be descriptive with file names and keep the contents of the file to exactly one component.
* Avoid files with multiple components, multiple services, or a mixture.
* Why? Spend less time hunting and pecking for code, and become more efficient. Longer file names are far better than short-but-obscure abbreviated names.

1.3. **Flat**
* Do keep a flat folder structure as long as possible.
* Consider creating sub-folders when a folder reaches seven or more files.
* Consider configuring the IDE to hide distracting, irrelevant files such as generated .js and .js.map files.
* Why? No one wants to search for a file through seven levels of folders. A flat structure is easy to scan.
* Base your decision on your comfort level. Use a flatter structure until there is an obvious value to creating a new folder.

1.4. **T-DRY (Try to be DRY)**
* Do be DRY (Don't Repeat Yourself).
* Avoid being so DRY that you sacrifice readability.
* Why? Being DRY is important, but not crucial if it sacrifices the other elements of LIFT. That's why it's called T-DRY.
* For example, it's redundant to name a template hero-view.component.html because with the .html extension, it is obviously a view. But if something is not obvious or departs from a convention, then spell it out.