The One Canonical

Function first: a comment written in a format other programs can read, sitting directly above the thing it describes. The name: NatSpec. It opens with `/**` or with `///`, and close to half of this file is made of it.

Two styles here. Line 81 is a single line saying `@inheritdoc IERC20`, meaning the words are in the interface, go read them there. Lines 91 to 98 spell it all out. Skimming past both is a skill: find the first line that is not a comment.

Here is `transfer`, the function a wallet actually calls, complete. Line 100 asks who is calling. Line 101 hands three values to something named `_transfer`. Line 102 returns true because the standard says it must. Line 103 closes it. That is the entire body.

Nothing here touches a balance. The public function is a doorway: name the caller, pass the work down, report success. The name it passes the work to begins with an underscore, and that underscore is a convention you are about to see everywhere.

Read `approve` on line 120 and `transferFrom` on line 142 and you find the shape again. Resolve the caller, hand the work to an internal name, return true. `transferFrom` does it twice: line 144 spends the allowance, line 145 moves the tokens.

Three public writers, and not one of them writes anything. Two of the names they hand down to sit further into the file than this board reaches. So the question is why anyone would build a file this way at all.

So open `_transfer` on line 159. It is `internal`, and the work it does is two checks: neither side of the move may be the zero address. Then line 166 hands everything down again, to a name called `_update`.

Read line 157 before you go. It says in plain words that this function is not virtual and that `_update` is what an inheriting contract should replace instead. The file is telling you, in a comment, where its own hinges are.

Three functions call `_update`, and no other line in this file writes a balance or the supply. That is the arrangement the whole descent was building toward: one function where the numbers actually move, and every path funnelled into it.

Twenty nine lines, on 176 to 204, and four of them are writes. Tap each one.

Look at what the two `if` statements on lines 177 and 191 are testing. Not a flag, not a mode, not a parameter added for the purpose. Whether one side of the move is the zero address. That single test is what lets `_update` do three different jobs.

And the two functions below prove it. `_mint` on line 214 calls `_update` with a zero sender. `_burn` on line 229 calls it with a zero receiver. Four lines each, a guard and a call, and no arithmetic of their own anywhere.

Every refusal in this file is a custom error, and every one of them carries values. Line 183 reverts with the account, the balance it actually held, and the amount that was asked for. Whatever catches that gets three numbers rather than a sentence.

The names arrived from outside. `ERC20InsufficientBalance`, `ERC20InvalidSender`, `ERC20InvalidReceiver`: all three are declared in the file imported on line 6, which is why line 29 lists `IERC20Errors` among its four parents.

All nine public functions carry `virtual`. So does `_update` on line 176. `_transfer`, `_mint` and `_burn` do not, and above each of those three sits a comment, on lines 157, 212 and 227, saying to override `_update` instead.

That is a file telling you how it expects to be edited. Replace `_update` and every operation changes at once, because everything funnels through it. Replace `_transfer` and you would have caught two paths out of three.

The last board, all three hundred and five lines. Function first: two functions in one contract sharing a name, told apart by what they take. The name: overloading. Line 251 takes three arguments, line 273 takes four, and the compiler picks between them by counting.

The three argument one has a single line of body. It calls the four argument one, passing `true`. The four argument version does the real work on line 280, and line 281 decides whether an announcement goes out. The same split you have read all lesson.

Line 144 sent you here. `_spendAllowance` reads the current allowance on line 295, then line 296 asks whether it is below `type(uint256).max`. If it is not below, the function does nothing whatsoever and the allowance stays exactly where it was.

An allowance set to the largest number there is never goes down. Lines 113 and 114 said so in words near the top of the file, and here it is in code: one comparison, and a value starts behaving like a setting.

Back to the top, and read the ladder in one go. A wallet calls line 99. Line 101 goes down to `_transfer` on 159. Line 166 goes down again to `_update` on 176. Line 203 announces what happened, and the call unwinds back out.

Now be exact about how far that ladder goes, and where it stops.

Two ERC20s now, read end to end, doing identical work. The difference was never the standard. Solmate writes each operation once and keeps the file short. This one splits every operation in two and funnels the halves into `_update`.

Neither is the right answer. They are two answers to the question of where a change should be made, and you can now open either file and say which one it picked, from its signatures and its own comments alone.