Built on Another

`abstract` on line 13 is a word you have met on four boards already. It says this file cannot be deployed as it stands. Something else has to inherit it, exactly the way it inherited `ERC20` on the same line, before any of this reaches a chain.

Both functions also carry `virtual`. So this file is a middle layer. It joined onto one contract on line 13, and on lines 19 and 34 it offers both of its own functions to whatever joins onto it next.

Read them the way you read nine signatures in week two. Line 19: the name `burn`, one parameter, a `uint256` called `value`. Then `public`, so a wallet can call it, then `virtual`, then no `returns` at all, so nothing comes back.

Line 34: the name `burnFrom`, two parameters, an address and a number, in that order. The same three words after the brackets. Four facts apiece for one line of reading, and neither body has been opened yet.

Line 20 is the whole of `burn`. One line: `_burn(_msgSender(), value);`. Three names sit in it. Ask the only question that matters about each one, and ask it in order. Where is this defined?

`value` is easy. It is the parameter on line 19, one line up, declared by the signature you just read. The other two are not in this file at all. Search all thirty eight lines and neither of them appears anywhere else.

Here is the move, and it is three steps. A name you cannot find in the file: read the contract line for what it inherits, then follow the import that names that. Line 13 says `ERC20`. Line 6 says `ERC20` comes from `../ERC20.sol`.

So `_burn` lives in that file, and you have read a function of that name before. In week two the Solmate version took a holder and an amount, was marked `internal`, and handed nothing back. Same name, same job, a different house.

`_msgSender` carries its own brackets, so it is not a value being handed over. It is a call, and whatever it answers with becomes the first argument to `_burn`. The inner brackets resolve first, the way they do in arithmetic.

And it is not declared in `ERC20.sol` either. It arrives from a file that `ERC20` itself joined onto. Two hops from the line you are reading, found by running the same three steps twice in a row.

The second function repeats the move. Line 35 calls `_spendAllowance` with the account, the caller and the value. Line 36 calls `_burn`, exactly as line 20 did, except that the first argument is `account` rather than whoever called.

`_spendAllowance` is the third name this file uses and never declares. Same question, same answer: it is not on this page, line 13 says what this contract joined onto, and line 6 says which file to open to find it.

Three lines in the whole contract do anything at all, and you have now traced every name in each of them. Line 20, line 35, line 36. Everything else in the file is a declaration, a comment, a blank line or a brace.

Tap each of the three and say, for every name in it, whether it was declared on this page or somewhere further up the chain.

Now read the comments, because in a file like this they are doing real work. Line 17 points at the parent's `_burn`. Line 27 points at that and at `allowance` as well. Each names a contract and a member inside it, in a notation a documentation tool understands.

That is the shape of a file built on another one. Its documentation is largely a set of directions to the places where the meaning actually lives, and lines 29 to 32 state plainly what a caller must already hold before line 34 will get anywhere.

Every line is lit. A licence, a pragma, one import, twenty three lines of documentation, a contract line carrying two words, two signatures, three lines of body and three closing braces. That is the file, complete, and it is the shortest one yet.

And you can now say where every name in it comes from, which you could not at step one. That is a narrower claim than saying what the file does, and the difference between those two is the last thing left to settle.

So here is the skill, and it is a reading skill rather than a writing one. When a name is not on the page, the contract line tells you what this file joined onto, and the imports tell you where that lives. Take it one hop at a time.

Now be exact about what this file alone settles and about what it quietly leaves for another file to answer.

Act three is contracts talking to contracts, and this was the quietest way that happens. No address held anywhere, nothing sent across, no answer waited for. One word on line 13, one import on line 6, and a file two hops away supplying most of the meaning.

Carry the trace with you. A name you do not know, then the contract line, then the import, then the same three steps again in the file you land in. Most real code is read exactly this way, one hop at a time.