Commit 56662a59 authored by Alexander Mikhaylenko's avatar Alexander Mikhaylenko

coding-style: Fix typos

Also don't abbreviate 'In other words'.
parent 7cbd0c17
Pipeline #28403 passed with stages
in 41 minutes and 39 seconds
......@@ -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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment