Fix typos and wording issues

Author: matthiaswenz

project_and_code_guidelines.md

@@ -65,15 +65,15 @@ Layout files should match the name of the Android components that they are inten
 | AdapterView item | ---                    | `item_person.xml`             |
 | Partial layout   | ---                    | `partial_stats_bar.xml`       |
 
-A slighly different case is when we are creating a layout that is going to be inflated by an `Adapter`, e.g to populate a `ListView`. In this case, the name of the layout should start with `item_`
+A slightly different case is when we are creating a layout that is going to be inflated by an `Adapter`, e.g to populate a `ListView`. In this case, the name of the layout should start with `item_`.
 
-Note that there are cases where these rules will not be possible to apply. For example, when creating layout files that are intended to be part of other layouts. In this case you should use the prefix `partial_`
+Note that there are cases where these rules will not be possible to apply. For example, when creating layout files that are intended to be part of other layouts. In this case you should use the prefix `partial_`.
 
 #### 1.2.1.3 Menu files  
 
-Similar to layout files, menu files should match the name of the component. For example, if we are defining a menu file that is going to be use in the `UserActivity`, then the name of the file should be `activity_user.xml`
+Similar to layout files, menu files should match the name of the component. For example, if we are defining a menu file that is going to be used in the `UserActivity`, then the name of the file should be `activity_user.xml`
 
-A good practise is to not include the word `menu` as part of the name because these files are already located in directory called menu. 
+A good practice is to not include the word `menu` as part of the name because these files are already located in the `menu` directory. 
 
 #### 1.2.1.4 Values files
 
