Linting

maneatingape · maneatingape · commit ca417955c83d · 2025-11-02T09:20:32.000Z
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -12,7 +12,7 @@ Your contribution should generally fall into one of the following two categories
 * 🪲 **Bug Fix** Solutions try to be as general as possible but can't test for every input.
   Your pull request fixes an incorrect answer for your input or prevents a panic.
 * 🚀 **Performance Improvement** Your pull request gives a significant performance
-  improvement. This could be achieved by using a better algorithm, better low level optimizations,
+  improvement. This could be achieved by using a better algorithm, better low-level optimizations,
   by applying the portable SIMD library or by any other means!
 
 ## Legal Notice
diff --git a/src/lib.rs b/src/lib.rs
@@ -48,7 +48,7 @@ library!(year2019 "Rescue Santa from deep space with a solar system voyage."
     day14, day15, day16, day17, day18, day19, day20, day21, day22, day23, day24, day25, intcode
 );
 
-library!(year2020 "What could go wrong trying to enjoy a well deserved vacation?"
+library!(year2020 "What could go wrong trying to enjoy a well-deserved vacation?"
     day01, day02, day03, day04, day05, day06, day07, day08, day09, day10, day11, day12, day13,
     day14, day15, day16, day17, day18, day19, day20, day21, day22, day23, day24, day25
 );
diff --git a/src/util/grid.rs b/src/util/grid.rs
@@ -1,4 +1,4 @@
-//! Fast 2 dimensional Grid backed by a single `vec`. This module is designed to work with [`Point`].
+//! Fast 2-dimensional Grid backed by a single `vec`. This module is designed to work with [`Point`].
 //!
 //! The traits [`Index`] and [`IndexMut`] are implemented for [`Point`] to allow usage like:
 //!
@@ -16,7 +16,7 @@
 //!   assert_eq!(grid[point], b'2');
 //! ```
 //!
-//! A convenience [`parse`] method creates a `Grid` directly from a 2 dimensional set of
+//! 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 in BFS algorithms for tracking visited
 //! locations or for tracking cost in Dijkstra.
diff --git a/src/util/point.rs b/src/util/point.rs
@@ -1,4 +1,4 @@
-//! Comprehensive 2 dimensional point implementation. This class is designed to work together
+//! Comprehensive 2-dimensional point implementation. This class is designed to work together
 //! with the [`Grid`] class.
 //!
 //! A common theme in Advent of Code is operations in 2 dimensions. This module provides a
diff --git a/src/year2016/day11.rs b/src/year2016/day11.rs
@@ -68,7 +68,7 @@ impl Floor {
         self.generators() >= other.generators() && self.microchips() >= other.microchips()
     }
 
-    // Criticial optimization treating generators and microchips as fungible.
+    // Critical optimization treating generators and microchips as fungible.
     #[inline]
     fn valid(self) -> bool {
         self.generators() == 0 || self.generators() >= self.microchips()
diff --git a/src/year2017/day07.rs b/src/year2017/day07.rs
@@ -88,7 +88,7 @@ pub fn parse(input: &str) -> Input<'_> {
             }
         }
 
-        // Total is a nodes weight plus the sum of all children recursively.
+        // Total is a node's weight plus the sum of all children recursively.
         node.total += total;
         node.processed += 1;
 
diff --git a/src/year2017/day10.rs b/src/year2017/day10.rs
@@ -1,8 +1,8 @@
 //! # Knot Hash
 //!
 //! Instead of reversing elements from the starting position then trying to handle wrap around,
-//! its easier use [`rotate_left`] to rotate the array by the same amount so that the starting
-//! position is always zero, then take advantage of the built in [`reverse`] method.
+//! it's easier to use [`rotate_left`] to rotate the array by the same amount so that the starting
+//! position is always zero, then take advantage of the built-in [`reverse`] method.
 //!
 //! [`rotate_left`]: slice::rotate_left
 //! [`reverse`]: slice::reverse
diff --git a/src/year2017/day25.rs b/src/year2017/day25.rs
@@ -1,6 +1,6 @@
 //! # The Halting Problem
 //!
