Miscellaneous fixes (#84)

zohairawan · web-flow · commit 492fb9f08cf8 · 2025-08-14T10:59:27.000-04:00
* Fix typos/grammar

* Fix code example

* Fix typo

* Fix typo

* Fix typo

* Fix grammar

* Fix grammar

* Fix typo

* Fix typo

* Fix typo
diff --git a/src/collections/factories.md b/src/collections/factories.md
@@ -62,7 +62,7 @@ class Main {
 }
 ```
 
-If you want the opposite - if you want to make a copy of a something like an `ArrayList`
+If you want the opposite - if you want to make a copy of something like an `ArrayList`
 which does not support `.add`, `.remove`, etc. - you can use `copyOf`.
 
 ```java
diff --git a/src/encapsulation/classes.md b/src/encapsulation/classes.md
@@ -52,7 +52,7 @@ public class ArrayList<E> extends AbstractList<E>
 }
 ```
 
-People who write programs that depend on the calling `.add` on an `ArrayList` do not need
+People who write programs that depend on calling `.add` on an `ArrayList` do not need
 to understand how or when the internal `elementData` and `size` fields are updated. Those also
 need not be the only fields that exist. All that is required is "calling `.add` will add an element to the list."
 
diff --git a/src/encapsulation/coupling.md b/src/encapsulation/coupling.md
@@ -14,5 +14,5 @@ long as code that is coupled is also "co-located" making changes
 to that code can be easier than if it were spread over multiple files.
 
 A not insignificant part of practice in the coding world is deciding when
-pieces of a program deserve to be abstracted from eachother (to minimize interdependence)
+pieces of a program deserve to be abstracted from each other (to minimize interdependence)
 and when they deserve to be coupled together (to keep logic in one place.)
diff --git a/src/hash_maps/appropriate_keys.md b/src/hash_maps/appropriate_keys.md
@@ -3,7 +3,7 @@
 Both objects with reference based and value based definitions of `equals` and `hashCode` 
 are "appropriate" to use as keys in `HashMap`s.
 
-The most important thing to be careful of using objects where`equals` and `hashCode` 
+The most important thing to be careful of is using objects where`equals` and `hashCode` 
 are value based, but the object itself is mutable.
 
 ```java
diff --git a/src/hash_maps/hash_distribution.md b/src/hash_maps/hash_distribution.md
@@ -7,7 +7,7 @@ If you open up a doctor's office in South Boston, you might have an issue
 ordering charts by last name only. Your `M` cabinet will be overflowing.[^irish]
 
 For that scenario, using the first letter of the last name is a non-ideal hash function
-because so when many people have last names starting with the same letter, they will
+because when so many people have last names starting with the same letter, they will
 not be evenly distributed amongst the buckets.
 
 Making a hash function with a good distribution is hard. `Objects.hash` will do a decent job of it
diff --git a/src/hash_maps/reference_based_identity.md b/src/hash_maps/reference_based_identity.md
@@ -8,7 +8,7 @@ Instead of making buckets like `A-G` and `H-Z`, it will use ranges of numbers. T
 same though
 
 For classes you make yourself, their `hashCode` will be based on what we call an object's
