O que é palavras dentro da outra
A técnica de palavras dentro da outra é simplesmente verificar se uma string existe como subsequência dentro de outra string. Parece óbvio, mas na prática as pessoas complicam demais. Você já deve ter visto alguém escrever um loop aninhado com três níveis quando um `contains()` resolve em uma linha.
Verificando palavras dentro da outra na prática
Deixa eu te mostrar como isso funciona de verdade. Tem um problema comum que eu encontrei recentemente e que ninguém conta. Você tem uma lista de termos para detectar num texto grande, digamos umas duzentas palavras-chave, e precisa saber quais aparecem dentro do corpo textual. A solução ingênua é percorrer cada termo e aplicar um indexOf pra cada um. Funciona. Mas performance cai feio quando o texto vai pra casa dos milhares de caracteres. O workaround que eu uso desde então é construir um Aho-Corasick pra múltiplas buscas simultâneas. Sim, soa pesado no início, mas o ganho é absurdo. Deixei de gastar segundos em requisições que agora rodam em milissegundos. O custo é só o tempo de construção do autômato, que é mínimo se você tiver uma lista fixa de termos.
Se for uma busca simples de uma única palavra, aí não tem frescura. Em Python seria algo como: "texto completo" in "texto completo aqui dentro"
Em JavaScript o equivalente seria: "texto completo".includes("texto")
Questão de um segundo. O problema é quando você escala pra múltiplas verificações ou precisa rastrear posições exatas. Aí entra a parte que a maioria ignora.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Implementação passo a passo
Vamos começar pelo básico. Pegamos uma palavra-alvo e uma string onde buscamos. O algoritmo mais simples usa dois ponteiros: um varre a palavra-alvo, outro varre a string principal. Quando há correspondência, avançamos ambos. Quando não, apenas o ponteiro da string principal avança. Isso é procura por subsequência pura. Eu costumo preferir uma abordagem diferente quando preciso de robustez. O método KMP (Knuth-Morris-Pratt) evita retrocesso desnecessário na string principal construindo um array de prefixes. O overhead inicial compensa rapidinho se você for fazer múltiplas comparações com a mesma palavra.
Um detalhe que poucos mencionam: case sensitivity. Se seu texto tem mixed case, converter tudo pra lowercase antes da comparação economiza bugs depois. Mas tome cuidado com acentos. "Café" não é igual a "cafe" numa comparação simples. O ideal é normalizar com unicodedata.normalize em Python, ou usar regex com flags apropriadas.
Armadilhas comuns
O erro mais frequente que vejo em código novo é confundir substring com subsequência. Substring exige continuidade de caracteres. Subsequência permite pular caracteres no meio. Se você precisa encontrar "palavra" dentro de "palaavra", isso é subsequência, não substring. O código errado vai falhar silenciosamente nessa distinção. Outro problema é performance em strings muito longas. Verificar palavras dentro da outra num texto de megabytes usando indexOf repetidamente pode travar uma thread inteira. Nesses casos, considere pré-processar o texto ou usar estruturas como suffix trees ou suffix arrays para buscas repetitivas.
E tem uma limitação importante: essa abordagem não lida bem com edição de strings dinâmicas. Se o texto muda constantemente entre buscas, reconstruir índices e autômatos sobe o custo. Aqui eu recomendo simplesmente manter uma cópia imutável para busca e aplicar a edição separadamente.
Alternativas quando o básico falha
Se o Aho-Corasick é overkill pro seu caso, existe o Trie. Ele organiza seus termos numa árvore e permite busca paralela em uma única passagem pelo texto. A memória consumida é maior, mas a velocidade é boa para conjuntos moderados de palavras, tipo cem a mil termos. Bloom filters também merecem menção quando você só precisa de uma resposta binária — existe ou não existe — e pode tolerar falsos positivos. São incrivelmente eficientes em memória. Eu uso Bloom filters como camada de triagem antes de rodar verificações mais pesadas, e isso corta custo computacional em cerca de 80% nos meus projetos.
A escolha final depende do seu cenário específico. Múltiplos padrões num texto grande? Aho-Corasick. Poucos padrões, texto pequeno? indexOf já basta. Textos que mutam frequentemente? Trie com atualização incremental. E quando nada disso funciona, ai sim vale a pena pensar em engine de busca dedicada como Elasticsearch, mas isso é outro nível de complexidade.
