🇧🇷Guia de Estilos 🎨

🔥 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(){}

Boa nomenclatura ✅​ 

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

📦 Class

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

Má nomenclatura 🚫

class fulano {}

Boa nomenclatura ✅​ 

class Fulano {}

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

Má nomenclatura 🚫

class fulano {
    DeTal: string; 
    Ciclano( ){ }
}

Boa nomenclatura ✅​ 

class Fulano {
    deTal: string; 
    ciclano( ){ }
}

🔌​ 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;
}

Boa nomenclatura ✅​ 

interface Fulano { 
    deTal: string;
}

🌟 Tipos

Use PascalCase para nomear o seu Tipo ⚙️

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

Má nomenclatura 🚫

type fulano = {
    DeTal: string;
}

Boa nomenclatura ✅​ 

type Fulano = {
    deTal: string;
}

😳 Namespaces

UsePascalCase para nomear os "Namespaces" - ⭐️ Padrão do time do TS.

Má nomenclatura 🚫

namespace fulanoDeTal {
}

Boa nomenclatura ✅​ 

namespace FulanoDeTal {
}

🔢 Enum

UsePascalCasepara 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.

Boa nomenclatura ✅​ 

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

😅 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 }

Bom caso de uso ✅​ 

let pontos: {x: number, y?: number } = { x: 777 } //

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;

Bom caso de uso ✅​ 

return undefined;

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

- Talvez ela ainda não esteja disponível ainda, foi mal gurizada hahaha! 😅

🤨​ 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);

Bom caso de uso ✅​ 

callbackDeAlgo(null);

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?

Bom caso de uso ✅​ 

if (error) // é Válido tanto para undefined quanto para o null

👉 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.

Bom caso de uso ✅​ 

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

📑 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';

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';

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.

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.

/** 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 🚫

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

Bom caso de uso ✅​ 

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!

NextFalse, true, "Falsy" & "Truthy" 👀

Last updated