Todo programador erra isso

Dicas essênciais de clean code que vai fazer diferença no seu código.

1. Números mágicos

Não faça validações com valores que não tem um significado claro, use variáveis com um nome curto e que explica o que significa. ❌ Jeito errado:

if (boleto > 400)
    return console.log("Vai dar pra pagar não");

✔ Jeito certo:

const saldo = 400;
if (boleto > saldo)
    return console.log("Vai dar pra pagar não");

2. Escolha nomes descritivos

❌ Jeito errado:

const x = 15

✔ Jeito certo:

const duracaoAceitarPedido = 15

3. Use const para valores imutáveis

❌ Jeito errado:

let maximoCaracteres = 4000

✔ Jeito certo:

const maximoCaracteres = 4000

4. Não use uma função para executar mais de uma ação

❌ Jeito errado:

function processarDadosEEnviarEmail(dados) {}

✔ Jeito certo:

function processarDados(dados) {}

function enviarEmail(dadosProcessados) {}

5. Comente apenas quando for necessário

❌ Jeito errado:

// Verifica se o usuário está autenticado
if (isLoggedIn) {}

✔ Jeito certo:

if (isLoggedIn) {} // O comentário só é necessário se o contexto for complexo.
KitsuneSemCaldahá 6 meses
2. Evite condicionais negativas
Quando for necessário validar algo, deixa a negacao para o else.
❌ Jeito errado:

if (!isLogged) {}

✔ Jeito certo:

if (isLogged) {}

Sou obrigado a discordar dessa:

O uso de condicionais negativas é muito atraente principalmente em sistemas construídos com guard clauses e early return. Além de diminuir o uso de if/else aninhado que sempre deve ser evitado.

def processar_requisicao(usuario):
    if not usuario.is_autenticado():
        return "Usuário não está logado."
    
    # Processa a requisição se o usuário estiver logado
    return f"Requisição processada para {usuario.nome}."

Compare com

def processar_requisicao(usuario):
    if usuario.is_autenticado():
        # Processa a requisição se o usuário estiver logado
        return f"Requisição processada para {usuario.nome}."
    else:
        return "Usuário não está logado."
condEduardohá 6 meses
Eu já ia comentar isso, o post desse OP tá parecendo copia e cola de algum lugar, ou deve ser algum iniciante que acha que deve seguir todas as convenções do livro.
LuizOutlierhá 6 meses
Esqueci de revisar essa parte, mas a ideia era pra não começar com a negação se seu objetivo, por exemplo, é retornar algum valor de uma api, ai depois que faz o tratamento do erro.
Detinhohá 6 meses

Esse 5 aí eu abro exceções para casos que eu quero indicar atomicidade. E dependendo do caso uso o Or também.

Exemplo: createOrActivateUsers.

Exemplo2: compareAndSet, esse bem da API do Java (AtomicInteger por exemplo).

LuizOutlierhá 6 meses
Realmente, varia de caso pra caso, mas a intenção foi pra não colocar tudo em uma mesma função dependendo do objetivo.
Gustavotzhá 6 meses

Aqui no W3Schools tem explicadinho boas praticas seguem os estudos ai, W3Schools - Boas praticas