From e99a15390e86b28154b3471437dd959ce014ead0 Mon Sep 17 00:00:00 2001 From: Felix Pherry <71205609+felixpherry@users.noreply.github.com> Date: Sat, 1 Jun 2024 13:31:48 +0700 Subject: [PATCH] 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> --- book/src/04_traits/05_trait_bounds.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/book/src/04_traits/05_trait_bounds.md b/book/src/04_traits/05_trait_bounds.md index 01bf8d3..a3e3f73 100644 --- a/book/src/04_traits/05_trait_bounds.md +++ b/book/src/04_traits/05_trait_bounds.md @@ -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(n: T) +fn print_if_even(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(n: T) +fn print_if_even(n: T) where T: IsEven + Debug // ^^^^^^^^^^^^^^^^^ @@ -160,7 +160,7 @@ fn print_if_even(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 -- 2.45.2