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

[Alexander Mikhaylenko <alexm src gnome org>]

commit 6c04481e0386d040b92187bfa6660dfe96de734d
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 | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)
---
diff --git a/CodingStyle.txt b/CodingStyle.txt
index fd38ec05..584ded3e 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.
@@ -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.
@@ -152,7 +152,7 @@ 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:
     * modifiers and the returned type at the beginning of the line;
@@ -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