Compare Two Script Versions with a Diff

One extra equals sign can change who qualifies for a reward. A hundred reindented lines may change nothing. A diff helps you find both, but you still have to explain what each edit does.

We’ll compare two small functions written for this walkthrough. The result table follows from the code; it isn’t a test report about a catalog release.

Save the comparison objects first

Save both versions before doing anything else. Names such as claim-old.luau and claim-new.luau are fine for this example. For a real release, keep the source address and revision identifier too.

Be clear about what you saved. An unchanged loader doesn’t mean its remote program stayed unchanged. Compare the actual layer your report concerns.

Version A has a strict boundary

local function canClaim(points, minimum)
    return points > minimum
end

print(canClaim(10, 10))

The operator is strictly greater than. With 10 points and a threshold of 10, this should return false. Version A also assumes the arguments can be compared; it doesn’t check their types.

The name minimum makes an inclusive rule sound plausible. Read the operator anyway. A good name can suggest intent, but it can’t change the calculation.

Version B changes two independent rules

local function canClaim(points, minimum)
    if type(points) ~= "number" or type(minimum) ~= "number" then
        return false
    end
    return points >= minimum
end

print(canClaim(10, 10))

Version B makes two edits: it rejects non-number arguments and includes equality. Review those decisions separately, because a caller may care about either one.

The new guard doesn’t enforce whole numbers or every numeric-domain rule a points system might need. If those requirements matter, make them a separate, deliberate change.

Read the unified diff

 local function canClaim(points, minimum)
-    return points > minimum
+    if type(points) ~= "number" or type(minimum) ~= "number" then
+        return false
+    end
+    return points >= minimum
 end

Read minus lines as removed text, plus lines as additions and unmarked lines as context. The diff markers aren’t part of the Luau program.

Look at the callers as well. Some may expect an error for bad input; others may already adjust the threshold before calling. A locally sensible change can still surprise code around it.

Turn each change into an example

Write down the rule you want: does equality qualify, and should a numeric string be rejected or converted? The comparison exposes those decisions, but it can’t choose them for the project.

Separate formatting from semantic changes

Use a viewer’s whitespace options when indentation overwhelms the change you need to review. Be careful with spaces inside strings, though; those can affect messages or data.

If you control the edit, separate formatting from behavior where practical. The next reader shouldn’t have to find one changed operator among a page of reindented lines.

A move can appear as a deletion followed by an addition. Compare the body before calling it new behavior, then check whether the new scope or initialization order matters.

Look beyond the main function

For larger files, check imports, resource addresses, settings, event connections and writes. The interface may barely change while a dependency or the timing of work changes underneath.

A new remote address deserves its own note. A diff makes the changed destination visible; it doesn’t establish the authorship or behavior of unread material there.

Write a review that names the effect

“Version B accepts equality and returns false for non-number arguments. The 10-point boundary case changes from false to true. Whole-number and range rules are unchanged.”

That’s enough for this review. The note identifies two effects and a boundary case, so another reader knows exactly what to examine next.

References and next steps

• Git diff documentation — comparison formats and options.
• Luau syntax — operators and control flow.
• Source information guide — identify what file you are comparing.
• Record a changed behavior before proposing a cause.