TypeScript Style Guide and Coding Conventions v1.0.0-beta

Owned by Edgar Guadalupe Manrique Martinez (Unlicensed)
Oct 26, 2022
3 min read

 

Una guía de estilo no oficial de TypeScript

 

Style

Category

Style

Category

UpperCamelCase

class / interface / type / enum / decorator / type parameters

lowerCamelCase

variable / parameter / function / method / property / module alias

CONSTANT_CASE

global constant values, including enum values

#ident

private identifiers are never used.

Variable y Función

  • Use lowerCamelCase para nombrar sus variables y funciones

Motivo: JavaScript convencional

Malo

var FooVar; const FooVar; let FooVar; function BarFunc() { }

Bueno

var fooVar; const fooVar; let fooVar; function barFunc() { }

Class

  • Utilice PascalCase para los nombres de las clases.

Motivo: esto es bastante convencional en JavaScript.

Malo

class foo { }

Bueno

  • Use camelCase de miembros y métodos de clase

Motivo: se sigue naturalmente de la convención de nomenclatura de variables y funciones.

Interfaz

  • Use PascalCase para el nombre.

Razón: Similar a la clase

  • Use camelCase para los members

Razón: Similar a la clase

  • No prefijo con I

Razón: No convencional. lib.d.ts define interfaces importantes sin una I (por ejemplo, Ventana, Documento, etc.).

Malo

Bueno

Type

  • Use PascalCase para el nombre.

Razón: Similar a la clase

  • Use camelCase para los members.

Razón: Similar a la clase

Namespace

  • Use PascalCase para nombres

Motivo: Convención seguida por el equipo de TypeScript. Los espacios de nombres son efectivamente solo una clase con miembros estáticos. Los nombres de las clases son PascalCase => Los nombres de los espacios de nombres son PascalCase

Malo

Bueno

Enum

  • Use PascalCase para nombres de enum

Razón: Similar a Clase. es un type.

Malo

Bueno

  • Use PascalCase para el enum member

Motivo: Convención seguida por el equipo de TypeScript

Malo

Bueno

Null vs. Undefined

  • No usar ninguno de los dos por indisponibilidad explícita

Razón: estos valores se usan comúnmente para mantener una estructura consistente entre valores. En TypeScript usas tipos para denotar la estructura.

Malo

Bueno

 

  • Use undefined en general (considere devolver un objeto como {valid:boolean, value?:Foo} en su lugar)

Malo

Bueno

 

  • Use null donde sea parte de la API o convencional

Motivo: es convencional en Node.js, p. el error es null para las devoluciones de llamada de estilo NodeBack.

Malo

Bueno

 

  • Use la verificación de la verdad para que los objetos sean null o undefined

Malo

Bueno

 

  • Utilice== null / != null (not === / !==) para comprobar si hay valores null / undefined en las primitivas, ya que funciona tanto para valores null / undefined como para otros valores falsos (como '', 0, false).

Malo

Bueno

Formatting

Spaces

  • Utilice 2 espacios. No tabs.

Semicolons

  • Utilice punto y coma.

Motivos: los puntos y comas explícitos ayudan a que las herramientas de formato de idioma brinden resultados consistentes. La falta de ASI (inserción automática de punto y coma) puede disparar nuevos desarrolladores, p. foo() \n (function(){}) será una declaración única (no dos). Advertencia TC39 sobre esto también. Equipos de ejemplo: airbnb, idiomático, google/angular, facebook/react, Microsoft/TypeScript.

Array

  • Anote las matrices como foos: foos: Foo[] en lugar de foos: foos: Array<Foo>.

Razones: Es más fácil de leer. Es utilizado por el equipo de TypeScript. Hace más fácil saber que algo es una matriz ya que la mente está entrenada para detectar [].

Filename

  • Nombra archivos con camelCase. camelCase. E.g. accordion.tsx, myControl.tsx, utils.ts, map.ts etc.

Motivo: Convencional en muchos equipos de JS.

type vs. interface

  • Use type cuando necesite una unión o intersección:

  • Utilice la interface cuando desee extends o implements

== or ===

  • use === ya que eso es lo que se usa en el código base de TypeScript.