-//! The input is parsed into a 2 dimensional array covering each possible combination of state
+//! The input is parsed into a 2-dimensional array covering each possible combination of state
 //! and tape value at the cursor. Each transition is then computed via a lookup into this array.
 //!
 //! To speed things up by about ten times, multiple transitions are then precomputed to allow
diff --git a/src/year2018/day18.rs b/src/year2018/day18.rs
@@ -1,6 +1,6 @@
 //! # Settlers of The North Pole
 //!
-//! This problem is a cellular automaton similar to the well known
+//! This problem is a cellular automaton similar to the well-known
 //! [Game of Life](https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life). To solve part two
 //! we look for a [cycle](https://en.wikipedia.org/wiki/Cycle_detection) then
 //! extrapolate forward a billion generations.
diff --git a/src/year2018/day22.rs b/src/year2018/day22.rs
@@ -1,6 +1,6 @@
 //! # Mode Maze
 //!
-//! Our high level approach is an [A*](https://en.wikipedia.org/wiki/A*_search_algorithm) search.
+//! Our high-level approach is an [A*](https://en.wikipedia.org/wiki/A*_search_algorithm) search.
 //! This [fantastic blog](https://www.redblobgames.com/pathfinding/a-star/introduction.html)
 //! is a great introduction to this algorithm. The heuristic is the
 //! [Manhattan distance](https://en.wikipedia.org/wiki/Taxicab_geometry) to the target. This will
diff --git a/src/year2018/day23.rs b/src/year2018/day23.rs
@@ -94,7 +94,7 @@ impl Cube {
         x + y + z
     }
 
-    /// All axes are the same same so choose `x` arbitrarily.
+    /// All axes are the same so choose `x` arbitrarily.
     fn size(&self) -> i32 {
         self.x2 - self.x1 + 1
     }
diff --git a/src/year2019/day03.rs b/src/year2019/day03.rs
@@ -13,7 +13,7 @@
 //! First we build two maps, one vertical and one horizontal, of each line segment for the first
 //! wire. Then we trace the steps of the second wire, looking for any intersections. We calculate
 //! both part one and part two at the same time, by also including the distance so far
-//! from the starting point of each lines.
+//! from the starting point of each line.
 //!
 //! [`range`]: BTreeMap::range
 use crate::util::parse::*;
diff --git a/src/year2019/day17.rs b/src/year2019/day17.rs
@@ -2,7 +2,7 @@
 //!
 //! The key insight is that this is not a path finding problem but a *compression*
 //! problem. We need to reduce the robot's path into repetitions of three patterns.
-//! This is essentially a very simple version of the well known
+//! This is essentially a very simple version of the well-known
 //! [LZW](https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch)
 //! algorithm used by the `GIF` and `ZIP` file formats.
 //!
diff --git a/src/year2019/day18.rs b/src/year2019/day18.rs
@@ -1,6 +1,6 @@
 //! # Many-Worlds Interpretation
 //!
-//! Our high level approach is to simplify the problem into graph path finding. We only
+//! Our high-level approach is to simplify the problem into graph path finding. We only
 //! ever need to move directly from key to key, so the maze becomes a graph where the nodes are
 //! keys and the edge weight is the distance between keys. Doors modify which edges
 //! are connected depending on the keys currently possessed.
@@ -18,7 +18,7 @@
 //!   along the way. We can model this by treating keys the same as doors. This optimization
 //!   sped up my solution by a factor of 30.
 //!
-//! On top of this approach we apply some high level tricks to go faster:
+//! On top of this approach we apply some high-level tricks to go faster:
 //! * We store previously seen pairs of `(location, keys collected)` to `total distance` in a map.
 //!   If we are in the same location with the same keys but at a higher cost, then this situation
 //!   can never be optimal so the solution can be discarded.
@@ -29,7 +29,7 @@
 //!   is higher than the asymptotic bounds of repeated BFS, this was twice as fast in practice
 //!   for my input.
 //!
