[Guideline] Add do not divide by 0

[vapdrs]

Closes #131

[netlify]

✅ Deploy Preview for scrc-coding-guidelines ready!

Name	Link
🔨 Latest commit	538c49c
🔍 Latest deploy log	https://app.netlify.com/projects/scrc-coding-guidelines/deploys/684878933a2b380008656773
😎 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

[felix91gr]

Whether the program is or isn't dividing by zero is indeed Undecidable.

But whether the program is performing checked arithmetic or not is Decidable. So... perhaps this guideline should be changed to enforce checked arithmetic?

By which I mean: maybe it shouldn't be "Do not divide by 0". Maybe it should always be checked arithmetic.

Let's talk about it on Zulip!

[PLeVasseur]

Whether the program is or isn't dividing by zero is indeed Undecidable.

Hmm. Does that make this quite onerous to the engineer which must comply with this?

Perhaps it could be advisory to allow easy deviation.

Maybe it should always be checked arithmetic.

This might be the right choice for another guideline, perhaps required which would make every division use checked_div().

What do you think @vapdrs?

[felix91gr]

Indeed. It's even worse than that. Division by zero is Undefined Behavior, which is instant death for Safety Critical purposes :3

[PLeVasseur]

Good point -- let's call that out here @vapdrs.

[PLeVasseur]

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

[PLeVasseur]

Should we leave the example code blank then?

[PLeVasseur]

Good point -- let's call that out here @vapdrs.

[PLeVasseur]

Whether the program is or isn't dividing by zero is indeed Undecidable.

Hmm. Does that make this quite onerous to the engineer which must comply with this?

Perhaps it could be advisory to allow easy deviation.

Maybe it should always be checked arithmetic.

This might be the right choice for another guideline, perhaps required which would make every division use checked_div().

What do you think @vapdrs?