{"id":4786,"date":"2026-05-11T22:58:58","date_gmt":"2026-05-11T17:28:58","guid":{"rendered":"https:\/\/itsupportwale.com\/blog\/10-essential-javascript-best-practices-for-cleaner-code\/"},"modified":"2026-05-11T22:58:58","modified_gmt":"2026-05-11T17:28:58","slug":"10-essential-javascript-best-practices-for-cleaner-code","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/10-essential-javascript-best-practices-for-cleaner-code\/","title":{"rendered":"10 Essential JavaScript Best Practices for Cleaner Code"},"content":{"rendered":"

\/\/ This is the specific block of “clever” garbage that took down the
\n\/\/ payment gateway at 3:00 AM on a Sunday.
\n\/\/ Node v20.11.1 – Production Environment<\/p>\n

var requestCache = {}; \/\/ Global scope leak<\/p>\n

app.use((req, res, next) => {
\n var correlationId = req.headers[‘x-correlation-id’] || Math.random().toString();<\/p>\n

\/\/ "Clever" optimization to avoid DB lookups\nif (requestCache[correlationId]) {\n    res.send(requestCache[correlationId].payload);\n    \/\/ Missing return statement. Execution continues.\n}\n\ndb.query('SELECT * FROM transactions WHERE id = ?', [req.body.id], (err, result) => {\n    if (err) {\n        \/\/ No error handling. Just logging to a global variable.\n        lastError = err; \n    }\n\n    new Promise((resolve, reject) => {\n        \/\/ Wrapping a callback in a promise manually for no reason\n        const processed = transformData(result);\n\n        \/\/ Mutating a global object without a cleanup strategy\n        requestCache[correlationId] = {\n            payload: processed,\n            timestamp: Date.now()\n        };\n\n        resolve(processed);\n    }).then(data => {\n        res.status(200).json(data);\n    });\n\n    \/\/ Unhandled promise rejection if transformData throws\n});\n<\/code><\/pre>\n
});<\/p>\n
## The Global Scope is a Graveyard\n\nLook at the first line. `var requestCache = {};`. This is not just a variable; it is a memory leak masquerading as a feature. In a Node.js environment, the module-level scope persists for the lifetime of the process. By attaching a growing object to this scope, you have effectively created a black hole for the heap. \n\nEvery single request that hit the middleware added a key to this object. Because the "clever" developer who wrote this didn't implement a Time-To-Live (TTL) or a Least Recently Used (LRU) eviction policy, the object grew until the V8 engine hit its default heap limit. \n\nHere is the reality: the garbage collector (GC) cannot reclaim memory that is still reachable. Since `requestCache` is in the global module scope, every entry inside it is considered "reachable." Even after the HTTP response was sent, the data persisted. This isn't just bad code; it's a fundamental misunderstanding of how the V8 heap is structured. \n\nWhen we ran the post-mortem diagnostics, the heap snapshot was damning.\n\n```text\n# node --inspect-brk index.js\n# In Chrome DevTools:\n# Snapshot 1: 24MB (Startup)\n# Snapshot 2: 840MB (After 10,000 requests)\n# Snapshot 3: 1.4GB (FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory)\n\n(node:45201) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues.\n<--- Last few GCs --->\n[45201:0x6000000]    15201 ms: Mark-sweep 1380.5 (1420.2) -> 1380.1 (1420.2) MB, 420.1 \/ 0.0 ms  (average mu = 0.152, current mu = 0.002) allocation failure; scavenge might not succeed\n<\/code><\/pre>\n
The V8 engine spent 420ms trying to perform a Mark-sweep on a heap that was 99% full of un-evictable garbage. This is why following javascript best practices isn’t optional; it’s a matter of keeping the server alive. A simple Map<\/code> with a size check or, better yet, an external store like Redis, would have prevented this. But no, we had to be “clever.”<\/p>\n
\n
Table of Contents<\/p>\n