[Guideline] Add do not divide by 0

[vapdrs]

Closes #131

[netlify]

✅ Deploy Preview for scrc-coding-guidelines ready!

Name	Link
🔨 Latest commit	1076b36
🔍 Latest deploy log	https://app.netlify.com/projects/scrc-coding-guidelines/deploys/689f3bf0b185860008a6b560
😎 Deploy Preview	https://deploy-preview-132--scrc-coding-guidelines.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[felix91gr]

Hi @vapdrs! I have already sent you a message in Zulip, but here seems like a better place to do so.

I come to add a couple of things to this guideline :)

1. There is a Clippy lint (actually a couple of lints, but this one is the main one) that one can enable to catch these kinds of operations: arithmetic_side_effects. This is a fairly general lint that, if enabled using warn or deny, lints any arithmetic expression that either overflows or panics (division and modulo by 0 will do the latter).

2. The aforementioned lint should indicate to the user that there are arithmetic operations in the stdlib that can be used to guarantee well-defined behavior. In the case of division by zero, it will suggest using operations such as checked_div, which outputs an Option<T> that the user must then handle properly. The None result indicates overflow, underflow or division by zero.

There are other such operations for division, such as checked_div_rem_euclid for when a remainder is desired.

And for other arithmetic operations, there are quite a few functions one can use to avoid Undefined Behavior: https://doc.rust-lang.org/std/?search=checked

3. A complement to the two resources above is the NonZero type. One uses NonZero to enclose a value that is known, by construction, to not equal zero.

This combines rather well with Option, as in Option<NonZero>, since the compiler can do some memory layout optimization due to the fact that the value being enclosed by NonZero has one bit-pattern that is known to not be possible (the 000...000 pattern)

I will review the PR shortly :3

[PLeVasseur]

Thanks for opening this up @vapdrs! Could you check the comments I left?

[PLeVasseur]

Thanks for pulling this together @vapdrs! I left a few suggestions based on how conf.py works together with Sphinx Needs as well as a way to use our coding guidelines extension. Could you take a look?

[PLeVasseur]

I'm realizing now that perhaps the issue template having uppercase options may have been to blame for them being made uppercase in this PR. Was that the case for you @vapdrs?

I've opened #143 to fix this 👍

[felix91gr]

I haven't been able to give the examples a proper re-read just yet. Tis' been a low-battery week. Will do my best to have final feedback on those (also regarding #136)

[felix91gr]

@vapdrs the build is failing, but to no fault of your own. It's just something that happens every now and then when the FLS and our FLS lockfile diverge.

There should be a way to automate this for most PRs, but for right now... let's see. I'd usually ask you to run the command that fixes this, but for traceability purposes we actually want those changes to be their own Pull Requests.

Lemme fix this in main, and that should enable your changes to build again :)

[felix91gr]

@vapdrs thanks! I was gonna ping you here as well but you just did the thing ❤️

[felix91gr]

I think these are the last few touches I'd add.

[felix91gr]

This one is done, as far as I'm concerned. Much like for #136, thank you @vapdrs for your work and for your patience ^^

I'll add it to the merge queue right away :)

[PLeVasseur]

Thanks for seeing this through @vapdrs!