Sliding Window
debt(d7/e3/b3/t5)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints state automated=no and the code_pattern is a nested loop over sequential data. Blackfire (the listed tool) is a profiler that can surface O(n²) performance regressions at runtime, but it won't flag 'this should be a sliding window' statically — a developer must recognise the pattern through code review or notice the slowdown under load. No static linter rule catches this automatically.
Closest to 'simple parameterised fix' (e3). The quick_fix describes replacing a brute-force nested loop with the two-pointer expand/shrink pattern. This is more than a one-line swap (you must restructure the loop logic, maintain running state, and handle boundary conditions) but is typically contained within a single function or component — not a cross-cutting refactor.
Closest to 'localised tax' (b3). The choice to use or misuse sliding window is scoped to individual algorithmic functions handling arrays or strings. The applies_to covers web and cli contexts broadly, but the pattern itself is self-contained — a wrong implementation in one function doesn't impose structural weight on the rest of the codebase.
Closest to 'notable trap' (t5). The misconception field identifies that developers wrongly believe sliding window only applies to arrays, missing strings and other sequential structures. The common_mistakes add further documented gotchas: fixed vs variable window confusion, forgetting to update state on left-pointer removal, and off-by-one errors. These are well-known but non-obvious pitfalls that most developers encounter and eventually learn.
Also Known As
TL;DR
Explanation
Instead of recomputing a result from scratch for each position (O(n²) or worse), the sliding window maintains running state — adding the new element entering the window and removing the one leaving. Fixed-size windows compute moving averages or max sums. Variable-size windows find the shortest/longest subarray meeting a constraint. Common uses: maximum sum subarray, longest substring without repeating characters, minimum window substring.
Diagram
flowchart LR
ARR[Array: 1 3 5 2 4 6 1<br/>Find max sum of 3 elements]
subgraph Naive_O_n_k
N1[Check 1,3,5 = 9]
N2[Check 3,5,2 = 10]
N3[Check 5,2,4 = 11]
N1 --> N2 --> N3
end
subgraph SlidingWindow_O_n
W1[Window 1,3,5 = 9]
W2[Slide: remove 1 add 2<br/>9-1+2 = 10]
W3[Slide: remove 3 add 4<br/>10-3+4 = 11]
W1 --> W2 --> W3
end
RESULT[Max sum = 11]
style W1 fill:#1f6feb,color:#fff
style W3 fill:#238636,color:#fff
style RESULT fill:#238636,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Not expanding/shrinking the window based on the constraint — moving a fixed step instead.
- Forgetting to update the running state when removing the leftmost element.
- Using a fixed-size window when a variable-size window is needed (or vice versa).
- Off-by-one errors in window boundary calculations.
Code Examples
// O(n²) — recompute sum from scratch for each window:
function maxSumSubarray(array $arr, int $k): int {
$max = 0;
for ($i = 0; $i <= count($arr) - $k; $i++) {
$sum = array_sum(array_slice($arr, $i, $k)); // O(k) per position
$max = max($max, $sum);
}
return $max;
}// O(n) — maintain running window sum:
function maxSumSubarray(array $arr, int $k): int {
$windowSum = array_sum(array_slice($arr, 0, $k));
$max = $windowSum;
for ($i = $k; $i < count($arr); $i++) {
$windowSum += $arr[$i] - $arr[$i - $k]; // Slide: add new, remove old
$max = max($max, $windowSum);
}
return $max;
}