fixed-delay-audit

To find fixed-delay anti-patterns, audit your source code for sleep, setTimeout, time.sleep, or Task.Delay constructs. The audit identifies locations where time-based waits lack exit conditions and suggests event-driven replacements.

A fixed-delay anti-pattern occurs when sleeps, delays, or time-based waits lack exit conditions. This happens when code pauses execution for a set duration instead of waiting for a specific resource state change or event trigger.

To replace time.sleep or setTimeout, implement condition-based polling, event-driven waits, callbacks, or synchronization primitives. An audit reports each occurrence with actionable refactor suggestions for adopting these event-driven alternatives.

Yes, the fixed-delay audit works across multiple languages. It identifies time-based wait constructs such as sleep, delay, time.sleep, setTimeout, and Task.Delay found throughout your codebase regardless of the specific language.

The best way to refactor a fixed timeout waiting for a resource is to replace it with condition-based polling or event-driven waits. This ensures the code reacts immediately when the state changes rather than waiting an arbitrary duration.

You should not use a fixed delay or sleep when waiting for a resource or state change. Without an exit condition, time-based waits cause unnecessary latency or failure; use synchronization primitives or event-driven callbacks instead.