Guias práticos sobre dicionário e aplicativosAprenda a configurar dicionários personalizados e regras de exceção no VS Code para que o corretor ortográfico entenda jargões de programação sem interromper seu fluxo de trabalho.
Imagem editorial ilustrando 5 Ajustes para Deixar o Corretor Ortográfico Inteligente no VS Code e Acabar com 'Erros' em Variáveis
Você sabe aquela irritação sutil de abrir um arquivo de código e ver um tapete de ondulações vermelhas sob palavras que você sabe que estão certas? Para nós que escrevemos código em Português do Brasil, mas mantemos a sintaxe técnica em inglês, o corretor ortográfico padrão é um inimigo. Ele xinga const, import, function e até nomes de variáveis como usuarioId. O resultado é um ruído visual que quebra a concentração e, pior, nos treina a ignorar erros reais.
O problema não é o português, é a falta de contexto da ferramenta. Editores de texto comuns não sabem distinguir uma string de um comentário, muito menos um framework de um verbo irregular. Felizmente, o ecossistema do VS Code em 2026 amadureceu o suficiente para resolver isso com ajustes finos, não desativando o corretor, mas ensinando ele a pensar como um programador.
O corretor embutido do VS Code é basicamente o mesmo motor do navegador ou do Word: ele verifica se a palavra existe no dicionário. Se não existe, é erro. Ponto final. Isso funciona para redação, mas falha miserável em const status = 'pending'. O "status" será marcado como estrangeirismo, e "const" como inexistente.
Aqui que entra a extensão Code Spell Checker (ID streetsidesoftware.code-spell-checker). Diferente das ferramentas padrão que buscam perfeição lexical, ela foca em erros de digitação comuns, permitindo que você adicione termos técnicos facilmente. A grande vantagem é o modelo de permissão: em vez de desligar o chefe, você dá uma lista de convidados VIPs.
Para quem trabalha com documentação técnica, a comparação entre ferramentas é inevitável. Enquanto o Grammarly é excelente para reduzir o tom de agressividade em e-mails de trabalho, ele é pesado demais e intrusivo dentro de um IDE. O Code Spell Checker é leve, não envia dados para a nuvem para análise de tom e se integra visualmente como se fosse nativo. Se você instalar o pacote de idioma Português brasileiro para esta extensão, ela já vem com uma base de termos tecnológicos aceitos, mas a mágica mesmo acontece na customização.
Adicionar palavras individualmente clicando com o botão direito e escolhendo "Adicionar ao dicionário" funciona no curto prazo, mas é um erro estratégico. Isso salva a palavra no dicionário global do seu usuário. Se você trabalhar em equipe ou clonar o projeto em outra máquina, os erros voltarão. A solução profissional é o arquivo cspell.json.
Criar este arquivo na raiz do seu projeto padroniza o que é "certo" para aquele código específico. Pense nele como um arquivo de configuração do ESLint, mas para palavras. Dentro dele, você define uma lista words que serão ignoradas universalmente para qualquer pessoa que abra aquele projeto com a extensão instalada.
Um exemplo prático: imagine que você está usando uma API externa que retorna um campo chamado qtde_produtos. O corretor vai chorar. Em vez de ignorar, você adiciona "qtde_produtos" ao array de palavras no cspell.json. Isso documenta implicitamente que aquele termo estranho é uma escolha técnica e não um erro de digitação. É uma forma de live documentation da gíria técnica daquele sistema.
Mesmo com um dicionário robusto, o corretor vai falhar em nomes dinâmicos. Se você tem uma variável nomeDoUsuario, o corretor pode não reconhecer a palavra inteira, e muito menos a junção. Adicionar cada variável ao dicionário é impossível. A solução aqui não é léxica, é sintática: usar expressões regulares (RegEx) para dizer ao corretor "ignore qualquer coisa que pareça código".
No arquivo cspell.json, você pode usar a chave ignoreRegExpList. A configuração que eu uso e recomendo para a maioria dos projetos em JavaScript, Python ou PHP é focada em camelCase e snake_case. Uma expressão simples como "[a-zA-Z0-9_]+" dentro de uma lista de exclusão para arquivos de código limpa 90% do ruído.
O truque é ser específico. Não ignore tudo. Ignore apenas os padrões que sabidamente são variáveis. Se você trabalhar com frontend, por exemplo, vai querer ignorar padrões de kebab-case em CSS classes. Isso requer um ajuste fino no RegEx, mas o ganho de produtividade é imediato. Você para de ver vermelho nas declarações e continua vendo vermelho nos comentários, onde os erros de português realmente acontecem.
Um erro clássico é tentar fazer o corretor entender Java, C#, Rust e HTML simultaneamente. Você não quer que ele verifique sintaxe de tags HTML, mas quer que verifique o texto dentro de parágrafos <p>. A solução é limitar o escopo de atuação da extensão usando a configuração cSpell.enabledLanguageIds.
No seu settings.json (global ou do workspace), você pode definir explicitamente em quais linguagens a verificação ocorre. Eu costumo habilitar para markdown, plaintext, tex e git-commit. Para javascript, typescript, python e json, muitas vezes prefiro desativar a verificação de strings e variáveis, deixando a extensão focada apenas nos comentários, se a ferramenta permitir essa granularidade.
Isso evita situações ridículas como o corretor tentando corrigir nomes de pacotes em JSON ou chaves de criptografia. Se você escreve muita documentação em Markdown dentro do repositório, essa separação é vital. Garante que seu README.md esteja impecável, seguindo boas práticas de legibilidade, algo que discutimos ao analisar o score de legibilidade no Hemingway Editor, enquanto seu código permanece intocado por regras de gramática que não se aplicam.
Chegamos em um ponto nevrálgico em 2026: a adequação linguística. O Acordo Ortográfico e as normas gramaticais brasileiras pedem que usemos termos em português sempre que possível. "Tela" em vez de "screen", "arquivo" em vez de "file". No entanto, a realidade do desenvolvimento nos obriga a lidar com "commits", "deploys", "bugs" e "pull requests".
O seu corretor configurado deve refletir essa híbridez saudável. Não adianta forçar o tradutor do navegador e escrever "requisição de puxar" para traduzir "pull request". O termo técnico se cristalizou. A sua função é garantir que, ao escrever um comentário explicando um bug complexo, a concordância verbal e a regência estejam corretas.
Configurar o dicionário para aceitar "deploy" como verbo e substantivo é uma necessidade real, não um preguiçoísmo. O controle aqui é manual e editorial. Adicione ao cspell.json os termos que são jargão consolidado da sua equipe. Isso mantém a limpeza visual sem sacrificar a precisão técnica. Lembre-se: o objetivo é que o leitor do código (que pode ser você daqui a seis meses) entenda o porquê daquela lógica, sem tropeçar em erros gramaticais que desviam a atenção.
Quando lidamos com código, a eficiência é a moeda mais valiosa. Perder trinta segundos lidando com uma sugestão de correção em uma variável privada ou um nome de API打破了 o "flow state", aquele estado de concentração profunda que programadores buscam. Ao configurar seu ambiente para respeitar as gírias técnicas inevitáveis, você não está desligando a gramática. Você está elevando o padrão da comunicação técnica, garantindo que o corretor funcione como um parceiro inteligente nos comentários e na documentação, e não como um fiscal burocrático ignorante sobre sintaxe de programação. Um ambiente bem configurado sinaliza maturidade profissional: você sabe a diferença entre escrever código e escrever texto.
Relato prático de como a análise de sentimento do Grammarly transformou minha comunicação corporativa, reduzindo conflitos desnecessários e melhorando a resposta de equipes em e-mails de alta pressão.
Entenda como o algoritmo do Hemingway calcula a dificuldade do seu texto em português e por que ele nem sempre acerta a mão na gramática brasileira.