-//! We also apply some low level tricks to go even faster:
+//! We also apply some low-level tricks to go even faster:
 //! * The set of remaining keys needed is stored as bits in an `u32`. We can have at most 26 keys
 //!   so this will always fit. For example needing `a`, `b` and `e` is represented as `10011`.
 //! * Robot location is also stored the same way. Robots can only ever be in their initial location
diff --git a/src/year2019/day24.rs b/src/year2019/day24.rs
@@ -2,7 +2,7 @@
 //!
 //! ## Part One
 //!
-//! The "biodiversity rating" is a very strong hint to store the 5x5 grid as bits in a integer.
+//! The "biodiversity rating" is a very strong hint to store the 5x5 grid as bits in an integer.
 //! To make calculating the rating a no-op, we store the grid:
 //!
 //! ```none
diff --git a/src/year2020/day14.rs b/src/year2020/day14.rs
@@ -12,7 +12,7 @@
 //! ```
 //!
 //! ## Part One
-//! The memory values are quite sparse, about 500 discrete values in a address range of about 65,000.
+//! The memory values are quite sparse, about 500 discrete values in an address range of about 65,000.
 //! This makes a [`FastMap`] a better choice than a large mostly empty array. Storing the correct
 //! value is a straightforward application of the problem rules, expressed as bitwise logic.
 //!
diff --git a/src/year2020/day17.rs b/src/year2020/day17.rs
@@ -4,7 +4,7 @@
 //! Of the total possible volume of the cube formed by the maximum extents in part one, only
 //! roughly 8% is active and of the hypercube from part two only 3% is active for my input.
 //!
-//! To speed things up our high level strategy will flip from a "pull" model where we check the
+//! To speed things up our high-level strategy will flip from a "pull" model where we check the
 //! surrounding neighbors of each cell, to a "push" model where we update the neighbors of each
 //! active cell instead.
 //!
diff --git a/src/year2020/day22.rs b/src/year2020/day22.rs
@@ -4,7 +4,7 @@
 //! [double-ended queue](https://en.wikipedia.org/wiki/Double-ended_queue) backed by a
 //! circular buffer. Why use our own implementation when there is a perfectly good [`VecDeque`]
 //! already available? The answer is speed. As there are at most fifty cards in the pack, the Deck
-//! can use a fix sized stack allocated array, avoiding the expensive heap allocations that
+//! can use a fixed-sized stack allocated array, avoiding the expensive heap allocations that
 //! [`VecDeque`] must use.
 //!
 //! `Deck` also keeps the score up to date as cards are added and removed, as this comes in useful
diff --git a/src/year2021/day01.rs b/src/year2021/day01.rs
@@ -1,6 +1,6 @@
 //! # Sonar Sweep
 //!
-//! The built in [`windows`] method comes in handy for this solution. For part 1 a straightforward
+//! The built-in [`windows`] method comes in handy for this solution. For part 1 a straightforward
 //! sliding window of size 2 allows us to compare each 2 consecutive values.
 //!
 //! For part 2 we can use a trick to simplify. If we consider the first 2 windows of 3 elements
diff --git a/src/year2021/day05.rs b/src/year2021/day05.rs
@@ -1,11 +1,11 @@
 //! # Hydrothermal Venture
 //!
-//! No subtlety with this solution, we create an 1 dimensional array of 1 million `u8` elements
+//! No subtlety with this solution, we create a 1-dimensional array of 1 million `u8` elements
 //! to store all possible points then increment values for each line. This assumes that no lines
 //! cross more than 255 times. This approach is much faster but less flexible than using a
 //! `HashMap` to store mappings of point to values.
 //!
-//! To avoid the overhead of a nested 2 dimensional array, each point `(x, y)` is mapped to
+//! To avoid the overhead of a nested 2-dimensional array, each point `(x, y)` is mapped to
 //! an index `y * 1000 + x`. For each line direction the index delta is calculated using
 //! the handy [`signum`] function.
 //!
diff --git a/src/year2021/day09.rs b/src/year2021/day09.rs
@@ -7,7 +7,7 @@
 //! such as a [`VecDeque`].
 //!
 //! This solution uses a DFS approach as it's faster and Rust's stack size limit seems enough
