mirror of
https://github.com/mainmatter/100-exercises-to-learn-rust
synced 2024-11-16 19:50:44 +01:00
fix(book): Correct type parameter naming convention to pascal case (#79)
* fix(book): Correct type parameter naming convention to pascal case * Update book/src/04_traits/05_trait_bounds.md --------- Co-authored-by: Felix Pherry <182051.FELIX@klgroup.local> Co-authored-by: Luca Palmieri <20745048+LukeMathWalker@users.noreply.github.com>
This commit is contained in:
parent
ffb2f08b67
commit
e99a15390e
1 changed files with 3 additions and 3 deletions
|
@ -58,7 +58,7 @@ We can do better using **generics**.\
|
|||
Generics allow us to write code that works with a **type parameter** instead of a concrete type:
|
||||
|
||||
```rust
|
||||
fn print_if_even<T>(n: T)
|
||||
fn print_if_even<T>(n: T)
|
||||
where
|
||||
T: IsEven + Debug
|
||||
{
|
||||
|
@ -125,7 +125,7 @@ body is present.
|
|||
All the examples above used a **`where` clause** to specify trait bounds:
|
||||
|
||||
```rust
|
||||
fn print_if_even<T>(n: T)
|
||||
fn print_if_even<T>(n: T)
|
||||
where
|
||||
T: IsEven + Debug
|
||||
// ^^^^^^^^^^^^^^^^^
|
||||
|
@ -160,7 +160,7 @@ fn print_if_even<Number: IsEven + Debug>(n: Number) {
|
|||
It is actually **desirable** to use meaningful names when there are multiple type parameters at play or when the name
|
||||
`T` doesn't convey enough information about the type's role in the function.
|
||||
Maximize clarity and readability when naming type parameters, just as you would with variables or function parameters.
|
||||
Follow Rust's conventions though: use camel case for type parameter names.
|
||||
Follow Rust's conventions, though: use [upper camel case for type parameter names](https://rust-lang.github.io/api-guidelines/naming.html#casing-conforms-to-rfc-430-c-case).
|
||||
|
||||
## The function signature is king
|
||||
|
||||
|
|
Loading…
Reference in a new issue