[gnome-games/wip/exalm/typos: 6/6] coding-style: Fix typos

[Alexander Mikhaylenko <alexm src gnome org>]

commit 924954a75e94def4ce3dd8a13e3ae4b9d661e744
Author: Alexander Mikhaylenko <exalm7659 gmail com>
Date:   Sun Sep 2 21:47:00 2018 +0500

    coding-style: Fix typos
    
    Also don't abbreviate 'In other words'.

 CodingStyle.txt | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)
---
diff --git a/CodingStyle.txt b/CodingStyle.txt
index fd38ec05..40452401 100644
--- a/CodingStyle.txt
+++ b/CodingStyle.txt
@@ -39,15 +39,15 @@ Vala projects.
                         out this.sort_criteria);
 
  * ''Prefer'' descriptive names over abbreviations (unless well-known)
-   & shortening of names. E.g discoverer over disco.
+   & shortening of names. E.g. discoverer over disco.
 
  * Use 'var' in variable declarations wherever possible.
 
- * Don't use var when declaring a number from a litteral.
+ * Don't use var when declaring a number from a literal.
 
  * Use 'as' to cast wherever possible.
 
- * Single statments inside if/else must not be enclosed by '{}'.
+ * Single statements inside if/else must not be enclosed by '{}'.
 
  * The more you provide docs in comments, but at the same time avoid
    over-documenting. Here is an example of useless comment:
@@ -56,7 +56,7 @@ Vala projects.
    fetch_the_document ();
 
  * Each class should go in a separate .vala file & named according to
-   the class in it, in spinal-case. E.g Games.GameSource class should
+   the class in it, in spinal-case. E.g. Games.GameSource class should
    go under game-source.vala.
 
  * Don't use any 'using' statement.
@@ -74,7 +74,7 @@ Vala projects.
 
  * Prefer properties over methods whenever possible.
 
- * Declare properties getters befor the setters.
+ * Declare properties getters before the setters.
 
  * Add a newline to break the code in logical pieces.
 
@@ -108,7 +108,7 @@ Vala projects.
  * Add a newline at the end of each file.
 
  * If a function returns several equally important values, they should
-   all be given as out arguments. IOW, prefer this:
+   all be given as out arguments. In other words, prefer this:
 
    void get_a_and_b (out string a, out string b)
 
@@ -116,11 +116,11 @@ Vala projects.
 
  * Use methods as callbacks to signals.
 
- * ''Prefer'' operators over methods when possible. E.g prefer
+ * ''Prefer'' operators over methods when possible. E.g. prefer
    'collection[key]' over 'collection.get(key)'.
 
  * If a function or a method can be used as a callback, don't enclose
-   it in a lambda. E.g do 'do (callback)' rather than
+   it in a lambda. E.g. do 'do (callback)' rather than
    'do (() => callback ())'.
 
  * Limit the try blocks to the code throwing the error.
@@ -140,7 +140,7 @@ Vala projects.
    same as the previous closing brace.
 
  * Internationalize error messages, which implies using printf style
-   string contruction rather than string templates.
+   string construction rather than string templates.
 
  * Append the original error message to the one you are building when
    refining an error.
@@ -152,9 +152,9 @@ projects.
 
  * ''Prefer'' lines of less than <= 80 columns
 
- * Functions with no parameter should state it with the 'void' keyword.
+ * Functions with no parameters should state it with the 'void' keyword.
 
- * In C files, function definitions are splitted in lines that way:
+ * In C files, function definitions are split into lines that way:
     * modifiers and the returned type at the beginning of the line;
     * the function name and the first parameter (if any) at the
       beginning of the line;
@@ -162,7 +162,7 @@ projects.
       parameter;
     * the opening curly brace at the beginning of the line.
 
- * In header files, function definitions are splitted in lines that way:
+ * In header files, function definitions are split into lines that way:
     * modifiers, the returned type, the function name and the first
       parameter (if any) at the beginning of the line;
     * each extra parameter has its own line, aligned with the first
@@ -174,9 +174,9 @@ projects.
  * 1-space between function name and braces (both calls and signature).
 
  * ''Prefer'' descriptive names over abbreviations (unless well-known)
-   & shortening of names. E.g discoverer over disco.
+   & shortening of names. E.g. discoverer over disco.
 
- * No single statment blocks.
+ * No single statement blocks.
 
  * The more you provide docs in comments, but at the same time avoid
    over-documenting. Here is an example of useless comment:
@@ -185,7 +185,7 @@ projects.
    fetch_the_document ();
 
  * Each class should go in a separate .c and .h file & named according
-   to the class in it, in spinal-case. E.g Games.GameSource class should
+   to the class in it, in spinal-case. E.g. Games.GameSource class should
    go under game-source.h and game-source.c.
 
  * Add a newline to break the code in logical pieces.
@@ -208,7 +208,7 @@ projects.
  * Add a newline at the end of each file.
 
  * If a function returns several equally important values, they should
-   all be given as out arguments. IOW, prefer this:
+   all be given as out arguments. In other words, prefer this:
 
    void get_a_and_b (gchar **a, gchar **b)
 
@@ -220,7 +220,7 @@ projects.
  * Always add a comma after the enumerated value of an enum type broken
    into multiple lines.
 
- * Always add a comma after values of an array litteral broken into
+ * Always add a comma after values of an array literal broken into
    multiple lines.
 
  * Any 'else', 'else if' block or any other special block following