-//! to accommodate the maximum basin size. 2 dimensional grids are common in Advent of Code
+//! to accommodate the maximum basin size. 2-dimensional grids are common in Advent of Code
 //! problems so we use our utility [`Grid`] and [`Point`] modules.
 //!
 //! [`VecDeque`]: std::collections::VecDeque
diff --git a/src/year2021/day12.rs b/src/year2021/day12.rs
@@ -4,13 +4,13 @@
 //! system, exploring all possible permutations of the paths and finishing whenever we reach
 //! the `end` cave.
 //!
-//! To speed things up, 2 strategies are used, one high level and one low level:
+//! To speed things up, 2 strategies are used, one high-level and one low-level:
 //! * [Memoization](https://en.wikipedia.org/wiki/Memoization) (or caching) of the possible paths
-//!   from each position, taking into account previously visited caves is the high level strategy
+//!   from each position, taking into account previously visited caves is the high-level strategy
 //!   to re-use work and save time.
 //! * [Bit Manipulation](https://en.wikipedia.org/wiki/Bit_manipulation) to store both the graph of
 //!   cave connections as an [adjacency matrix](https://en.wikipedia.org/wiki/Adjacency_matrix)
-//!   and the list of visited caves compressed into a single `u32` is the low level strategy to
+//!   and the list of visited caves compressed into a single `u32` is the low-level strategy to
 //!   quickly and efficiently store the small cardinality set of caves.
 use crate::util::bitset::*;
 use crate::util::hash::*;
diff --git a/src/year2021/day23.rs b/src/year2021/day23.rs
@@ -1,6 +1,6 @@
 //! # Amphipod
 //!
-//! Our high level approach is an [A*](https://en.wikipedia.org/wiki/A*_search_algorithm) search
+//! Our high-level approach is an [A*](https://en.wikipedia.org/wiki/A*_search_algorithm) search
 //! over all possible burrow states. Three techniques are used to speed things up.
 //!
 //! Firstly a good choice of heuristic is crucial. The heuristic used has the following
@@ -14,7 +14,7 @@
 //! * Detecting deadlocked states where an amphipod in the hallway prevents any possible solution.
 //!   Exploring any further is a waste of time.
 //!
-//! Thirdly low level bit manipulation is used to represent the burrow state size compactly
+//! Thirdly low-level bit manipulation is used to represent the burrow state size compactly
 //! in only 16 bytes for faster copying and hashing.
 use crate::util::hash::*;
 use crate::util::heap::*;
