Challenge 1: Why Rename Avoids a Real Text-Matching Problem — Solution Walkthrough

Why plain find-and-replace would be risky here:

A plain text find-and-replace operates purely on matching characters
— it has no understanding of what "data" actually refers to in each
location. Searching for "data" and replacing it would also match the
unrelated comment and the string literal simply because they happen
to contain the identical text, incorrectly altering content that has
nothing to do with the variable being renamed.

Why Rename avoids this problem:

Per this chapter's own material, Rename operates on the IDE's actual
understanding of the code's structure — specifically which
declaration a given identifier refers to — rather than matching text
patterns. It updates only genuine references to that specific variable
declaration, correctly leaving the unrelated comment and string
literal completely untouched, since neither of them is actually a
reference to the variable being renamed at all.

Why this distinction matters practically:

Using find-and-replace here could silently corrupt a comment's own
meaning or change a string literal's actual displayed content — a bug
that might not be caught immediately, since the file would still
compile. Rename's structural awareness prevents this category of
mistake entirely, rather than requiring careful manual review of every
match afterward.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own Rename-vs-find-and-replace
distinction to a concrete scenario with a genuine name collision,
correctly explaining the mechanism (structural awareness vs. text
matching) rather than just asserting Rename is "smarter."