using braces for entry_point! saves 1 byte

[bingmatv]

The 3rd edition of the blog https://github.com/phil-opp/blog_os/blob/edition-3/blog/content/edition-3/posts/02-booting/index.md looks like

bootloader_api::entry_point!(kernel_main);

Using braces like

bootloader_api::entry_point!{kernel_main}

Doesn't need the lasting semicolon so it saves 1 byte.

[bjorn3]

Using braces is less clear IMO. I don't see any reason why you would want to save a single byte in the source code.

[bingmatv]

The earliest version of Super Mario has only 40KB, I suggest to cost more resource only when necessary, e.g., movies and security. Movies may require high definition, for security like Post-Quantum Cryptography it may require more memory since quantum computers break RSA and ECC, and CPU vulnerability mitigations like Meltdown and Spectre mitigations. If not necessary like movies and security, IMO it should use less resource like 40KB Super Mario @bjorn3

[bjorn3]

I don't see how the size of a compiled game is related to what the expected size of source code should be. Your suggested change has absolutely no effect on the size of the compiled kernel and if anything adding a commit to change this would increase the size of the blog_os repo.

[Freax13]

The different bracket styles are usually used for different things: Normal parenthesis are used for function-call-like macros, curly braces are usually used when the body contains decl- or statements-like content, and brackets are used for array-like things. We should stick to those conventions: In this case, the macro body doesn't contain decl- or statement-like tokens and doesn't have anything to do with collections of any sort. Considering that changing this would only save a single byte,IMO we should prioritize clarity.

[phil-opp]

As bjorn3 noted, the compiled binaries are not affected by brace styles, variable names, newlines, etc. For distributing the source files, you can compress them (e.g. zip them). So there is no real advantage of saving a few bytes in the source file.

Because of this, we can freely optimize the source file for readability, as Freax13 mentioned.