@@ -266,8 +266,8 @@ fn best_possible(burrow: &Burrow) -> usize {
                 // Even though we're in our home burrow we need to move out of the way of a lower
                 // amphipod of a different kind.
                 need_to_move[kind] += 1;
-                // Calculate the energy assuming we can move to one of the nearest hallway
-                // spaces on either side.
+                // Calculate the energy assuming we can move to one of the nearest hallway spaces
+                // on either side.
                 let up = 4 - depth;
                 let across = 2; // Nearest spot then back
                 let down = need_to_move[kind];
diff --git a/src/year2022/day15.rs b/src/year2022/day15.rs
@@ -94,7 +94,7 @@ pub fn part2_testable(input: &[Input], size: i32) -> u64 {
     let mut right = FastSet::new();
 
     // Rotate points clockwise by 45 degrees, scale by √2 and extend edge by 1.
-    // This transform each sensor into an axis aligned bounding box.
+    // This transforms each sensor into an axis aligned bounding box.
     // The distress beacon is located where the top, left, bottom and right
     // edges of 4 separate bounding boxes intersect.
     for Input { sensor, manhattan, .. } in input {
diff --git a/src/year2022/day23.rs b/src/year2022/day23.rs
@@ -1,6 +1,6 @@
 //! # Unstable Diffusion
 //!
-//! We represent elves as bits in a integer then use bitwise operations to efficiently figure
+//! We represent elves as bits in an integer then use bitwise operations to efficiently figure
 //! out the movement for multiple elves at once.
 use Direction::*;
 
@@ -112,7 +112,7 @@ fn step(input: &mut Input, order: &mut [Direction]) -> bool {
 
         let mut up = prev;
         let mut down = next;
-        // Find neighours in vertical columns.
+        // Find neighbors in vertical columns.
         let vertical = grid[i - 1].or(grid[i]).or(grid[i + 1]).not();
         let mut left = vertical.shr();
         let mut right = vertical.shl();
diff --git a/src/year2023/day02.rs b/src/year2023/day02.rs
@@ -2,21 +2,21 @@
 use crate::util::iter::*;
 use crate::util::parse::*;
 
-pub struct Game(u32, u32, u32);
+type Game = (u32, u32, u32);
 
 /// Parse each game into the maximum red, green and blue values.
 pub fn parse(input: &str) -> Vec<Game> {
     input
         .lines()
         .map(|line| {
             line.split_ascii_whitespace().chunk::<2>().skip(1).fold(
-                Game(0, 0, 0),
-                |Game(r, g, b), [amount, color]| {
+                (0, 0, 0),
+                |(r, g, b), [amount, color]| {
                     let amount = amount.unsigned();
                     match color.as_bytes()[0] {
-                        b'r' => Game(r.max(amount), g, b),
-                        b'g' => Game(r, g.max(amount), b),
-                        b'b' => Game(r, g, b.max(amount)),
+                        b'r' => (r.max(amount), g, b),
+                        b'g' => (r, g.max(amount), b),
+                        b'b' => (r, g, b.max(amount)),
                         _ => unreachable!(),
                     }
                 },
@@ -30,11 +30,11 @@ pub fn part1(input: &[Game]) -> usize {
     input
         .iter()
         .enumerate()
-        .filter_map(|(id, &Game(r, g, b))| (r <= 12 && g <= 13 && b <= 14).then_some(id + 1))
+        .filter_map(|(id, &(r, g, b))| (r <= 12 && g <= 13 && b <= 14).then_some(id + 1))
         .sum()
 }
 
 /// Sum the product of maximum red, green and blue values.
 pub fn part2(input: &[Game]) -> u32 {
-    input.iter().map(|Game(r, g, b)| r * g * b).sum()
+    input.iter().map(|(r, g, b)| r * g * b).sum()
 }
diff --git a/src/year2023/day14.rs b/src/year2023/day14.rs
@@ -14,7 +14,7 @@
 //!
 //! Next for each possible tilt orientation (north, south, east and west) an approach similar to a
 //! prefix sum is used. Each edge or fixed rock is assigned an index. We expand the grid by 2 in
-//! each direction (one for each edge) to handles the edges. For example, using west (left):
+//! each direction (one for each edge) to handle the edges. For example, using west (left):
 //!
 //! ```none
 //!     ..#.#..
diff --git a/src/year2023/day16.rs b/src/year2023/day16.rs
@@ -194,7 +194,7 @@ fn beam(graph: &mut Graph, node: &mut Node, mut position: Point, mut direction:
     }
 }
 
-/// Tarjan's algorithm to find strongly connected components, e.g cycles in a directed graph.
+/// Tarjan's algorithm to find strongly connected components, e.g. cycles in a directed graph.
 fn strong_connect(graph: &mut Graph, position: Point) -> usize {
     // Push current index to stack and insert a dummy node to keep the vector index correct when
     // processing children.
diff --git a/src/year2023/day17.rs b/src/year2023/day17.rs
@@ -1,6 +1,6 @@
 //! # Clumsy Crucible
 //!
-//! Our high level approach is an [A*](https://en.wikipedia.org/wiki/A*_search_algorithm) search.
+//! Our high-level approach is an [A*](https://en.wikipedia.org/wiki/A*_search_algorithm) search.
 //! This [fantastic blog](https://www.redblobgames.com/pathfinding/a-star/introduction.html)
 //! is a great introduction to this algorithm.
 //!
diff --git a/src/year2023/day21.rs b/src/year2023/day21.rs
@@ -27,7 +27,7 @@
 //!       #
 //! ```
 //!
-//! The next insight is that if we can reach a plot in `x` steps the we can also reach it in
+//! The next insight is that if we can reach a plot in `x` steps then we can also reach it in
 //! `x + 2, x + 4...` steps by repeatedly stepping back and forth 1 tile. This means the
 //! number of tiles reachable depends on the *parity* of a plot from the center,
 //! i.e. whether it is an odd or even number of steps. As the 131 width of the tile is an odd
diff --git a/src/year2023/day23.rs b/src/year2023/day23.rs
@@ -7,7 +7,7 @@
 //! ## Compression
 //!
 //! First we "compress" the maze into a much smaller simpler graph. For example the following maze
-//! converts into a undirected weighted graph.
+//! converts into an undirected weighted graph.
 //!
 //! ```none
 //!     #.#####
diff --git a/src/year2023/day25.rs b/src/year2023/day25.rs
@@ -28,10 +28,10 @@
 //!           * *       * *
 //!     ```
 //!
-//! Our high level approach is as follows:
+//! Our high-level approach is as follows:
 //! * Pick any arbitrary node
 //! * Find a start node furthest from it.
-//! * Find a end node furthest from the start node.
+//! * Find an end node furthest from the start node.
 //!
 //! The key insight is that the start and end nodes must be on opposite sides of the cut.
 //! We then BFS 3 times from the start to the end to find 3 different shortest paths.
@@ -43,7 +43,7 @@
 //! on start's side of the graph and will find our answer.
 //!
 //! The complexity of each BFS is `O(V + E)` and we perform a total of 6. To speed things up even
-//! further some low level optimizations are used:
+//! further some low-level optimizations are used:
 //!
 //! * Numeric node and edge identifiers to allow `vec` to store previously seen values instead
 //!   of `HashMap`.
@@ -74,7 +74,7 @@ impl Input {
 /// Then the edges are gathered into a single vec so that each edge also has a unique index.
 ///
 /// As both node and edge indices are contiguous this allows us to use a vec to store previously
-/// seen values which is must faster than using a `HashMap`.
+/// seen values which is much faster than using a `HashMap`.
 pub fn parse(input: &str) -> Input {
     let mut lookup = vec![usize::MAX; 26 * 26 * 26];
     let mut neighbours = Vec::with_capacity(2_000);
diff --git a/src/year2024/day07.rs b/src/year2024/day07.rs
diff --git a/src/year2024/day11.rs b/src/year2024/day11.rs
diff --git a/src/year2024/day20.rs b/src/year2024/day20.rs

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-//! Comprehensive 2 dimensional point implementation. This class is designed to work together`
	`1`	`+//! Comprehensive 2-dimensional point implementation. This class is designed to work together`
`2`	`2`	//! with the [`Grid`] class.
`3`	`3`	`//!`
`4`	`4`	`//! A common theme in Advent of Code is operations in 2 dimensions. This module provides a`
Original file line number	Diff line number	Diff line change
`@@ -68,7 +68,7 @@ impl Floor {`
`68`	`68`	`self.generators() >= other.generators() && self.microchips() >= other.microchips()`
`69`	`69`	`}`
`70`	`70`
`71`		`- // Criticial optimization treating generators and microchips as fungible.`
	`71`	`+ // Critical optimization treating generators and microchips as fungible.`
`72`	`72`	`#[inline]`
`73`	`73`	`fn valid(self) -> bool {`
`74`	`74`	`self.generators() == 0 \|\| self.generators() >= self.microchips()`
Original file line number	Diff line number	Diff line change
`@@ -88,7 +88,7 @@ pub fn parse(input: &str) -> Input<'_> {`
`88`	`88`	`}`
`89`	`89`	`}`
`90`	`90`
`91`		`- // Total is a nodes weight plus the sum of all children recursively.`
	`91`	`+ // Total is a node's weight plus the sum of all children recursively.`
`92`	`92`	`node.total += total;`
`93`	`93`	`node.processed += 1;`
`94`	`94`