https://github.com/angular-ru/angular-style-guide
Angular / TypeScript projects style guide
https://github.com/angular-ru/angular-style-guide
Last synced: 11 days ago
JSON representation
Angular / TypeScript projects style guide
- Host: GitHub
- URL: https://github.com/angular-ru/angular-style-guide
- Owner: Angular-RU
- Created: 2021-04-23T10:51:37.000Z (about 4 years ago)
- Default Branch: main
- Last Pushed: 2021-06-20T19:54:01.000Z (about 4 years ago)
- Last Synced: 2025-03-18T09:13:29.986Z (3 months ago)
- Homepage:
- Size: 83 KB
- Stars: 2
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Angular / TypeScript projects style guide
**TypeScript + ESLint**
- [Require that member overloads be consecutive](#rules-for-eslint)
- [Requires using either `T[]` or `Array` for arrays](#array-types)
- [Disallows awaiting a value that is not a Thenable](#await-thenable)
- [Requires type annotations to exist (typedef)](#typedef)
- [Require explicit return and argument types on exported functions' and classes' public class methods](#explicit-module-boundary-types)
---
## TypeScript + ESLint
- https://github.com/typescript-eslint/typescript-eslint
### Require that member overloads be consecutive
Use
[`'@typescript-eslint/adjacent-overload-signatures': 'error'`](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/adjacent-overload-signatures.md),
because grouping overloaded members together can improve readability of the code.
 `Bad pattern`
```ts
class Foo {
foo(s: string): void;
foo(n: number): void;
bar(): void {}
foo(sn: string | number): void {}
}
export function foo(s: string): void;
export function foo(n: number): void;
export function bar(): void;
export function foo(sn: string | number): void;
```
 `Good pattern`
```ts
class Foo {
foo(s: string): void;
foo(n: number): void;
foo(sn: string | number): void {}
bar(): void {}
}
export function bar(): void;
export function foo(s: string): void;
export function foo(n: number): void;
export function foo(sn: string | number): void;
```
### Requires using either `T[]` or `Array` for arrays
Use
[`'@typescript-eslint/array-type': 'error'`](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/array-type.md)
for always using `T[]` or readonly `T[]` for all array types.
 `Bad pattern`
```ts
const x: Array = ['a', 'b'];
const y: ReadonlyArray = ['a', 'b'];
```
 `Good pattern`
```ts
const x: string[] = ['a', 'b'];
const y: readonly string[] = ['a', 'b'];
```
### Disallows awaiting a value that is not a Thenable
Use
[`'@typescript-eslint/await-thenable': 'error'`](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/await-thenable.md)
 `Bad pattern`
```ts
await 'value';
const createValue = () => 'value';
await createValue();
```
 `Good pattern`
```ts
await Promise.resolve('value');
const createValue = async () => 'value';
await createValue();
```
### Requires type annotations to exist
Many believe that requiring type annotations unnecessarily can be cumbersome to maintain and generally reduces code
readability. TypeScript is often better at inferring types than easily written type annotations would allow. And many
people believe instead of enabling typedef, it is generally recommended using the `--noImplicitAny` and
`--strictPropertyInitialization` compiler options to enforce type annotations only when useful. This rule can enforce
type annotations in locations regardless of whether they're required.
But why is annotation description useful? Because for the code review, you will not be able to find out what will change
in runtime due to inferred types. But when you specify types, you know exactly what to change to:
It is also worth noting that if we do not use type annotations for methods, it may be difficult for us to read the code
during the review, we may not notice something and not pay attention to how the data type has changed if the build does
not crash with an error.
Reference to [explicit-module-boundary-types](#explicit-module-boundary-types)
# Require explicit return and argument types on exported functions' and classes' public class methods
Explicit types for function return values and arguments makes it clear to any calling code what is the module boundary's
input and output.
 `Bad pattern`
```ts
// Should indicate that a number is returned
export function myFn() {
return 1;
}
```
 `Good pattern`
```ts
// A return value of type number
export function myFn(): number {
return 1;
}
```