Apply suggestions from code review

Author: ChmielewskiKamil

program-analysis/echidna/Exercise-X.md

@@ -33,7 +33,7 @@ Depending on your framework, the `NaughtCoin` contract will be in the `src` fold
 
 ### Exercise goals
 
-The main goal is to make the player's balance equal to `0`.  You might know the answer right away. However, the purpose of this exercise is to define the whole system using properties in an iterative way. Start small and see what you can find. Expand over time. Here are some steps that you may take:
+The main goal is to make the player's balance equal to `0`.  You might know the answer right away. However, the purpose of this exercise is to describe the whole system using properties in an iterative way. Start small and see what you can find. Expand over time. Here are some steps that you may take:
 
 1. Before writing any code, look at the NaughtCoin contract and think of 4-5 invariants that need to be held in this contract and write them down. The more, the better. You will be able to validate your assumptions about the system with Echidna. Be creative!
 2. Create a simple `ExternalTest` contract with a proper state setup. Who is the player? Does he have the tokens?
@@ -102,13 +102,13 @@ If you are stuck at any point, feel free to look at the following hints. You can
   
   import {NaughtCoin} from "src/NaughtCoin.sol";
   
-  contract ExternalTestSimple {
+  contract ExternalTest {
    address player;
       NaughtCoin public naughtCoin;
   
       constructor() {
        player = msg.sender;
-          naughtCoin = new NaughtCoin(player);
+      naughtCoin = new NaughtCoin(player);
       }
   }
    ```
@@ -143,7 +143,7 @@ If you are stuck at any point, feel free to look at the following hints. You can
   <summary>2nd property</summary>
 
    ```
-   function sender_balance_is_equal_to_initial_supply() public {
+   function player_balance_is_equal_to_initial_supply() public {
         assert(naughtCoin.balanceOf(player) == naughtCoin.INITIAL_SUPPLY());
     }
    ```
@@ -156,7 +156,7 @@ If you are stuck at any point, feel free to look at the following hints. You can
   In plain English we have defined this invariant as The player token balance should equal the initial supply if the current `block.timestamp < timelock`. The second part of this sentence specifies exactly when this property should be tested.
 
    ```
-   function sender_balance_is_equal_to_initial_supply() public {
+   function player_balance_is_equal_to_initial_supply() public {
         // pre-conditions
         uint256 currentTime = block.timestamp;
         if (currentTime < naughtCoin.timeLock()) {
@@ -299,7 +299,7 @@ Run Echidna and check the corpus. Now we have fully covered this property.
 
   The token transfer via `transferFrom` should fail if the current `block.timestamp < timelock` and/or spender has enough allowance.
 
-  This property in its base form is the same as the one with `transfer` function.
+  This property in its base form is the same as the one with the `transfer` function.
 
    ```
    function transfer_from_should_fail_before_timelock_period(uint256 amount)
@@ -328,7 +328,7 @@ Run Echidna and see what you get. Echidna emits the `AssertionFailed` event with
 
 The property `playerBalance == InitialSupply` still holds. You need to guide Echidna a little bit more for it to invalidate this property.
 
-Try to get into the mindset of exploring the system you are auditing. Since, we have discovered something new about the system, a `transferFrom` function does not fail, as we initially expected, the next logical step would be to test this functionality and make sure that it works properly.
+Try to get into the mindset of exploring the system you are auditing. Since we have discovered something new about the system, a `transferFrom` function does not fail, as we initially expected, the next logical step would be to test this functionality and ensure that it works properly.
 
 Try to write a property for the `transferFrom` function.
 
@@ -380,7 +380,7 @@ Try to write a property for the `transferFrom` function.
 
 #### Fixing a bug
 
-Last step is to fix a bug that you have found. Try to fix it and re-run your properties. Check if they hold.
+The last step is to fix a bug that you have found. Try to fix it and re-run your properties. Check if they hold.
 
 <details>
   <summary>Fixing a bug part 1</summary>
@@ -406,7 +406,7 @@ Add a `Player(address player)` event to your contract and emit it in your proper
 
 The player's address is `0x0000...3000`. Echidna is making calls from multiple accounts. It was able to increase the allowance of an address `0x000...1000` and make a call to `transferFrom(player, 0x000...1000, amount)`. This is expected!
 
-The `lockTokens` modifier does not prevent others from making transfers, only the player is constrained.
+The `lockTokens` modifier does not prevent others from making transfers. Only the player is constrained.
 
 ```
 // Prevent the initial owner from transferring tokens until the timelock has passed