Apply suggestions to the suggestions

docs/comments.md

@@ -8,7 +8,7 @@ While we're not enforcing a strict standard, here are some things to keep in min
   - Comments should **NOT** repeat _what_ code _does_[^1] or explain concepts obvious to someone with a basic understanding of the language at hand. Instead, focus on explaining _why_ a line or block of code exists.
     - Anyone with basic reading comprehension and a good IDE can figure out what code does; gaining a _post hoc_ understanding of the _reasons_ behind its existence takes a lot more digging, effort and bloodshed.
 - Keep comments readable
-  - A comment's verbosity should roughly scale with the complexity of its subject matter. Some people naturally write shorter or longer comments as a personal style, but summarizing a 300 line function with "does a thing" is about as good as writing nothing. Conversely, writing a paragraph-level response where a basic one-liner would suffice is no less undesireable.
+  - A comment's verbosity should roughly scale with the complexity of its subject matter. Some people naturally write shorter or longer comments as a personal style, but summarizing a 300 line function with "does a thing" is about as good as writing nothing. Conversely, writing a paragraph-level response where a basic one-liner would suffice is no less undesirable.
   - Long comments should ideally be broken into multiple lines at around the 100-120 character mark. This isn't _mandatory_, but avoids unnecessary scrolling in terminals and IDEs.
 - Make sure comments exist on Functions, Classes, Methods, and Properties
   - These may be the most important things to comment. When someone goes to use a function/class/method/etc., having a comment reduces the need to flip back and forth between files to figure out what XYZ does. Peek Definition is great until you're three nested levels deep.
@@ -16,8 +16,8 @@ While we're not enforcing a strict standard, here are some things to keep in min
 [^1]: With exceptions for extremely long, convoluted or unintuitive methods (though an over-dependency on said comments is likely a symptom of poorly structured code).
 
 # TSDoc
-The codebase makes extensive use of [TSDocs](https://tsdoc.org), which are a TypeScript-specific version of [JSDocs](https://jsdoc.app/about-getting-started)
-that use similar syntax and attach to functions, classes, etc.
+The codebase makes extensive use of [TSDoc](https://tsdoc.org), which is a TypeScript-specific version of [JSDoc](https://jsdoc.app/about-getting-started)
+that uses similar syntax and attaches to functions, classes, etc.
 
 When formatted correctly, these comments are shown within VS Code or similar IDEs just by hovering over the function or object.
 - Functions also show the comment for each parameter as you type them, making keeping track of arguments inside lengthy functions much more clear.
@@ -75,8 +75,8 @@ export class AddSubstituteAttr extends MoveEffectAttr {
 Looking at the example given, you'll notice this contains an `{@linkcode XYZ}` tag in some of the parameters. This provides a clickable hyperlink to that type or object in most modern IDEs. (`@linkcode` is used here instead of `@link` so that the text appears in monospace which is more obviously a `type` rather than a random hyperlink.) \
 Also note the dashes (` - `) between the parameter names and descriptions - these are **mandatory** under the TSDoc spec[^2].
 
-If you're interested in going more in depth, you can find a reference guide for how comments like these work [on the TSDoc website](https://tsdoc.org)
-as well as check out the [playground](https://tsdoc.org/play/) page there that can be used for live testing of examples.
+If you're interested in going more in depth, you can find a reference guide for how comments like these work [on the TSDoc website](https://tsdoc.org).
+The [playground page](https://tsdoc.org/play/) there can also be used for live testing of examples.
 
 [^2]: Incidentally, this is also the only place dashes are explicitly _required_.