Never mind that you’re introducing the possibility for bugs: the compiler would catch if you type the wrong symbol name, but not if you type 129 accidentally.
And anyone reading or maintaining that code now has several additional needless WTFs they’ll encounter in the course of making sense of it.
But more importantly, by giving it a name the code is more self-documenting. New and old programmers don't have to figure out why 128, or if 128 is right or not in this bit of code.
If you want a different display, they'd prefer you to rewrite it from scratch?
He's not primarily a programmer, but a computer engineer. It wasn't his first computer system, and may not even be his last. The mouse stays the same size, but the computers themselves have shrunk dramatically over the years. Maybe when he turns 90 he'll ship-in-a-bottle build a computer inside his favourite mouse?
Ha wouldn't be shocked. Apparently some mice already have ARM processors inside, why not take it a bit further.
Or they may never have thought about running on a different device. Why should I do the work to do it?
This was not done with the idea of portability, maintainability, or even good engineering practice.
It can't know that with a named constant.
(Same would be true for any value that's a power of 2. Usually a real speed up.)
For example, take a look at the display module [0] -- this 190-line program contains over 20 instances of constant "128", in lines like those:
What does this mean? See, there is only one display supported by this OS -- an 1024 x 768 monochrome one. Since this is monochrome, you only need one bit per pixel, and you can put 8 of them in the byte. If the pixels are sent out serially and lines follow each other in the buffer, then start of each line is (1024 / 8) = 128 bytes apart.But instead of writing something like "const LineStride = Width / 8", the code just hardcodes the value all over the place.
[0] https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Displ...