DEV Community

Luís Von Muller
Luís Von Muller

Posted on

🇧🇷 Guia de Estilos para TypeScript 🎨

🔥 Este é um Guia não oficial e você pode opinar através do repositório de GitHub para juntos chegarmos a melhor definição do Ideal! Vamos colaborar? 💪

👉 Navegação por tópico facilitada!

⭐️​ Variáveis e Funções:

Use camelCase para nomear variáveis e funções

Má nomenclatura 🚫

let FulanoVariavel: string = 'Aqui está errado.. ( ఠ ͟ʖ ఠ )';
function CiclanoFuncao(){}
Enter fullscreen mode Exit fullscreen mode

Boa nomenclatura ✅​

let fulanoVariavel: string = 'Aqui está daora! (✿◠‿◠)';
function ciclanoFuncao(){}
Enter fullscreen mode Exit fullscreen mode

📦 Class

Use PascalCase para nomear suas classes! (Ou use programação funcional 👀)

Má nomenclatura 🚫

class fulano {}
Enter fullscreen mode Exit fullscreen mode

Boa nomenclatura ✅​

class Fulano {}
Enter fullscreen mode Exit fullscreen mode

Use camelCase para as propriedades e métodos de suas classes! 🔥

Má nomenclatura 🚫

class fulano {
    DeTal: string; 
    Ciclano( ){ }
} 
Enter fullscreen mode Exit fullscreen mode

Boa nomenclatura ✅​

class Fulano {
    deTal: string; 
    ciclano( ){ }
} 
Enter fullscreen mode Exit fullscreen mode

🔌​ Interfaces:

Use PascalCase para nomear a Interface ⚙️

  • Use camelCase para nomear seus membros 🥰

Não use o Prefixo "I", exemplo: IfuncaoFulano... 😡

Má nomenclatura 🚫

interface IFulano { 
    DeTal: string;
} 
Enter fullscreen mode Exit fullscreen mode

Boa nomenclatura ✅​

interface Fulano { 
    deTal: string;
} 
Enter fullscreen mode Exit fullscreen mode

🌟 Tipos

Use PascalCase para nomear o seu Tipo ⚙️

  • Use camelCase para nomear as propriedades do seu tipo! 🥰

Má nomenclatura 🚫

type fulano = {
    DeTal: string;
}
Enter fullscreen mode Exit fullscreen mode

Boa nomenclatura ✅​

type Fulano = {
    deTal: string;
}
Enter fullscreen mode Exit fullscreen mode

😳 Namespaces

Use*PascalCase*para nomear os "Namespaces" - ⭐️ Padrão do time do TS.

Má nomenclatura 🚫

namespace fulanoDeTal {
}
Enter fullscreen mode Exit fullscreen mode

Boa nomenclatura ✅​

namespace FulanoDeTal {
}
Enter fullscreen mode Exit fullscreen mode

🔢 Enum

Use_PascalCase_para nomear os Enums.

  • Use PascalCasepara nomear seus subtipos/valores.

Má nomenclatura 🚫

enum jogodoBicho {
    avestruz,
    borboleta,
    cachorro
}
// Não há endosso do Jogo do Bicho. Apenas é algo contextual que todo Brasileiro entenderia.
Enter fullscreen mode Exit fullscreen mode

Boa nomenclatura ✅​

enum JogoDoBicho {
    Avestruz,
    Borboleta,
    Cachorro
}
// Não há endosso do Jogo do Bicho. Apenas é algo contextual que todo Brasileiro entenderia.
Enter fullscreen mode Exit fullscreen mode

😅 Null vs Undefined 👀

Tente não usar nenhum deles para indisponibilidade explícita! ⭐️

Mal caso de uso 🚫

let pontos : {x: number, y: number | null | undefined }  = {x: 1, y: undefined } 
Enter fullscreen mode Exit fullscreen mode

Bom caso de uso ✅​

let pontos: {x: number, y?: number } = { x: 777 } //  
Enter fullscreen mode Exit fullscreen mode

Em suma: Precisa informar que uma propriedade é pode ser "indefinida"? Use o operador "?" antecedendo o seu tipo! 🥰

👉 Retorno de funções? 🤔

Mal caso de uso 🚫

return null;
Enter fullscreen mode Exit fullscreen mode

Bom caso de uso ✅​

return undefined;
Enter fullscreen mode Exit fullscreen mode

Por quê? Sugiro você consultar a página Sobre False, True, Truthy & Falsy. 🥰

🤨​ Callbacks?

Use null quando for parte da API ou de sua convenção usar.

É quase em um consenso em Node.js, por exemplo: error é nullem chamadas do NodeBack.

Mal caso de uso 🚫

callbackDeAlgo(undefined);
Enter fullscreen mode Exit fullscreen mode

Bom caso de uso ✅​

callbackDeAlgo(null);
Enter fullscreen mode Exit fullscreen mode

E como verificar isso aí? 😅

Cheque por "Truthy" em objetos sendo null ou undefined.

Mal caso de uso 🚫

if (error === null) // e se for undefined? 
Enter fullscreen mode Exit fullscreen mode

Bom caso de uso ✅​

if (error) // é Válido tanto para undefined quanto para o null
Enter fullscreen mode Exit fullscreen mode

👉 Um exemplo um pouco mais completo sobre verificação 🔥

Use "==" null ou "!=" null. Não use "===" ou "!==" para checar por null ou undefined quando querendo verificar tipos primitivos porque funciona apenas nos tipos primitivos supracitados e não para valores "Falseáveis", como por exemplo: 0, false, etc.

Mal caso de uso 🚫

if (error !== null) // Não garante que seja apenas nullo. Pode ser um valor Falseável.
Enter fullscreen mode Exit fullscreen mode

