The existing rule forbids breaking up view bodies with computed
properties or methods — even with `@ViewBuilder` — and requires
extraction into separate `View` structs in their own files. The
reasoning is sound: SwiftUI can diff and skip struct-based subviews
when inputs haven't changed, whereas a computed property on the parent
re-runs on every `body` invalidation.
Applied mechanically, however, the rule also flags private, single-use
helpers inside small, single-responsibility views — helpers whose only
purpose is to give a descriptive name to a tightly-coupled section of
`body` in place of an explanatory comment. For that specific case the
performance argument is a wash: a computed property and the equivalent
inlined code both re-run on every `body` invalidation, so struct
extraction buys nothing but file-sprawl there.
This change adds a single bullet right after the rule:
Do not rewrite private helpers that exist only for structural
readability, belong to the same concern as `body` (not a distinct
responsibility), and would fit in `body` at an acceptable length if
inlined.
All three criteria — private + same concern + not-excessive-when-
inlined — must hold for the exception to apply. Otherwise the main
rule stands: decomposition for performance, distinct responsibility,
reuse, or own state still means extracting into separate `View`
structs in their own files.
The duplicate reminder at the bottom of the file is kept (the repeat
is emphasis), with one short addition to its aside so a reader
scanning only the bottom half of the file still sees that the
exception applies there too.
The "flag excessively long body" bullet is untouched; it stays
internally consistent with the exception's "acceptable length if
inlined" clause.
Paul Hudson