@@ -164,15 +164,15 @@ public class MyClass {
 
 ### 2.2.4 Use spaces for indentation
 
-Use __4 space__ idents for blocks:
+Use __4 space__ indents for blocks:
 
 ```java
 if (x == 1) {
     x++;
 }
 ```
 
-Use __8 space__ idents for line wraps:
+Use __8 space__ indents for line wraps:
 
 ```java
 Instrument i =
@@ -222,13 +222,13 @@ According to the Android code style guide, the standard practices for some of th
 
 * `@SuppressWarnings`: The @SuppressWarnings annotation should only be used under circumstances where it is impossible to eliminate a warning. If a warning passes this "impossible to eliminate" test, the @SuppressWarnings annotation must be used, so as to ensure that all warnings reflect actual problems in the code.
 
-More information about annotations guidelines can be found [here](http://source.android.com/source/code-style.html#use-standard-java-annotations).
+More information about annotation guidelines can be found [here](http://source.android.com/source/code-style.html#use-standard-java-annotations).
 
 #### 2.2.6.2 Annotations style
 
 __Classes, Methods and Constructors__
 
-When annotations are applied to a class, method or constructor they are listed after the documentation block and should appear as __one annotation per line__ .
+When annotations are applied to a class, method, or constructor, they are listed after the documentation block and should appear as __one annotation per line__ .
 
 ```java
 /* This is the documentation block about the class */
@@ -264,14 +264,14 @@ The ordering of import statements is:
 
 To exactly match the IDE settings, the imports should be:
 
-* Alphabetical within each grouping, with capital letters before lower case letters (e.g. Z before a).
+* Alphabetically ordered within each grouping, with capital letters before lower case letters (e.g. Z before a).
 * There should be a blank line between each major grouping (android, com, junit, net, org, java, javax).
 
 More info [here](https://source.android.com/source/code-style.html#limit-variable-scope)
 
 ### 2.2.9 Logging guidelines
 
-Use the logging methods provided by the `Log` class to print out error messages or other information that may be useful for developers to identifiy issues:
+Use the logging methods provided by the `Log` class to print out error messages or other information that may be useful for developers to identify issues:
 
 * `Log.v(String tag, String msg)` (verbose)
 * `Log.d(String tag, String msg)` (debug)
@@ -290,8 +290,8 @@ public class MyClass {
     }
 }
 ```
-	
-VERBOSE and DEBUG logs __must__ be disable on relase builds. It is also recommendable to disable INFORMATION, WARNING and ERROR logs but you may want to keep them enable if you think they may be useful to identify issues on release builds. If you decide to leave them enable, you have to make sure that they are not leaking private information such as email addresses, user ids, etc. 
+    
+VERBOSE and DEBUG logs __must__ be disabled on release builds. It is also recommended to disable INFORMATION, WARNING and ERROR logs but you may want to keep them enabled if you think they may be useful to identify issues on release builds. If you decide to leave them enabled, you have to make sure that they are not leaking private information such as email addresses, user ids, etc. 
 
 To only show logs on debug builds:
 
@@ -339,7 +339,7 @@ public class MainActivity extends Activity {
 } 
 ```
 
-If your class is extending and __Android component__ such as an Activity or a Fragment, it is a good practise to order the override methods so that they __match the component's lifecycle__. For example, if you have an Activity that implements `onCreate()`, `onDestroy()`, `onPause()` and `onResume()`, then the correct order is:
+If your class is extending an __Android component__ such as an Activity or a Fragment, it is a good practice to order the override methods so that they __match the component's lifecycle__. For example, if you have an Activity that implements `onCreate()`, `onDestroy()`, `onPause()` and `onResume()`, then the correct order is:
 
 ```java
 public class MainActivity extends Activity {
@@ -355,7 +355,7 @@ public class MainActivity extends Activity {
     public void onPause() {}
 
     @Override 
-    public void onDestory() {}
+    public void onDestroy() {}
 
 }
 ```
@@ -369,18 +369,18 @@ The opposite case are __callback__ interfaces that should always be the __last__
 Examples:
 
 ```java
-// Context always go first
+// Context always goes first
 public User loadUser(Context context, int userId);
 
 // Callbacks always go last
 public void loadUserAsync(Context context, int userId, UserCallback callback);
 ```
 
-### 2.2.13 String constants, naming and values
+### 2.2.13 String constants, naming, and values
 
-Many elements of the Android SDK such as `SharedPreferences`, `Bundle` or `Intent` use a key-value pair approach so it's very likely that even for a small app you end up having to write a lot of String constants.
+Many elements of the Android SDK such as `SharedPreferences`, `Bundle`, or `Intent` use a key-value pair approach so it's very likely that even for a small app you end up having to write a lot of String constants.
 
-When using one of these components, you __must__ define the keys as a `static final` fields and they should be prefixed as indicaded below. 
+When using one of these components, you __must__ define the keys as a `static final` fields and they should be prefixed as indicated below. 
 
 | Element            | Field Name Prefix |
 | -----------------  | ----------------- |
@@ -390,7 +390,7 @@ When using one of these components, you __must__ define the keys as a `static fi
 | Intent Extra       | `EXTRA_`            |
 | Intent Action      | `ACTION_`           |
 
-Note that the arguments of a Fragment - `Fragment.getArguments()` - are also a Bundle. However, because this is a quite common use of Bundles, we define a different prefix for them. 
+Note that the arguments of a Fragment - `Fragment.getArguments()` - are also a Bundle. However, because this is a quite common use of Bundles, we define a different prefix for them.
 
 Example:
 
@@ -407,11 +407,11 @@ static final String ACTION_OPEN_USER = "com.myapp.action.ACTION_OPEN_USER";
 
 ### 2.2.14 Arguments in Fragments and Activities
 
-When data is passed into an `Activity `or `Fragment` via `Intents` or a `Bundles`, the keys for the different values __must__ follow the rules described in the section above.
+When data is passed into an `Activity `or `Fragment` via an `Intent` or a `Bundle`, the keys for the different values __must__ follow the rules described in the section above.
 
-When an `Activity` or `Fragment` expect arguments, it should provide a `static public` method that facilitates the creation of the `Fragment` or `Intent`.
+When an `Activity` or `Fragment` expects arguments, it should provide a `public static` method that facilitates the creation of the relevant `Intent` or `Fragment`.
 
-In the case of Activities the method is usually called `getStartIntent()`
+In the case of Activities the method is usually called `getStartIntent()`:
 
 ```java
 public static Intent getStartIntent(Context context, User user) {
@@ -421,7 +421,7 @@ public static Intent getStartIntent(Context context, User user) {
 }
 ```
 
-For Fragments it's named `newInstance()` and it handles the creation of the Fragment with the right arguments. 
+For Fragments it is named `newInstance()` and handles the creation of the Fragment with the right arguments: 
 
 ```java
 public static UserFragment newInstance(User user) {
@@ -433,18 +433,18 @@ public static UserFragment newInstance(User user) {
 }
 ```
 
-__Note 1__: these methods should go at the top of the class before `onCreate()`
+__Note 1__: These methods should go at the top of the class before `onCreate()`.
 
-__Note 2__: if we provide the methods described above, the keys for extras and arguments should be `private` because there is not need for them to be exposed outside the class. 
+__Note 2__: If we provide the methods described above, the keys for extras and arguments should be `private` because there is not need for them to be exposed outside the class.
 
 ### 2.2.15 Line length limit
 
 Code lines should not exceed __100 characters__. If the line is longer than this limit there are usually two options to reduce its length:
 
-* Extract a local variable or method (Preferable).
+* Extract a local variable or method (preferable).
 * Apply line-wrapping to divide a single line into multiple ones. 
 
-There are two __exceptions__ where is possible to have lines longer than 100:
+There are two __exceptions__ where it is possible to have lines longer than 100:
 
 * Lines that are not possible to split, e.g. long URLs in comments.
 * `package` and `import` statements. 
@@ -464,7 +464,7 @@ int longName = anotherVeryLongVariable + anEvenLongerOne - thisRidiculousLongOne
 
 __Assignment Operator Exception__ 
 
-An exception to the break at operators rule is the assignment operator `=`, where the line break should happen __after__ the operator. 
+An exception to the `break at operators` rule is the assignment operator `=`, where the line break should happen __after__ the operator. 
 
 ```java
 int longName = 
@@ -487,7 +487,7 @@ Picasso.with(context)
 
 __Long parameters case__
 
-When a method has many parameters or its parameters are very long we should break the line after every comma `,`
+When a method has many parameters or its parameters are very long, we should break the line after every comma `,`
 
 ```java
 loadPicture(context, "http://ribot.co.uk/images/sexyjoe.jpg", mImageViewProfilePicture, clickListener, "Title of the picture");
@@ -527,7 +527,7 @@ public Observable<Location> syncLocations() {
 
 ### 2.3.1 Use self closing tags
 
-When an XML element doesn't have any content, you __must__ use self closing tags.
+When an XML element doesn\'t have any contents, you __must__ use self closing tags.
 
 This is good:
 
@@ -541,7 +541,7 @@ This is good:
 This is __bad__ :
 
 ```xml
-<!-- Don't do this! -->
+<!-- Don\'t do this! -->
 <TextView
     android:id="@+id/text_view_profile"
     android:layout_width="wrap_content"
@@ -552,7 +552,7 @@ This is __bad__ :
 
 ### 2.3.2 Resources naming 
 
-Resource IDs and names are written in __lowercase_underscore__
+Resource IDs and names are written in __lowercase_underscore__.
 
 #### 2.3.2.1 ID naming
 
@@ -587,7 +587,7 @@ Menu example:
 
 #### 2.3.2.2 Strings
 
-String names start with a prefix that indentifies the section they belong to. For example `registration_email_hint` or `registration_name_hint`. If a string __doesn't belong__ to any section then you should follow the rules below:
+String names start with a prefix that identifies the section they belong to. For example `registration_email_hint` or `registration_name_hint`. If a string __doesn\'t belong__ to any section, then you should follow the rules below:
 
 
 | Prefix             | Description                           |
@@ -617,22 +617,22 @@ As a general rule you should try to group similar attributes together. A good wa
 
 ### 2.4.1 Unit tests 
 
-Test classes should match the name of the class that the tests are targeting, followed by `Test`. For example, if we create a test class that contains tests for the `DatabaseHelper`, we should name it `DatabaseHelperTest`.
+Test classes should match the name of the class the tests are targeting, followed by `Test`. For example, if we create a test class that contains tests for the `DatabaseHelper`, we should name it `DatabaseHelperTest`.
 
-Test methods are annotated with `@Test` and should generally start with the name of the method that is being tested, followed by a precondition and/or expected behaviour. 
+Test methods are annotated with `@Test` and should generally start with the name of the method that is being tested, followed by a precondition and/or expected behaviour.
 
 * Template: `@Test void methodNamePreconditionExpectedBehaviour()`
 * Example: `@Test void signInWithEmptyEmailFails()`
 
 Precondition and/or expected behaviour may not always be required if the test is clear enough without them. 
 
-Sometimes a class may contain a large amount of methods, that at the same time require several tests for each method. In this case, it's recommendable to split up the test class into multiple ones. For example, if the `DataManager` contains a lot of methods we may want to divide it into `DataManagerSignInTest`, `DataManagerLoadUsersTest`, etc. Generally you will be able to see what tests belong together because they have common [test fixtures](https://en.wikipedia.org/wiki/Test_fixture). 
+Sometimes a class may contain a large amount of methods, that at the same time require several tests for each method. In this case, it\'s recommendable to split up the test class into multiple ones. For example, if the `DataManager` contains a lot of methods we may want to divide it into `DataManagerSignInTest`, `DataManagerLoadUsersTest`, etc. Generally you will be able to see what tests belong together because they have common [test fixtures](https://en.wikipedia.org/wiki/Test_fixture). 
 
 ### 2.4.2 Espresso tests
 
 Every Espresso test class usually targets an Activity, therefore the name should match the name of the targeted Activity followed by `Test`, e.g. `SignInActivityTest`
 
-When using the Espresso API is a common practise to place chained methods in new lines. 
+When using the Espresso API it is a common practice to place chained methods in new lines. 
 
 ```java
 onView(withId(R.id.view))