ERAS FrontEnd ‐ Coding Styles - JU-DEV-Bootcamps/ERAS GitHub Wiki

Table of Contents

Description

Use this standards to keep quality, consistency, maintainability, reduce technical debt, improve readability, understanding and for sure ensuring our software quality.

TypeScript coding style guide

Naming Conventions

1. Use lower camel case for:

  • variables
  • method names
  • methods parameters
  • classes atributes
  • enums atributes

Bad

let PageSize;

function RemoveRow() {}

Good:

let pageSize;

function removeRow() {}

Why? Improves code readability and consistency.
Why? Avoids errors, confusions with reserved names and/or named class conventions.
Why? Straight forward to read and understand at a glance.

1. Use upper camel case (Pascal Case) on classes, interfaces, enums.

Bad

class userLogin {}

interface user {}

enum Statususer {}

Good:

class UserLogin {}

interface User {}

enum StatusUser {}

Why? Improves code readability and consistency among classes, interfaces, etc.
Why? Distinguishs from variables, properties, methods and methods' parameters.
Why? Straight forward to read and understand at a glance.

⬆️ Back to Top

Naming

Clarity is king!!!

1. Use meaningful variable names.
The name of a variable, function, or class, should be self explanatory.

Bad

function isBetween(a1, a2, a3) {
    return a2 <= a1 && a1 <= a3;
}

Good

function isBetween(value:number, left:number, right:number):boolean {
    return left <= value && value <= right;
}

Why? Avoid to depend on documentation or comments.
Why? Straight forward to read and understand at a glance.

2. Use pronounceable variable names

Bad

class Subs {
    public ccId: number;
    public billAddrId: number;
    public shipAddrId: number;
}

Good:

class Subscription {
    public creditCardId: number;
    public billingAddressId: number;
    public shippinAddressId: number;
}

Why? When you need to discuss it you need to be clear, otherwise it sounds weird.
Why? Straight forward to read and understand at a glance.

3. Avoid mental mapping

Explicit is better than implicit.

Bad

const u = getUser();
const s = getSubscription();
const t = charge(u, s);

Good:

const user = getUser();
const subscription = getSubscription();
const transaction = charge(user, subscription);

Why? Straight forward to read and understand at a glance.

4. Do not add unneeded context

If your class, type or object name tells you something, do not repeat it at your variable name.

Bad

type Car = {
    carMake: string;
    carModel: string;
    carColor: string;
}

function print(car: Car): void {
    console.log(`${car.carMake} ${car.carModel} (${car.carColor})`);
}

Good:

type Car = {
    make: string;
    model: string;
    color: string;
}

function print(car: Car): void {
    console.log(`${car.make} ${car.model} (${car.color})`);
}

Why? Straight forward to read and understand at a glance.

⬆️ Back to Top

Naming Booleans

1. Do NOT use negative names for boolean variables.

Bad

const isNotEnabled = true;

if ( !isNotEnabled ) {}

Good:

const isEnabled = true;

if ( !isEnabled ) {}

Why? Makes code harder to read and understand.
Why? Can leads to introduce of double negatives values.
Why? Straight forward to read and understand at a glance.

1. Add prefixes like "is", "are", or "has".

Bad

const enabled = true;

Good:

const isEnabled = false;

Why? Helps to distinguish a boolean from another variables at a glance.

⬆️ Back to Top

Angular coding style guide

Organize imports

Make sure you apply and follow good practices for import statements:

  • Unused imports should be removed.
  • Add an space before and after the reference name of the item imported.
  • Groups of imports are delineated by one blank line before and after.
  • Groups must respect the following order:
    • Angular own libraries (i.e. '@angular/**')
    • Rxjs libraries (i.e 'rxjs', 'rxjs/**')
    • Imports should be sorted by type
      • modules
      • services
      • classes
      • interfaces
      • enums
      • and at the end components
    • If you have a bounch group of elements you should order alphabetically.

Bad

import {NgModule} from '@angular/core';
import {MatSelectChange } from '@angular/material/select';
import { merge, Observable, BehaviorSubject } from 'rxjs';
import { filter,tap } from 'rxjs/operators';
import {INumberToTypeDictionary, Utils} from '@shared/classes';
import { ProductUtils } from '@modules/services/products/classes';
import {HttpClient} from '@angular/common/http';

Good:

import { HttpClient } from '@angular/common/http';
import { MatSelectChange } from '@angular/material/select';
import { NgModule } from '@angular/core';

import { BehaviorSubject, merge, Observable } from 'rxjs';
import { filter, tap } from 'rxjs/operators';

import { INumberToTypeDictionary, Utils } from '@shared/classes';
import { ProductUtils } from '@modules/services/products/classes';

import { HomeComponent } from './home/home.component';
import { LandingPageComponent } from './landing-page/landing-page.component';

Why? Helps us to keep a clean and easy import statements.
Why? Helps us to quickly see code's dependencies.

Use aliases

Make sure to use absolute paths instead of relative paths. Our project has the ability to handle path aliases.

Bad:

@use '../../../../styles/utils/index.scss' as main-styles;

import { ModalComponent } from '../../../../shared/components/modal/modal.component';

import { ConfigurationsService } from '../../../../core/services/configurations.service';

import { getEvalClass } from '../../../modules/lists/utils/evaluations.util';

Good

@use 'index.scss' as main-styles;

import { ModalComponent } from '@shared/components/modal/modal.component';

import { ConfigurationsService } from '@core/services/configurations.service';

import { getEvalClass } from '@modules/lists/utils/evaluations.util';

Why? Makes import statements cleaner and easier to understand. Why? Improves maintainability and refactoring.

⬆️ Back to Top

Git project management system

Link pull requests to tickets

Start linking our pull request to user stories, enhancements, or issues

LinkPullRequest

Why? Helps us to improve code reviews.
Why? Helps us to have traceability and context of worked items .

⬆️ Back to Top