RBoy: A Gameboy Emulator in Rust
github.com
github.com
It’s soulless to make all code look like bland corporate cardboard. It appeals to our OCD perfectionist tendencies but in my experience provides very little real value. Software is like writing. It can’t help but express how the author thinks about their code. These tools try to iron that personality out - and for what reason? Who cares in javascript if some files use semicolons and some don’t? Who cares if my where clause is on the same line or the next? The compiler doesn’t care, and neither do I.
(I will grant that all files in a project should have consistent white space, but you don’t need cargo fmt for that.)
The formatter has no opinion. It follows rules. It doesn't work perfectly everywhere. It works enough. I would argue caring about exact bespoke spacing of all code is the perfectionism you mention.
The IDE should apply user formatting preferences upon reading in the file, and apply the std formatting while writing it (with the aim of having diffs work well). That would make good use of auto-formatters.
It's in precisely zero ways like communism and that really doesn't help the clarity of the rest of your post.
A single-author novel can have personality. A 100-author 30-volume encyclopedia, less so. Whenever I set up a new single-author codebase, I set up as little automatic code formatting as I please. For collaborating with other developers, I will enforce as much as possible as early as possible.
Perhaps you do not remember reading through 10k lines of PHP source that has been formatted by someone who has entirely different ideas about what good formatting is than almost everyone else on earth (or perhaps you never have!), but if you did remember the advantage of a single formatting standard that is ubiquitous would be very clear.
1. it makes it just plain easier to read others code. it's hard enough to have to grasp the logic behind everything, if they have wildly different formatting on top of that it gets substantially worse (incidentally, this was given as one of the reasons why go was such a success in the open source world).
2. i've been able to get a couple of archaic linter rules dropped, i.e. the brackets around single statement conditionals.
// for this reason brackets were mandatory
if (a == b)
doSomething();
doSomethingElse();
https://github.com/mvdnes/rboy/blob/9f6b3bc47311ba687326bfff...
This process of matching on opcode and doing a marginally different version of the same basic few operations on one of a set of registers is something that is _much_ easier to do when you're able to see all the opcodes and activities in a densely packed set of lines like this.
(The start of the opcodes that I linked are not the best example of this, but they get more regular the further down the file you go. See https://github.com/mvdnes/rboy/blob/9f6b3bc47311ba687326bfff... )
Beyond knowing that they exist, I haven't explored macros in rust, but I'm curious if they could be of help here. But using cargo fmt, and spreading each of those lines into 3-10 lines would be awful, and would definitely lead to me making mistakes and not noticing typos.
[1] https://git.musuka.dev/paoda/gb/src/branch/main/src/instruct...
Declarative macros might be useful here, at least to cut down on the mindless repetition somewhat. These are fairly hygienic (a technical term meaning that if variable names in the macro are the same as variable names in the code using the macro, this doesn't make them the same variable) and so pretty safe to use but limited.
Procedural macros can do almost anything, they're Rust code that runs inside the compiler when your program is compiled, so e.g. they can have arbitrarily complicated behaviour including completely breaking compilation. You could definitely fix this with proc macros, but, that's not necessarily a good idea.
Where do I find games to test this out?
You could probably do this with mrustc.
But then I am biased, having the Z80 opcodes burned in my brain due to the Speccy days.