Buscar uma chave em um dict Python com dez entradas leva o mesmo tempo que buscar em um com dez milhões. Isso não é acidente de uma linguagem rápida. O dict do Python, o HashMap do Java e o Map do JavaScript são todos tabelas hash, e todo o design existe para que busca, inserção e remoção rodem em O(1) na média. A notação Big O dá a essa busca o rótulo “tempo constante”. Este é o mecanismo que justifica isso. ...
Um programa em C que libera um buffer e continua lendo dele ainda compila. Depois corrompe a memória, às vezes na hora, às vezes três requisições depois, numa parte do código que nunca tocou aquele buffer. O Rust rejeita esse programa já no cargo build, sem nenhum garbage collector envolvido. O compilador rastreia quem é o owner de cada valor e quem pode acessá-lo. Esse rastreamento é ownership e borrowing. ...
Um teste para place_order precisa de um gateway de pagamento, um cliente de SMS e uma calculadora de impostos. Use os de verdade e cada execução do teste cobra um cartão e manda um SMS para um número de telefone real. Um teste unitário tem que rodar em milissegundos e sem rede, então os três precisam ser substituídos por outra coisa. Esse “outra coisa” vem em cinco tipos, cada um resolvendo um problema diferente, e tratá-los como intercambiáveis é por isso que as discussões de “só usa um mock” em code review não terminam nunca. ...
Você salva um arquivo, o Prettier reformata, e o ESLint aponta imediatamente um erro na linha que o Prettier acabou de tocar. As duas ferramentas estão configuradas, as duas estão rodando, e em vez de ajudar, estão brigando uma com a outra. As duas ferramentas fazem trabalhos diferentes. O problema é que as duas têm opinião sobre uma única coisa: a aparência do código na tela. O que o ESLint realmente verifica O ESLint analisa seu código em uma árvore de sintaxe abstrata e executa regras sobre a estrutura dela. A maior parte do seu valor vem de regras que encontram bugs reais: uma variável nunca definida, um return inalcançável depois de outro return, um import que ficou sem uso depois de uma refatoração, uma chave duplicada em um objeto que sobrescreve a primeira em silêncio. São verificações semânticas: o ESLint lê o que o código faz. ...
<.+> contra <b>bold</b> and <i>italic</i> não encontra <b>. Encontra a string inteira, do primeiro < ao último >. Nada está quebrado. É exatamente isso que um quantificador greedy deve fazer, e também é o bug mais comum de “o regex está casando demais”. Depois que você entende o que o motor faz enquanto lê o seu padrão, esse bug e a maioria dos parentes dele deixam de ser mistério. Como um Motor de Regex Lê o Seu Padrão Um motor de regex não compara o seu padrão com a string como você compara duas strings por igualdade. Os motores que você usa no dia a dia (re do Python, RegExp do JavaScript, PCRE, .NET, Java) são regex-directed: eles percorrem o padrão da esquerda para a direita, token por token, e para cada token tentam consumir caracteres da string na posição atual. Quando um token casa, o motor avança tanto o ponteiro do padrão quanto o da string. Quando um token falha, o motor faz backtracking: volta ao último ponto em que tinha uma escolha, como um quantificador que poderia ter casado com menos caracteres ou um ramo de alternância ainda não tentado, e tenta a outra opção. ...
Por Que any Faz Você Perder o Tipo que Passou? Tipe um parâmetro como any e o TypeScript para de verificar tudo o que sai da função: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compila, quebra em tempo de execução Você sabe que passou um array de números. O compilador não sabe, porque any faz ele parar de olhar. O tipo de n fica any, então chamar um método de string em um número compila sem problemas e lança TypeError: n.toUpperCase is not a function em tempo de execução. ...
Abra um arquivo que não existe em Python e open() lança um FileNotFoundError que sobe para fora da sua função. Faça o mesmo em Go e os.ReadFile devolve um valor error ao lado de um slice de bytes nil. Mesma falha, duas formas de código completamente diferentes em volta dela. A diferença não é cosmética. Ela decide se quem chama pode ignorar a falha por acidente, e se o compilador percebe quando isso acontece. ...
Um cliente travado num retry loop sem backoff pode colocar mais carga na sua API em um minuto do que os outros dez mil clientes juntos. Do seu lado, isso não parece um ataque. Parece um bug do lado deles, e se torna um incidente do seu lado. Um rate limiter contém esse cliente antes que ele chegue a esse ponto. O que um rate limiter realmente decide? A cada request, o limiter se faz uma única pergunta: essa chave fez requests demais na janela atual? Três escolhas transformam isso em algo que você pode implementar. ...
Um listener de scroll em window pode disparar centenas de vezes durante um único swipe. Se você executa getBoundingClientRect() em cada card de um feed a cada um desses eventos, cinquenta imagens já bastam para a página engasgar. A Intersection Observer API tira essa verificação do caminho do scroll: você registra quais elementos observar, e o navegador avisa quando a visibilidade deles muda de fato. Como o IntersectionObserver funciona Um observer vigia um ou mais elementos target em relação a um root (o viewport, por padrão) e chama um callback sempre que um target cruza um limite de visibilidade. ...
Abra um arquivo salvo como UTF-8 em uma ferramenta que assume outra codificação e café se transforma em café. Os bytes no disco não mudaram. O que mudou foi a regra usada para transformá-los de volta em caracteres, e as duas regras discordam sobre o que o byte 0xC3 significa. A maioria dos bugs de “caracteres estranhos” sai da mesma raiz: nomes de arquivo corrompidos, formulários ilegíveis, um emoji que faz um insert no banco falhar, duas strings que parecem idênticas mas falham na comparação. Por trás de cada um está a confusão entre duas coisas distintas: Unicode e UTF-8. ...