Conceitos Fundamentais

Como programadores, começamos distinguindo entre tipos primitivos e tipos compostos. Tipos primitivos representam valores imutáveis simples que costumam ser copiados por valor durante atribuições. Já tipos compostos (por exemplo, objetos, arrays) são estruturas de dados que armazenam referências. Compreender essa fronteira facilita o raciocínio lógico, a identificação de custos de memória e o design de APIs que lidam com dados básicos de domínio.

• Primitivo por valor: cada cópia é independente. Alterar uma cópia não afeta a original na maioria das linguagens.
• Imutabilidade de primitivos: em muitas linguagens, o valor de um primitivo não pode ser modificado em si; você cria uma nova instância ao “modificar”.
• Atenção às exceções: em algumas linguagens, null/undefined, NaN ou NaN-like podem exigir tratamento específico para evitar erros de lógica.

Principais Tipos Primitivos (exemplos práticos)

Abaixo descrevo os tipos primitivos comuns, com notas sobre representação, operações típicas e considerações de uso em lógica de programação:

• Number: representa números inteiros e de ponto flutuante (em muitas linguagens via IEEE 754). Operações aritméticas básicas, comparações e funções de arredondamento são comuns.
• String: sequence de caracteres. Em geral, imutável; operações incluem concatenação, extração de substrings e interações com números via coerção explicita.
• Boolean: verdadeiro (true) ou falso (false). Usado para controle de fluxo, condições e flags.
• Null: ausência intencional de valor. Diferente de undefined, representa “nada aqui”.
• Undefined: valor não inicializado ou não atribuído. Em algumas linguagens, é distinto de null.
• Symbol: tipo primitivo único (geralmente para identificadores). Em algumas linguagens, oferece unicidade estável.
• BigInt: representação de inteiros grandes além do limite de Number, útil para cálculos precisos sem perda de precisão.

Observação: a semântica exata pode variar entre linguagens, mas o conceito de primitivos como valores simples e imutáveis é amplamente compartilhado. Aqui, apresento uma visão comum para fundamentar lógicas de validação, casting e decisões condicionais.

Conversão de Tipos: Casting e Coerção

Em lógica de programação, entender quando ocorre coerção (conversão implícita) versus cast (conversão explícita) evita armadilhas de lógica. A prática recomendada é usar conversões explícitas quando o objetivo é clareza e previsibilidade.

• Explicit casting (conversões explícitas):>
  • Number(“42”) ou parseInt(“42”, 10) — transforma string em número.
  • String(42) — transforma número em string.
  • Boolean(“”) ou Boolean(0) — transforma valores em booleanos.
• Coerção implícita (coerção automática): potenciais armadilhas. Em algumas linguagens, operadores podem promover tipos automaticamente (ex.: “1” + 2 resulta em “12” em muitas implementações, ou 1 + true resulta em 2).
• Cuidados com NaN e null/undefined: operações entre tipos podem retornar NaN ou estados nulos se não houver validação prévia.

// Exemplos de tipos primitivos e coerção em JavaScript
let a = 5;          // number
let b = "3.14";     // string
let c = true;         // boolean

let n = Number(b);       // 3.14
let i = parseInt(b, 10); // 3
let s = String(a);        // "5"
let d = +b;                // 3.14 (unário +)
let f = Boolean(0);        // false

console.log(typeof n); // "number"
console.log(n + a);    // 8.14

Boas práticas: prefira casting explícito quando o objetivo é transparência. Use typeof e checagens apropriadas para evitar armadilhas comuns, especialmente ao lidar com entrada de usuário ou resultados de funções.

Boas Práticas e Armadilhas Comuns

• Defina claramente o contrato de tipos de suas funções. Declare expectativas de entrada e saída para evitar surpresas em lógica de controle.
• Use comparação estrita (===) em vez de igualdade frouxa (==) para evitar coerção indesejada.
• Trate null e undefined com cuidado. Em JS, por exemplo, typeof null retorna “object”; cheque explicitamente null quando relevante.
• Verifique NaN com mecanismos adequados (ex.: Number.isNaN ou isNaN, conforme contexto) para não confundir com zero ou string vazia.
• Considere a consistência de representação de dados ao longo de módulos. Documente o tipo esperado para cada entrada de função e mensagem de retorno.