You are an expert software engineer. Your task is to analysis the following unified code diff and its code changes. Your objective is to analyze each file for the following error and warning codes (as defined by their descriptors).
You should provide a per file analysis working with the following common problem areas:
Definition: A function exceeding 200 lines of code is considered overly large and should be refactored into smaller, cohesive units. Example:
// Bad
function processAll() {
// 200+ lines of mixed parsing, validation, IO, and reporting
}// Good
function processAll() {
const input = parseInput();
const validated = validate(input);
const results = compute(validated);
return writeReport(results);
}Definition: A function over 100 lines and up to 200 lines is considered moderately large. Recommend extraction of logical sections. Example:
// Bad
function buildDashboard() {
// 150 lines intermixing queries, transforms, and rendering
}// Good
function buildDashboard() {
const raw = queryData();
const viewModel = toViewModel(raw);
return renderDashboard(viewModel);
}Definition: When renaming a class or function, all references, imports, and exports must be updated consistently. Example:
// Bad
const fetchUserProfile = require('./user'); // new name
router.get('/me', async (req, res) =>
res.json(await getUserProfile(req.user.id)) // still old name
);// Good
const fetchUserProfile = require('./user')
router.get('/me', async (req, res) =>
res.json(await fetchUserProfile(req.user.id)) // consistent rename
);Definition: Avoid synchronous fs methods (fs.readFileSync, etc.) in server/runtime code as they block the event loop. Allowed only in CLI or startup code. Example:
// Bad
const txt = fs.readFileSync(path, 'utf8');// Good
const txt = await fs.promises.readFile(path, 'utf8');Definition: Flag await used inside forEach or other non-awaiting higher-order functions, which never propagate the awaited promise. Example:
// Bad
items.forEach(async (x) => {
await save(x); // caller never waits
});// Good
for (const x of items) {
await save(x);
}
// Or
await Promise.all(items.map((x) => save(x)));Definition: Axios throws on non-2xx responses; code must anticipate errors with try/catch or equivalent handling. Example:
// Bad
const res = await axios.get(url);// Good
try {
const res = await axios.get(url, { timeout: 5000 });
return res.data;
} catch (err) {
log.warn({ url, status: err.response?.status }, 'HTTP failed');
throw err;
}Definition: Functions with ≥ 4 parameters are difficult to extend and understand. Suggest using an options object. Example:
// Bad
function createUser(name, email, role, isActive, locale) {}// Good
function createUser({ name, email, role, isActive, locale }) {}Definition: Timers and intervals should be cleared with clearTimeout/clearInterval to avoid leaks. Example:
// Bad
const id = setInterval(tick, 1000);// Good
const id = setInterval(tick, 1000);
onShutdown(() => clearInterval(id));Definition: Event listeners attached with emitter.on in non-init paths can leak if not cleaned up. Prefer once or off. Example:
// Bad
app.get('/stream', (req, res) => {
emitter.on('data', (d) => res.write(d));
});// Good
app.get('/stream', (req, res) => {
const onData = (d) => res.write(d);
emitter.on('data', onData);
req.on('close', () => emitter.off('data', onData));
});Definition: Promises must eventually resolve or reject; never leave them pending indefinitely. Example:
// Bad
function waitForever() {
return new Promise(() => setTimeout(() => {}, 1000)); // no resolve/reject
}// Good
function delay(ms) {
return new Promise((resolve) => setTimeout(resolve, ms));
}Definition: Module-scope objects must not grow without bounds. Use LRU/TTL or explicit cleanup. Example:
// Bad
const cache = new Map(); // grows forever// Good
import LRU from 'lru-cache';
const cache = new LRU({ max: 5000, ttl: 60_000 });Definition: Streams, sockets, watchers, and cursors must be closed/destroyed in finally/teardown blocks. Example:
// Bad
const cursor = db.find(query);// Good
const cursor = db.find(query);
try {
// use cursor
} finally {
await cursor.close();
}Definition: Self-scheduling loops (recursive setTimeout) require a stop/abort signal to prevent leaks. Example:
// Bad
function tick() { doWork(); setTimeout(tick, 1000); }
tick();// Good
function start(signal) {
const run = () => {
if (!signal.aborted) {
doWork();
setTimeout(run, 1000);
}
};
run();
}Definition: Buffer.prototype.slice/subarray keeps reference to large parents; copy instead if long-lived. Example:
// Bad
const header = bigBuffer.slice(0, 64); // keeps entire buffer in memory// Good
const header = Buffer.from(bigBuffer.subarray(0, 64));Definition: Increasing global MaxListeners masks leaks rather than fixing them. Example:
// Bad
require('events').defaultMaxListeners = 1000;// Good
// Remove duplicate listeners or restructure emitter usage insteadDefinition: Using Map.set with non-primitive keys in request paths can leak memory. Prefer WeakMap or explicit cleanup. Example:
// Bad
const cache = new Map();
cache.set(req, result); // req objects persist forever// Good
const cache = new WeakMap();
cache.set(req, result); // GC cleans up with reqYou should output your analysis according to these rules for each violation in each file:
- Start with the file path
- Choose an ERR or WARN code from the above list matching the analyzed code problem
- ERR_LARGE_FN, WARN_LARGE_FN should include the function name and how many lines the fn is
- WARN_LONG_PARAMETER_LIST should indicate the function, the current parameters and how many parameters are there, and ideally should ideate any helpful state or options object to use instead
- WARN_MEMLEAK_MODULE_SCOPE_OBJECTS should indicate the object or variable name and a recommended code replacement
- In general the context of the problematic code should be shown and a proposed fix should be made using a unified diff format
- You should ensure that you close all backticks and triple backticks between each file analysis and violation
- You should enter the file path, the violation, a descrition of the violation followed by a code block of the unified diff
- After each unified diff you can offer an alternate Proposed modification: block to describe your proposed diff
- Only the unified diff should be in a code block
- Output a unified diff
- Use 3+ lines of context per hunk.
- You must start all unified diff blocks using
and terminate using - You must escape all backticks in a unified diff with a backslash
- Preserve file modes/renames if relevant.
- If creating a new file, use /dev/null in the --- header.
- A patch that applies cleanly with
git apply --3way --checkcovering all changes, using this exact form:
Example analysis remark:
Description: Context: You produced a const variable declaration without a variable and this will throw a syntax error
--- a/<path>
+++ b/<path>
@@ -<start>,<len> +<start>,<len> @@
<context/removed lines prefixed with ' ' or '-'>
<added lines prefixed with '+'>
Proposed modification: add a resolve parameter to promise and call after functions async code is run
Here are the code changes to review:
Here are the original source files: