Merge branch 'develop' into develop

Author: bowbahdoe

src/collections/factories.md

@@ -62,7 +62,8 @@ 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

src/encapsulation/classes.md

@@ -52,7 +52,8 @@ 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."
 

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.)

src/files.md

@@ -4,6 +4,6 @@ Files are how you store information
 on a[^normal] computer so that it can still be there when your program
 is done running.
 
-As such, read files and writing files are tasks you will often want to do.
+As such, reading files and writing files are tasks you will often want to do.
 
 [^normal]: *normal

src/generics/raw_types.md

@@ -39,8 +39,7 @@ void main() {
 
 Raw types exist for two basic reasons
 
-1. Every now and then Java isn't smart enough. Trust that there are valid reasons to turn off generics, even
-I haven't shown you any yet. Avoid doing so yourself - at least for awhile.
+1. Every now and then Java isn't smart enough. Trust that there are valid reasons to turn off generics, even if I haven't shown you any yet. Avoid doing so yourself - at least for awhile.
 2. Generics weren't always in Java! Classes that later were made generic had to stay compatible with old "raw"
 usages somehow.
 

src/hash_maps/appropriate_keys.md

@@ -3,7 +3,8 @@
 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

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

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));

src/hash_maps/value_based_identity.md

@@ -1,7 +1,8 @@
 # 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.

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.