-"identity." This means that while different instances of a class might give the same 
+"identity." This means that while different instances of a class might give the same (incomplete sentence)
 
 
 ```java
@@ -67,8 +67,8 @@ class Main {
         // Car C is a distinct object with its own identity
         var carC = new LivingRaceCar(10);
         
-        // Car C therefore only equal itself
-        // Car A and B will equal eachother
+        // Car C therefore will only equal itself
+        // Car A and B will equal each other
         IO.println("A.equals(A): " + carA.equals(carA));
         IO.println("A.equals(B): " + carA.equals(carB));
         IO.println("A.equals(C): " + carA.equals(carC));
diff --git a/src/hash_maps/value_based_identity.md b/src/hash_maps/value_based_identity.md
@@ -1,7 +1,7 @@
 # Value Based Identity
 
-While reference based identity can be useful, its often not what you want for keys in a `HashMap`.
-Ideally if you are looking up `"Tow Mater"` you shouldn't have to be careful to ensure its the *same*
+While reference based identity can be useful, it's often not what you want for keys in a `HashMap`.
+Ideally if you are looking up `"Tow Mater"` you shouldn't have to be careful to ensure it's the *same*
 instance of `String`, all you care about is that it contains the right characters.
 
 We call this notion of identity "value based." Two things are the same if they contain the same data - i.e. if they represent the same value.
diff --git a/src/hyrums_law/authority.md b/src/hyrums_law/authority.md
@@ -5,7 +5,7 @@ are not really laws in the same way as "The Law of Conservation of Energy."
 
 Those sorts of laws are observed truths about a field. Best we can tell they are always true, no matter what.
 
-Hyrum's Law is just an aphorism. Its one specific person's view on the field.
+Hyrum's Law is just an aphorism. It's one specific person's view on the field.
 
 This sounds sketchy, and it is, but the state
 of the computing field is such that aphorisms and personal anecdotes are often the best information we have.
diff --git a/src/hyrums_law/emergent_properties.md b/src/hyrums_law/emergent_properties.md
@@ -7,5 +7,5 @@ Hyrum's law is one of those sorts of things. Nobody sat down and agreed
 that they will use an API in wacky ways. It just happens when you throw enough
 monkeys in a pile and they all reach for a keyboard.
 
-As such, the way to deal with it isn't to put blame upon the monkeys. Its
+As such, the way to deal with it isn't to put blame upon the monkeys. It's
 to accept it as a naturally occurring phenominon and plan accordingly.
diff --git a/src/interfaces_ii.md b/src/interfaces_ii.md
@@ -3,5 +3,5 @@
 Interfaces let you describe a common set of methods shared
 by different implementing classes.
 
-They can do slightly more than this though and its helpful
+They can do slightly more than this though and it's helpful
 to know about.
diff --git a/src/interfaces_ii/static_methods.md b/src/interfaces_ii/static_methods.md
@@ -13,8 +13,8 @@ interface Animal {
             // My cousin has a Pig that we were all afraid
             // was going to straight up eat her child.
             //
-            // The child got old enough that its not a concern,
-            // but good god.
+            // The child got old enough that it's not a concern,
+            // but good God.
             return false;
         }
     }
diff --git a/src/recursion/counting_down.md b/src/recursion/counting_down.md
@@ -8,7 +8,7 @@ number one lower than you were given. if it isn't you are done.
 
 ```java
 void countDown(int x) {
-    if (x > 0) {
+    if (x <= 0) {
         IO.println("DONE");
     }
     else {
diff --git a/src/recursion/disclaimer.md b/src/recursion/disclaimer.md
@@ -4,9 +4,9 @@ Recursion will be annoying to learn.
 
 Sorry.
 
-Its not because its particuarly hard or because its
-beyond your ken. Its just that when you learn loops first, recursion
+It's not because it's particuarly hard or because it's
+beyond your ken. It's just that when you learn loops first, recursion
 tends to be harder to learn than if you started with it.
 
 The good news is that once you get it, after however much
-mental anguish, you won't forget it. And it will be useful, however occasionally.
+mental anguish, you won't forget it. And it will be useful, however occasional.
diff --git a/src/reflection.md b/src/reflection.md
@@ -1,10 +1,10 @@
 # Reflection
 
-Reflection is the what we call it when a program
+Reflection is what we call it when a program
 uses information about how it - the program - is structured
 in order to do things while running.
 
-We call it reflection because its as if your code
+We call it reflection because it's as if your code
 looks into a mirror and sees its own reflection.[^whenhumans]
 
 [^whenhumans]: When a human looks into a mirror they might see their own eye color.
diff --git a/src/reflection/class_objects.md b/src/reflection/class_objects.md
@@ -41,5 +41,5 @@ up front you should use a wildcard.
 
 [^ifconfused]: If that seems confusing and useless, you are half
 right. It certainly is confusing, but it is pretty useful sometimes.
-If its still beyond your ken just always write `Class<?>` and we'll
+If it's still beyond your ken just always write `Class<?>` and we'll
 loop back to it.
diff --git a/src/reflection/get_a_method.md b/src/reflection/get_a_method.md
@@ -21,7 +21,7 @@ class Tea {
 ```
 
 
-Unlike fields which can be identified only by their name, methods which are distinct overloads of eachother
+Unlike fields which can be identified only by their name, methods which are distinct overloads of each other
 are distinguised by the arguments they take in.
 
 ```java

Original file line number	Diff line number	Diff line change
`@@ -62,7 +62,7 @@ class Main {`
`62`	`62`	`}`
`63`	`63`	```
`64`	`64`
`65`		-If you want the opposite - if you want to make a copy of a something like an `ArrayList`
	`65`	+If you want the opposite - if you want to make a copy of something like an `ArrayList`
`66`	`66`	which does not support `.add`, `.remove`, etc. - you can use `copyOf`.
`67`	`67`
`68`	`68`	```java
Original file line number	Diff line number	Diff line change
`@@ -52,7 +52,7 @@ public class ArrayList<E> extends AbstractList<E>`
`52`	`52`	`}`
`53`	`53`	```
`54`	`54`
`55`		-People who write programs that depend on the calling `.add` on an `ArrayList` do not need
	`55`	+People who write programs that depend on calling `.add` on an `ArrayList` do not need
`56`	`56`	to understand how or when the internal `elementData` and `size` fields are updated. Those also
`57`	`57`	need not be the only fields that exist. All that is required is "calling `.add` will add an element to the list."
`58`	`58`