Minor grammar fixes

Grammarly caught some missing articles, some misspellings, etc.

Author: dingo-d

wordpress-coding-standards/php.md

@@ -133,7 +133,7 @@ Note that requiring the use of braces just means that _single-statement inline c
 
 Using long array syntax ( `array( 1, 2, 3 )` ) for declaring arrays is generally more readable than short array syntax ( `[ 1, 2, 3 ]` ), particularly for those with vision difficulties. Additionally, it's much more descriptive for beginners.
 
-Arrays must be declared using long array syntax.
+Arrays must be declared using the long array syntax.
 
 ### Closures (Anonymous Functions)
 
@@ -237,11 +237,11 @@ Incorrect:
 
 ### Remove Trailing Spaces
 
-Remove trailing whitespace at the end of each line of code. Omitting the closing PHP tag at the end of a file is preferred. If you use the tag, make sure you remove trailing whitespace.
+Remove trailing whitespace at the end of each line of code. Omitting the closing PHP tag at the end of a file is preferred. If you use the tag, make sure you remove the trailing whitespace.
 
 ### Space Usage
 
-Always put spaces after commas, and on both sides of logical, comparison, string and assignment operators.
+Always put spaces after commas, and on both sides of the logical, comparison, string, and assignment operators.
 
 ```php
 x === 23
@@ -327,7 +327,7 @@ my_function( ( $x - 1 ) * 5, $y );
 
 ### Formatting SQL statements
 
-When formatting SQL statements you may break it into several lines and indent if it is sufficiently complex to warrant it. Most statements work well as one line though. Always capitalize the SQL parts of the statement like `UPDATE` or `WHERE`.
+When formatting SQL statements you may break them into several lines and indent if it is sufficiently complex to warrant it. Most statements work well as one line though. Always capitalize the SQL parts of the statement like `UPDATE` or `WHERE`.
 
 Functions that update the database should expect their parameters to lack SQL slash escaping when passed. Escaping should be done as close to the time of the query as possible, preferably by using `$wpdb->prepare()`
 
@@ -340,7 +340,7 @@ $id = some_foo_number(); // data we expect to be an integer, but we're not certa
 $wpdb->query( $wpdb->prepare( "UPDATE $wpdb->posts SET post_title = %s WHERE ID = %d", $var, $id ) );
 ```
 
-`%s` is used for string placeholders and `%d` is used for integer placeholders. Note that they are not 'quoted'! `$wpdb->prepare()` will take care of escaping and quoting for us. The benefit of this is that we don't have to remember to manually use [`esc_sql()`](https://developer.wordpress.org/reference/functions/esc_sql/), and also that it is easy to see at a glance whether something has been escaped or not, because it happens right when the query happens.
+`%s` is used for string placeholders and `%d` is used for integer placeholders. Note that they are not 'quoted'! `$wpdb->prepare()` will take care of escaping and quoting for us. The benefit of this is that we don't have to remember to manually use [`esc_sql()`](https://developer.wordpress.org/reference/functions/esc_sql/), and also that it is easy to see at a glance whether something has been escaped or not because it happens right when the query happens.
 
 See [Data Validation](https://developer.wordpress.org/plugins/security/data-validation/) in the Plugin Handbook for further details.
 
@@ -377,7 +377,7 @@ Files should be named descriptively using lowercase letters. Hyphens should sepa
 my-plugin-name.php
 ```
 
-Class file names should be based on the class name with `class-` prepended and the underscores in the class name replaced with hyphens, for example `WP_Error` becomes:
+Class file names should be based on the class name with `class-` prepended and the underscores in the class name replaced with hyphens, for example, `WP_Error` becomes:
 
 ```php
 class-wp-error.php
@@ -456,7 +456,7 @@ Dynamic hooks should be named using interpolation rather than concatenation for
 
 Dynamic hooks are hooks that include dynamic values in their tag name, e.g. `{$new_status}_{$post->post_type}` (publish_post).
 
-Variables used in hook tags should be wrapped in curly braces `{` and `}`, with the complete outer tag name wrapped in double quotes. This is to ensure PHP can correctly parse the given variables' types within the interpolated string.
+Variables used in hook tags should be wrapped in curly braces `{` and `}`, with the complete outer tag name wrapped in double-quotes. This is to ensure PHP can correctly parse the given variables' types within the interpolated string.
 
 ```php
 do_action( "{$new_status}_{$post->post_type}", $post->ID, $post );
@@ -568,7 +568,7 @@ switch ( $foo ) {
 
 The `goto` statement must never be used.
 
-The `eval()` construct is _very dangerous_, and is impossible to secure. Additionally, the `create_function()` function, which internally performs an `eval()`, is deprecated in PHP 7.2. Neither of these must be used.
+The `eval()` construct is _very dangerous_ and is impossible to secure. Additionally, the `create_function()` function, which internally performs an `eval()`, is deprecated in PHP 7.2. Neither of these must be used.
 
 ### Error Control Operator `@`
 
@@ -584,6 +584,6 @@ While this operator does exist in Core, it is often used lazily instead of doing
 
 Per [#22400](https://core.trac.wordpress.org/ticket/22400 "Remove all, or at least most, uses of extract() within WordPress"):
 
-> `extract()` is a terrible function that makes code harder to debug and harder to understand. We should discourage it's [sic] use and remove all of our uses of it.
+> `extract()` is a terrible function that makes code harder to debug and harder to understand. We should discourage its (sic) use and remove all of our uses of it.
 
 Joseph Scott has [a good write-up of why it's bad](https://blog.josephscott.org/2009/02/05/i-dont-like-phps-extract-function/).