Comment linting

Author: maneatingape

CONTRIBUTING.md

@@ -3,7 +3,7 @@
 I hope that you've enjoyed reading these solutions as much as I enjoyed writing them.
 They're pretty fast and clean...but can you make them even *faster and cleaner*?
 
-If you've made an improvement then please
+If you've made an improvement, then please
 [open a pull request](https://github.com/maneatingape/advent-of-code-rust/compare).
 Contributions are encouraged and valued. ❤️
 

src/util/grid.rs

@@ -18,8 +18,8 @@
 //!
 //! A convenience [`parse`] method creates a `Grid` directly from a 2 dimensional set of
 //! ASCII characters, a common occurrence in Advent of Code inputs. The [`same_size_with`] function
-//! creates a grid of the same size, that can be used for in BFS algorithms for tracking visited
-//! location or for tracking cost in Dijkstra.
+//! creates a grid of the same size that can be used in BFS algorithms for tracking visited
+//! locations or for tracking cost in Dijkstra.
 //!
 //! [`Point`]: crate::util::point
 //! [`parse`]: Grid::parse

src/util/math.rs

@@ -6,7 +6,7 @@
 //!
 //! * [Least common multiple](https://en.wikipedia.org/wiki/Least_common_multiple)
 //!
-//! * [Modular exponentation](https://en.wikipedia.org/wiki/Modular_exponentiation).
+//! * [Modular exponentiation](https://en.wikipedia.org/wiki/Modular_exponentiation).
 //!   Calculates bᵉ mod m efficiently using
 //!   [exponentiation by squaring](https://en.wikipedia.org/wiki/Exponentiation_by_squaring).
 //!

src/util/parse.rs

@@ -8,8 +8,8 @@
 //! ```
 //!
 //! This module provides two [`&str`] extension methods [`iter_signed`] and [`iter_unsigned`]. The
-//! reason for the separate methods is that some Advent of Code inputs contains the `-` character
-//! as a delimeter and this would cause numbers to be incorrectly parsed as negative.
+//! reason for the separate methods is that some Advent of Code inputs contain the `-` character
+//! as a delimiter and this would cause numbers to be incorrectly parsed as negative.
 //!
 //! [`iter_unsigned`]: ParseOps::iter_unsigned
 //! [`iter_signed`]: ParseOps::iter_signed

src/util/thread.rs

@@ -1,6 +1,6 @@
 //! Utility methods to spawn a number of
 //! [scoped](https://doc.rust-lang.org/stable/std/thread/fn.scope.html)
-//! threads equals to the number of cores on the machine. Unlike normal threads, scoped threads
+//! threads equal to the number of cores on the machine. Unlike normal threads, scoped threads
 //! can borrow data from their environment.
 use std::sync::atomic::{AtomicBool, AtomicU32, AtomicUsize, Ordering::Relaxed};
 use std::thread::*;
@@ -31,7 +31,7 @@ where
 /// Spawns `n` scoped threads that each receive a
 /// [work stealing](https://en.wikipedia.org/wiki/Work_stealing) iterator.
 /// Work stealing is an efficient strategy that keeps each CPU core busy when some items take longer
-/// than other to process, used by popular libraries such as [rayon](https://github.com/rayon-rs/rayon).
+/// than others to process, used by popular libraries such as [rayon](https://github.com/rayon-rs/rayon).
 /// Processing at different rates also happens on many modern CPUs with
 /// [heterogeneous performance and efficiency cores](https://en.wikipedia.org/wiki/ARM_big.LITTLE).
 pub fn spawn_parallel_iterator<F, R, T>(items: &[T], f: F) -> Vec<R>
@@ -43,7 +43,7 @@ where
     let threads = threads();
     let size = items.len().div_ceil(threads);
 
-    // Initially divide work as evenly as possible amongst each worker thread.
+    // Initially divide work as evenly as possible among each worker thread.
     let workers: Vec<_> = (0..threads)
         .map(|id| {
             let start = (id * size).min(items.len());

src/year2015/day07.rs

@@ -1,7 +1,7 @@
 //! # Some Assembly Required
 //!
 //! To obtain the result we recursively compute the inputs starting at gate `a` and working
-//! backwards. To make things faster we memoize the result of each wire in a cache, so that each
+//! backward. To make things faster we memoize the result of each wire in a cache, so that each
 //! wire is computed at most once.
 //!
 //! For part two we pre-seed the value of `b` in the cache with the result from part one then

src/year2015/day23.rs

@@ -4,7 +4,7 @@
 //! [3n + 1 sequence](https://en.wikipedia.org/wiki/Collatz_conjecture)
 //! for one of two different numbers chosen depending on whether `a` is 0 or 1.
 //!
-//! The code fast enough to emulate directly without needing any understanding of what it's doing.
+//! The code is fast enough to emulate directly without needing any understanding of what it's doing.
 use crate::util::parse::*;
 
 pub enum Op {

src/year2015/day25.rs

@@ -22,7 +22,7 @@
 //!
 //! Starting at the chosen number 12 and moving diagonally upwards to the right we intersect
 //! the top row at column `column + row - 1 = 2 + 4 - 1 = 5`. This gives the triangular number
-//! `5 * (5 + 1) / 2 = 15`. Then we count backwards by `row` elements to get the one less
+//! `5 * (5 + 1) / 2 = 15`. Then we count backward by `row` elements to get the one less
 //! zero based based index `15 - 4 = 11`.
 //!
 //! The second part is realizing that the description of the code generation is

src/year2016/day12.rs

@@ -3,7 +3,7 @@
 //! This problem is interesting in that the solution is all about *reading* code not writing code.
 //!
 //! We could implement a brute force virtual machine without understanding the underlying code
-//! but it's much more efficient to analyse the code instead.
+//! but it's much more efficient to analyze the code instead.
 //!
 //! The first thing we notice is that the following idiom is repeated several times:
 //!

src/year2016/day19.rs

@@ -2,7 +2,7 @@
 //!
 //! The title is a reference to the [Josephus problem](https://en.wikipedia.org/wiki/Josephus_problem).
 //! We can solve both parts efficiently in `O(1)` constant storage without needing any
-//! auxiliary data strucutres.
+//! auxiliary data structures.
 //!
 //! ## Part One
 //!
@@ -58,12 +58,12 @@
 //!
 //! Part two is a variant of the problem. We solve in `log(n)` time by working *backwards*
 //! from the winning elf until we reach the starting number of elves.
-//! Starting with the winning elf `a` it must have eliminated its neighbour to the right:
+//! Starting with the winning elf `a` it must have eliminated its neighbor to the right:
 //!
 //! `a` => `a b`
 //!
 //! We then choose the previous elf to the left wrapping around to elf `b` in this case. Elf `b`
-//! must have eliminated its neighbour 1 step to the right:
+//! must have eliminated its neighbor 1 step to the right:
 //!
 //! `a b` => `a b c`
 //!