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>

diff --git a/book/src/04_traits/05_trait_bounds.md b/book/src/04_traits/05_trait_bounds.md
index 01bf8d3..a3e3f73 100644 (file)
--- 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<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