Bom caso de uso ✅​

if (error != null) // Garante que é um valor de tipo primitivo (ou seja, null ou undefined mas não falsy).
Enter fullscreen mode Exit fullscreen mode

📑 Formatação

O Compilador do TypeScript já fornece um bom serviço de formatação estrutural, o que já é bom o suficiente para diminuir o esforço mental do desenvolvedor (ou do time). Todavia, você também pode usar o tsfmt no terminal (linha de comando para formatar seu código) - e também está disponível como plugin para várias IDES (vscode, etc).

👉 Só um exemplo que eu acho pertinente, ou melhor, uma boa prática:

let fulano: string = 'Ciclano';
Enter fullscreen mode Exit fullscreen mode

No caso, usamos um espaço depois da definição do tipo...

  • let variavel:(espaço)tipo(espaço)=(espaço)valor(ponto e virgula)

💬 Sobre Aspas...

Prefira usar aspas simples (single quotes) ao invés de aspas duplas.

  • Times grandes que usam JS/TS o fazem. É uma convenção quasae que de mercado, também é o sugerido pelo time do "Prettier".
let nomeDoSujeito: string = 'Luís Von Müller';
Enter fullscreen mode Exit fullscreen mode

Todavia, muita vezes em inglês precisamos usar o a single quote para conjugar um verbo: "I'm"

Se a aspas simples não lhe cabe. Use então "`"

  • Faça o uso do string template do JS ao invés de concatenar variáveis strings através var + "..." + var2.

typescript
let nomeDoSujeito: string = 'Luís Von Müller';
console.log(
Quem escreveu? ${nomeDoSujeito})

Sobre outras coisas como usar "tabs" ou espaço. O sugerido para JS é 2 espaços (e muitas companias como Facebook, Airbnb, google seguem esse padrão. Mas o time do TS usa 4 e o do VScode também 😅. Isso é variável e de gosto muito mais pessoal ou convenção própria e do teu time 🥰

(Mas eu uso tabs configuradas como 4 espaços) 🤗

⚙️​ Ponto & Vírgula;

Use o ponto e vírgula, por quê?

  • Pontos e vírgulas explícitos ajudam os identadores (tsfmt/prettier) a identificar e "estruturar" seu código.
  • A falta de ponto e vírgula pode ser incômodo para novos desenvolvedores em TS. Já que a maioria das linguagens o implementa. (Houve um debate sobre como isso pode ser "incomodo" para novos desenvolvedores e outros. https://github.com/tc39/ecma262/pull/1062)
  • Empresas grandes usam em suas implementações, ex: Google/Angular - Facebook/React - Microsoft/VScode...

🗂 Sugestão para boa nomeação de arquivos.

Essa aqui é uma baita de uma discussão, depende muito do que ambiente você está e se você está seguindo o padrão de nomeação de um framework, ex: React para Componentes. Mas no geral o que a maioria dos times usa é o seguinte:

Use camelCase para nomear seus arquivos, exemplo:

  • utils.ts
  • helpersDaora.ts
  • mapeamentoEndPointsDaApi.ts

🤨​ Tipo ou Interface?

Tipos devem ser usados para definir, adivinha? Tipos. Ou seja, se você tem uma função, ela retorna um valor. E esse valor possui um tipo. Mas essa função, também recebe algo. E esse algo, também são valores, ou seja, também podem ser tipos. Mas a "meta" ideia é que interface forneça uma interface 😅. Eu acho que esse exemplo clarifica...

Quando usar qual?

  • Tipos: Precisa de União ou Interseção de tipos (e provavelmente você vai preferir Tipos também se quiser implementar alguns tipos de mapeamentos Genéricos de objetos).
  • Interfaces: quando você precisa dizer que algo "implements" ou "extends", como por exemplo uma classe, para receber argumentos em uma função, ou até mesmo para quando você tá querendo criar alguma função extremamente composta bem maneira 👏.

😅 Ou do jeito que você se sentir mais confortável e seguro para a implementação que está fazendo! 👀

Aqui em baixo, eu poderia definir a função de outra maneira, optei por essa.

`typescript
/** Definimos a interface (ou contrato) de uso da função */
interface DizerOi {
nome: string;
sobrenome?: string;
}

/** Definimos que o tipo de retorno da função como uma Array de Strings */
type DisseOi = string[];

/** Vamos dizer oi 10x! e retornar um array! */
const dizerOi = ({nome, sobrenome}: DizerOi): DisseOi => {
return [...Array(10).keys()].map((key) => {
return Olá ${nome} ${sobrenome ?? ''};
})
}

console.log(dizerOi({nome: 'Luís'}));
`

👯‍♀️ Anotação do tipo Array 👯‍♂️

Use tipo[] ao invés de Array<tipo>

Mal caso de uso 🚫

typescript
let variosNumeros: Array<number> = [1,2,3,4,5,6,7];

Bom caso de uso ✅​

typescript
let variosNumeros: number[] = [1,2,3,4,5,6,7];

⚠️​ Comparadores "===" e "=="

😴​ Relaxa amigo! Você tá usando TypeScript. Pode usar "===" tranquilamente!

🥰 Obrigado por ler até aqui!

Discussion (5)

Collapse
incognitadev profile image
Luis Sousa

Muito bom. Só para avisar esta com alguns erros de formatação.

Collapse
luisvonmuller profile image
Luís Von Muller Author

Sim, o conteúdo original tá no: "luis-von-muller.gitbook.io/typescr..." - Aqui só dei um ctrl + c / v -> Não tô com muito tempo hehe

Collapse
luisvonmuller profile image
Luís Von Muller Author

Seriously?

Collapse
tenebris_aenigma profile image
tenebrisAenigma

Coisa linda ♥‿♥