Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apply some of clippy's suggestions #1

Merged
merged 9 commits into from
Oct 20, 2023

Conversation

backwardspy
Copy link
Contributor

each commit is a discrete change, and i've tried to justify each one in the commit message body.

there are a few further changes that i considered but didn't tackle:

  • finding a type safe alternative to your unsafe block in from_time
  • removing other uses of .unwrap()
  • package restructuring

these could be larger and more opinionated changes so i left them out.

backwardspy and others added 9 commits October 20, 2023 12:40
this matches the style to rust's standard library docs

suggested by clippy's `doc_markdown` lint:
https://rust-lang.github.io/rust-clippy/master/index.html#/doc_markdown
these functions have no side effects, so calling them and discarding
the returned value is usually a mistake. this annotation helps the
compiler warn us in these cases:

```
OfficeHours::new(Clock::NineAm, Clock::FivePm);
// warning: unused return value of `OfficeHours::new` that must be used
// help: use `let _ = ...` to ignore the resulting value
```

suggested by clippy's `must_use_candidate` lint:
https://rust-lang.github.io/rust-clippy/master/index.html#/must_use_candidate
implementing it this way still allows the previous usage:
`for hour in office_hours.into_iter() { ... }`
however it now also allows the following to work:
`for hour in &office_hours { ... }`

this is an idiomatic change for convenience more than anything else.

suggested by clippy's `iter_without_into_iter` lint:
https://rust-lang.github.io/rust-clippy/master/index.html#/iter_without_into_iter
given that the rest of the code lives in `lib.rs`, it seems of marginal
benefit to have the error type live away from its usage.

looking at other popular crates, it seems conventional to keep the error
next to the other types related to it, for example serde has several
error types that live near the code that raises them:
https://docs.rs/serde/latest/serde/?search=error

suggested by clippy's `module_name_repetitions` lint:
https://rust-lang.github.io/rust-clippy/master/index.html#/module_name_repetitions
we're gonna have to take this... offline
you can use `Self` in impl blocks to refer to the type the impl belongs
to. the main benefit in my opinion is the ability to rename or move the
impl around later without having to update all the methods.

suggested by clippy's `use_self ` lint:
https://rust-lang.github.io/rust-clippy/master/index.html#/use_self
this just enables the use of the function inside other const contexts.
one potential caveat to consider is if you ever need to make this
method non-const in future, it's a breaking change.
that seems unlikely in this case, but it's worth bearing in mind.

suggested by clippy's `missing_const_for_fn` lint:
https://rust-lang.github.io/rust-clippy/master/index.html#/missing_const_for_fn
@sgoudham sgoudham merged commit 93a4b6f into sgoudham:main Oct 20, 2023
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants