Cerca una chiave in un dict Python con dieci elementi e ci metti lo stesso tempo che cercarla in un dict con dieci milioni. Non è un caso dovuto a un linguaggio veloce. Il dict di Python, la HashMap di Java e la Map di JavaScript sono tutte hash table, e l’intero design esiste per far girare lookup, inserimento e cancellazione in O(1) in media. La notazione Big O chiama questa lookup “tempo costante”. Ecco il meccanismo che se lo merita. ...
Un programma in C che libera un buffer e continua a leggerlo compila comunque. Poi corrompe la memoria, a volte subito, a volte tre richieste più tardi, in una parte di codice che quel buffer non lo ha mai toccato. Rust rifiuta quel programma già al cargo build, senza alcun garbage collector di mezzo. Il compilatore tiene traccia di chi possiede ogni valore e di chi può accedervi. Questo tracciamento si chiama ownership e borrowing. ...
Un test per place_order ha bisogno di un gateway di pagamento, un client SMS e un calcolatore delle tasse. Se collegassi quelli veri, ogni esecuzione del test addebiterebbe una carta e manderebbe un SMS a un numero reale. Un test unitario deve girare in pochi millisecondi, senza rete, quindi tutti e tre vanno sostituiti con qualcos’altro. Quel “qualcos’altro” si presenta in cinque forme — ognuna risolve un problema diverso — e trattarle come intercambiabili è il motivo per cui le discussioni “basta mockarlo” in code review girano in tondo. ...
Salvi un file, Prettier lo riformatta, ed ESLint segnala subito un errore sulla riga che Prettier ha appena toccato. Entrambi gli strumenti sono configurati, entrambi sono attivi, e invece di aiutarti si combattono a vicenda. I due strumenti fanno lavori diversi. Il problema è che hanno entrambi un’opinione su una cosa sola: come deve apparire il codice sulla pagina. Cosa controlla davvero ESLint ESLint analizza il codice in un albero di sintassi astratto e applica regole sulla sua struttura. Il suo contributo più utile sono le regole che individuano bug reali: una variabile mai definita, un return irraggiungibile dopo un altro return, un import rimasto inutilizzato dopo un refactoring, una chiave duplicata in un oggetto che sovrascrive la prima in silenzio. Sono controlli semantici: ESLint legge cosa fa il codice. ...
<.+> contro <b>bold</b> and <i>italic</i> non trova <b>. Trova l’intera stringa, dal primo < all’ultimo >. Non c’è nessun bug. È esattamente quello che un quantificatore greedy deve fare, ed è anche il bug più comune in assoluto quando “il regex matcha troppo”. Una volta capito cosa fa il motore mentre legge il pattern, questo bug e i suoi parenti smettono di essere misteriosi. Come un Motore Regex Legge il Pattern Un motore regex non confronta il pattern con la stringa come si confrontano due stringhe per uguaglianza. I motori che usi ogni giorno (re di Python, RegExp di JavaScript, PCRE, .NET, Java) sono regex-directed: scorrono il pattern da sinistra a destra, token per token, e per ogni token provano a consumare caratteri dalla stringa nella posizione attuale. Quando un token trova corrispondenza, il motore avanza sia il puntatore del pattern che quello della stringa. Quando un token fallisce, il motore fa backtracking: torna all’ultimo punto in cui aveva una scelta, come un quantificatore che poteva fermarsi prima o un ramo di un’alternanza non ancora provato, e prova l’altra opzione. ...
Perché any fa perdere il tipo che hai passato? Tipizza un parametro come any e TypeScript smette di controllare tutto ciò che esce dalla funzione: 1 2 3 4 5 6 function firstElement(arr: any[]): any { return arr[0]; } const n = firstElement([1, 2, 3]); n.toUpperCase(); // compila, va in crash a runtime Tu sai di aver passato un array di numeri. Il compilatore no, perché any gli dice di smettere di guardare. n torna come any, quindi chiamare un metodo di stringa su un numero compila senza problemi e lancia TypeError: n.toUpperCase is not a function quando viene eseguito. ...
Apri un file che non esiste in Python e open() lancia un FileNotFoundError che risale fuori dalla tua funzione. Fai la stessa cosa in Go e os.ReadFile ti restituisce un valore error accanto a uno slice di byte nil. Stesso fallimento, due forme di codice completamente diverse attorno ad esso. La differenza non è estetica. Decide se chi chiama la funzione può ignorare il fallimento per errore, e se il compilatore se ne accorge quando succede. ...
Un client bloccato in un retry loop senza backoff può generare, in un minuto, più carico sulla tua API di quanto ne generino insieme altri diecimila client. Visto da te non sembra un attacco: sembra un bug dalla loro parte, che diventa un incidente dalla tua. Un rate limiter blocca quel client prima che arrivi a quel punto. Cosa decide davvero un rate limiter? A ogni richiesta, il limiter si pone una sola domanda: questa chiave ha fatto troppe richieste nella finestra attuale? Tre scelte trasformano quella domanda in qualcosa che puoi implementare. ...
Un listener scroll su window può scattare centinaia di volte durante un singolo swipe. Se ad ogni evento esegui getBoundingClientRect() su tutte le card di un feed, bastano cinquanta immagini per inchiodare la pagina. La Intersection Observer API toglie quel controllo dal percorso dello scroll: registri quali elementi osservare e il browser ti avvisa quando la loro visibilità cambia davvero. Come funziona IntersectionObserver Un observer osserva uno o più elementi target rispetto a un root (di default il viewport) e invoca una callback ogni volta che un target supera una soglia di visibilità. ...
Apri un file salvato come UTF-8 in uno strumento che assume una codifica diversa e café diventa café. I byte sul disco non sono cambiati. È cambiata solo la regola usata per trasformarli di nuovo in caratteri, e le due regole non sono d’accordo su cosa significhi il byte 0xC3. La maggior parte dei bug da “caratteri strani” — nomi di file corrotti, moduli web illeggibili, emoji che fanno fallire un insert nel database, due stringhe identiche all’occhio ma diverse nel confronto — nasce dalla stessa confusione tra due cose distinte: Unicode e UTF-8. ...