Distinguish names in such a way that the reader knows what the differences offer.
**Bad:**
```ts
function between<T>(a1: T, a2: T, a3: T) {
return a2 <= a1 && a1 <= a3;
}
```
**Good:**
```ts
function between<T>(value: T, left: T, right: T) {
return left <= value && value <= right;
}
```
**[⬆ back to top](#table-of-contents)**
### Use pronounceable variable names
If you can’t pronounce it, you can’t discuss it without sounding like an idiot.
**Bad:**
```ts
class DtaRcrd102 {
private genymdhms: Date;
private modymdhms: Date;
private pszqint = '102';
}
```
**Good:**
```ts
class Customer {
private generationTimestamp: Date;
private modificationTimestamp: Date;
private recordId = '102';
}
```
### Use the same vocabulary for the same type of variable
**Bad:**
```ts
function getUserInfo(): User;
function getUserDetails(): User;
function getUserData(): User;
```
**Good:**
```ts
function getUser(): User;
```
**[⬆ back to top](#table-of-contents)**
### Use searchable names
We will read more code than we will ever write. It's important that the code we do write is readable and searchable. By not naming variables that end up being meaningful for understanding our program, we hurt our readers. Make your names searchable. Tools like [TSLint](https://palantir.github.io/tslint/rules/no-magic-numbers/) can help identify unnamed constants.
Using getters and setters to access data from objects that encapsulate behavior could be better that simply looking for a property on an object.
"Why?" you might ask. Well, here's a list of reasons:
* When you want to do more beyond getting an object property, you don't have to look up and change every accessor in your codebase.
* Makes adding validation simple when doing a set.
* Encapsulates the internal representation.
* Easy to add logging and error handling when getting and setting.
* You can lazy load your object's properties, let's say getting it from a server.
**Bad:**
```ts
class BankAccount {
balance: number = 0;
// ...
}
const value = 100;
const account = new BankAccount();
if (value <0){
throw new Error('Cannot set negative balance.');
}
account.balance = value;
```
**Good:**
```ts
class BankAccount {
private accountBalance: number = 0;
get balance(): number {
return this.accountBalance;
}
set balance(value: number) {
if (value <0){
throw new Error('Cannot set negative balance.');
}
this.accountBalance = value;
}
// ...
}
const account = new BankAccount();
account.balance = 100;
```
**[⬆ back to top](#table-of-contents)**
### Make objects have private/protected members
TypeScript supports `public`*(default)*, `protected` and `private` accessors on class members.
**Bad:**
```ts
class Circle {
radius: number;
constructor(radius: number) {
this.radius = radius;
}
perimeter(){
return 2 * Math.PI * this.radius;
}
surface(){
return Math.PI * this.radius * this.radius;
}
}
```
**Good:**
```ts
class Circle {
constructor(private readonly radius: number) {
}
perimeter(){
return 2 * Math.PI * this.radius;
}
surface(){
return Math.PI * this.radius * this.radius;
}
}
```
**[⬆ back to top](#table-of-contents)**
### Prefer readonly properties
TypeScript's type system allows you to mark individual properties on an interface / class as readonly. This allows you to work in a functional way (unexpected mutation is bad).
For more advanced scenarios there is a built-in type `Readonly` that takes a type `T` and marks all of its properties as readonly using mapped types (see [mapped types](https://www.typescriptlang.org/docs/handbook/advanced-types.html#mapped-types)).
Callbacks aren't clean, and they cause excessive amounts of nesting *(the callback hell)*.
There are utilities that transform existing functions using the callback style to a version that returns promises
(for Node.js see [`util.promisify`](https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original), for general purpose see [pify](https://www.npmjs.com/package/pify), [es6-promisify](https://www.npmjs.com/package/es6-promisify))
Promises supports a few patterns that could be useful in some cases:
|Pattern|Description|
|-------|-----------|
|`Promise.resolve(value)`|Convert a value into a resolved promise.|
|`Promise.reject(error)`|Convert an error into a rejected promise.|
|`Promise.all(promises)`|Returns a new promise which is fulfilled with an array of fulfillment values for the passed promises or rejects with the reason of the first promise that rejects.|
|`Promise.race(promises)`|Returns a new promise which is fulfilled/rejected with the result/error of the first settled promise from the array of passed promises.|
`Promise.all` is especially useful when there is a need to run tasks in parallel. `Promise.race` makes it easier to implement things like timeouts for promises.
**Good:**
```ts
import { get } from 'request';
import { writeFile } from 'fs';
import { promisify } from 'util';
const write = promisify(writeFile);
function downloadPage(url: string, saveTo: string): Promise<string> {
With async/await syntax you can write code that is far cleaner and more understandable that chained promises. Within a function prefixed with `async` keyword you have a way to tell the JavaScript runtime to pause the execution of code on the `await` keyword (when used on a promise).
**Bad:**
```ts
import { get } from 'request';
import { writeFile } from 'fs';
import { promisify } from 'util';
const write = util.promisify(writeFile);
function downloadPage(url: string, saveTo: string): Promise<string> {
### Don't leave commented out code in your codebase
Version control exists for a reason. Leave old code in your history.
**Bad:**
```ts
class User {
name: string;
email: string;
// age: number;
// jobPosition: string;
}
```
**Good:**
```ts
class User {
name: string;
email: string;
}
```
### Don't have journal comments
Remember, use version control! There's no need for dead code, commented code, and especially journal comments. Use git log to get history!
**Bad:**
```ts
/**
* 2016-12-20: Removed monads, didn't understand them (RM)
* 2016-10-01: Improved using special monads (JP)
* 2016-02-03: Added type-checking (LI)
* 2015-03-14: Implemented combine (JR)
*/
function combine(a:number, b:number): number {
return a + b;
}
```
**Good:**
```ts
function combine(a:number, b:number): number {
return a + b;
}
```
**[⬆ back to top](#table-of-contents)**
### Avoid positional markers
They usually just add noise. Let the functions and variable names along with the proper indentation and formatting give the visual structure to your code.
Optionally you can use IDE support for code folding (see Visual Studio Code [folding regions](https://code.visualstudio.com/updates/v1_17#_folding-regions)).
