Refactor comments.

Author: Luca Palmieri

jira-wip/src/koans/02_ticket_store/01_store.rs

@@ -1,24 +1,27 @@
 mod store {
     /// It's time to shift focus: our tickets are doing well, but they need a home.
-    /// A place where we can store them, search for them, and retrieve them.
+    /// A place where we can store them, search for them, retrieve them.
     ///
     /// We can use many different data structures to store and manage our tickets.
     /// JIRA users rely heavily on ticket identifiers, e.g. RUST-2018 or COVID-19.
-    /// It's a unique label that identifies univocally a single ticket, generally `<board name>-<ticket number>`.
+    /// It's a unique label that unambiguously identifies a single ticket,
+    /// generally `<board name>-<ticket number>`.
     /// We don't have the concept of a board yet, so we'll roll with a simple numerical id.
     ///
     /// What is the simplest data structure that allows us to fetch a ticket given its id?
     /// It makes sense for us to use a HashMap, also known as a dictionary in other languages.
-    /// You can read more about the HashMap in rust here: https://doc.rust-lang.org/std/collections/struct.HashMap.html
+    /// You can read more about the HashMap in Rust here:
+    /// https://doc.rust-lang.org/std/collections/struct.HashMap.html
     use std::collections::HashMap;
     /// Let's import what we worked on in the previous set of exercises.
     use super::recap::Ticket;
 
     /// First we will create a TicketStore struct, with a `data` field of type HashMap.
     ///
-    /// HashMap is a *generic* struct: we need to specify two types, one for the key, and one for the stored value - HashMap<K, V>.
+    /// HashMap is a *generic* struct: we need to specify two types, one for the key, and one for
+    /// the stored value - HashMap<K, V>.
     ///
-    /// Let's set the value to the type of our Ticket, and we will use an unsigned integer for our identifier.
+    /// Let's set the value type to our Ticket, and we will use an unsigned integer for our ids.
     struct TicketStore {
         /// The collection of stored tickets.
         data: HashMap<u32, Ticket>,
@@ -30,13 +33,13 @@ mod store {
         /// It can be invoked using `TicketStore::new()`.
         pub fn new() -> TicketStore {
             TicketStore {
-                // Note that the compiler can infer the
-                // types for our HashMaps' key value pairs.
+                // Note that the compiler can infer the types for our HashMaps' key-value pairs.
                 data: HashMap::new(),
             }
         }
 
-        /// We take `&mut self` because we will have to mutate our HashMap to insert a new key/value pair.
+        /// We take `&mut self` because we will have to mutate our HashMap to insert a new
+        /// key-value pair.
         pub fn save(&mut self, ticket: Ticket, id: u32) {
             todo!()
         }
@@ -54,33 +57,39 @@ mod store {
 
         /// Now let's put our TicketStore to use
         ///
-        /// We are going to create a ticket as we have previously done
-        /// then store it in our TicketStore, and finally validate that
-        /// the ticket we have saved in our store is indeed the same ticket
+        /// We are going to create a ticket, save it in our TicketStore and finally validate that
+        /// the ticket we have saved in our store is indeed the same ticket we created.
         #[test]
         fn a_ticket_with_a_home() {
             let ticket = generate_ticket(Status::ToDo);
 
-            // Pay special attention to the 'mut' keyword here: variables are immutable by default in Rust.
-            // The `mut` keyword is used to signal that you must pay special attention to the variable as it's likely to change later on
-            // in the function body.
+            // Pay special attention to the 'mut' keyword here: variables are immutable
+            // by default in Rust.
+            // The `mut` keyword is used to signal that you must pay special attention to the
+            // variable as it's likely to change later on in the function body.
             let mut store = TicketStore::new();
             let ticket_id = Faker.fake();
 
-            // Here we need to create a clone of our `ticket` because `save` takes the `ticket` argument as value,
-            // thus taking ownership of its value out of the caller function into the method.
-            // But we need `ticket`'s value after this method call, to verify it matches what we retrieve.
-            // Hence the need to clone it, creating a copy of the value and passing that copy to the `save` method.
+            // Here we need to create a clone of our `ticket` because `save` takes the `ticket`
+            // argument as value, thus taking ownership of its value out of the caller function
+            // into the method.
+            // But we need `ticket`'s value after this method call, to verify it matches what
+            // we retrieve.
+            // Hence the need to clone it, creating a copy of the value and passing that copy to
+            // the `save` method.
             //
-            // (You might have to go back to the `recap` koan to derive a couple more traits for Ticket and Status...)
+            // (You might have to go back to the `recap` koan to derive a couple more traits
+            // for Ticket and Status...)
             store.save(ticket.clone(), ticket_id);
 
             assert_eq!(store.get(&ticket_id), &ticket);
         }
 
-        /// We want our `get` method to panic when looking for an id to which there is no ticket associated (for now).
+        /// We want our `get` method to panic when looking for an id to which there is no ticket
+        /// associated (for now).
         ///
-        /// Rust has a way to handle this failure mode more gracefully, we will take a look at it later.
+        /// Rust has a way to handle this failure mode more gracefully, we will take a look
+        /// at it later.
         #[test]
         #[should_panic]
         fn a_missing_ticket() {