Temporary Field
debt(d7/e5/b5/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints list phpstan and phpmd, but the automated flag is explicitly 'no' — these tools may flag null properties but cannot reliably detect the semantic pattern of a field only valid in one code path. The code_pattern description ('only set in one method and null everywhere else') requires contextual human judgment to identify, making this a code-review-level finding rather than a reliable automated catch.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix calls for moving fields into dedicated method parameters or a state-specific object. This is more than a one-line swap: it requires identifying all usages of the temporary field across the class and callers, creating or repurposing a value object or parameter, and updating call sites. It's a meaningful refactor within one or a few components, not a simple line-level replacement.
Closest to 'persistent productivity tax' (b5). Temporary fields apply across web, cli, and queue-worker contexts. Every maintainer who touches the class must reason about when the field is valid, adding cognitive overhead to reads, writes, and tests. The common mistake of adding null checks everywhere instead of eliminating the pattern compounds the burden over time. It doesn't define the system's shape, but it persistently slows down work on the affected class and its consumers.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field explicitly states that developers treat a sometimes-null field as 'just an implementation detail,' failing to recognise it signals a missing class. The common mistakes confirm that null-initialisation actively hides the pattern, and that developers typically respond by adding null checks (making it worse) rather than eliminating the temporary nature. This contradicts standard OOP expectations that an object's fields are always in a valid, meaningful state.
Also Known As
TL;DR
Explanation
Temporary Field is a smell where an instance variable is only populated during part of the object's lifecycle — set before a complex operation and ignored at all other times. Readers must understand when the field is valid and when it isn't, adding cognitive load. The refactoring is usually Extract Class: move the temporary fields and the methods that use them into a dedicated parameter object or method object, making the state explicit and scoped.
Common Misconception
Why It Matters
Common Mistakes
- Setting instance properties only inside specific methods and using them elsewhere without null checks.
- Using $this->result as a temporary accumulator in a method instead of a local variable or return value.
- Not noticing temporary fields because they are null-initialised — the null hides the pattern.
- Fixing temporary fields by adding null checks everywhere rather than eliminating the temporary nature.
Code Examples
// Field only meaningful during one operation — confuses readers
class OrderProcessor {
private ?array $currentItems = null; // only set during process()
private ?float $subtotal = null; // only meaningful mid-calculation
public function process(Order $order): void {
$this->currentItems = $order->items;
$this->subtotal = $this->calculateSubtotal();
// ...
$this->currentItems = null; // reset when done
}
}// Move temporary fields to local variables or a parameter object
class OrderProcessor {
public function process(Order $order): Invoice {
$items = $order->items; // local — scope is clear
$subtotal = $this->calculateSubtotal($items);
return $this->buildInvoice($items, $subtotal);
}
}