Merge pull request #390 from sihart25/issue-316

remove ABV isn't and others

README.md

@@ -56,7 +56,7 @@ label ![pilot](https://shields.io/badge/-pilot-31E930).
 We welcome all contributions to improve the lesson! Maintainers will do their best to help you if you have any
 questions, concerns, or experience any difficulties along the way.
 
-We'd like to ask you to familiarise yourself with our [Contribution Guide](CONTRIBUTING.md) and have a look at
+We would like to ask you to familiarise yourself with our [Contribution Guide](CONTRIBUTING.md) and have a look at
 the [more detailed guidelines][lesson-example] on proper formatting, instructions on compiling and rendering the lesson locally, and 
 making any changes and adding new content or episodes.
 

_episodes/00-setting-the-scene.md

@@ -25,8 +25,8 @@ So, you have gained basic software development skills either by self-learning or
 e.g., a [novice Software Carpentry course][swc-lessons].
 You have been applying those skills for a while by writing code to help with your work
 and you feel comfortable developing code and troubleshooting problems.
-However, your software has now reached a point where there’s too much code to be kept in one script.
-Perhaps it's involving more researchers (developers) and users,
+However, your software has now reached a point where there is too much code to be kept in one script.
+Perhaps it is involving more researchers (developers) and users,
 and more collaborative development effort is needed to add new functionality
 while ensuring previous development efforts remain functional and maintainable.
 

_episodes/10-section1-intro.md

@@ -20,7 +20,7 @@ and introducing the project that we will be working on throughout the course.
 In order to build working (research) software efficiently
 and to do it in collaboration with others rather than in isolation,
 you will have to get comfortable with using a number of different tools interchangeably
-as they’ll make your life a lot easier.
+as they will make your life a lot easier.
 There are many options when it comes to deciding
 which software development tools to use for your daily tasks -
 we will use a few of them in this course that we believe make a difference.
@@ -124,6 +124,6 @@ Therefore, one should be aware of these guidelines
 and adhere to whatever the project you are working on has specified.
 In Python, we will be looking at a convention called PEP8.
 
-Let's get started with setting up our software development environment!
+Let us get started with setting up our software development environment!
 
 {% include links.md %}

_episodes/11-software-project.md

@@ -246,7 +246,7 @@ A novice will often make up the structure of their code as they go along.
 However, for more advanced software development,
 we need to plan and design this structure - called a *software architecture* - beforehand.
 
-Let's have a quick look into what a software architecture is
+Let us have a quick look into what a software architecture is
 and which architecture is used by our software project
 before we start adding more code to it.
 

_episodes/12-virtual-environments.md

@@ -25,7 +25,7 @@ the `requirements.txt` file."
 ## Introduction
 So far we have cloned our software project from GitHub and inspected its contents and architecture a bit.
 We now want to run our code to see what it does -
-let's do that from the command line.
+let us do that from the command line.
 For the most part of the course we will run our code
 and interact with Git from the command line.
 While we will develop and debug our code using the PyCharm IDE
@@ -236,7 +236,7 @@ This will create the target directory for the virtual environment
 > and avoid issues that could prove difficult to trace and debug.
 {: .callout}
 
-For our project let's create a virtual environment called "venv".
+For our project let us create a virtual environment called "venv".
 First, ensure you are within the project root directory, then:
 
 ~~~
@@ -342,7 +342,7 @@ When you’re done working on your project, you can exit the environment with:
 ~~~
 {: .language-bash}
 
-If you've just done the `deactivate`,
+If you have just done the `deactivate`,
 ensure you reactivate the environment ready for the next part:
 
 ~~~
@@ -565,7 +565,7 @@ In the above command, we tell the command line two things:
 As we can see, the Python interpreter ran our script, which threw an error -
 `inflammation-analysis.py: error: the following arguments are required: infiles`.
 It looks like the script expects a list of input files to process,
-so this is expected behaviour since we don't supply any.
+so this is expected behaviour since we do not supply any.
 We will fix this error in a moment.
 
 ## Optional exercises

_episodes/13-ides.md

@@ -80,10 +80,10 @@ and Microsoft's free [Visual Studio Code (VS Code)](https://code.visualstudio.co
 
 ## Using the PyCharm IDE
 
-Let's open our project in PyCharm now and familiarise ourselves with some commonly used features.
+Let us open our project in PyCharm now and familiarise ourselves with some commonly used features.
 
 ### Opening a Software Project
-If you don't have PyCharm running yet, start it up now.
+If you do not have PyCharm running yet, start it up now.
 You can skip the initial configuration steps which just go through
 selecting a theme and other aspects.
 You should be presented with a dialog box that asks you what you want to do,
@@ -156,7 +156,7 @@ and PyCharm is clever enough to understand it.
    so we can also use this environment for other projects if we wish.
 6. Select `OK` in the `Add Python Interpreter` window.
    Back in the `Preferences` window, you should select "Python 3.11 (python-intermediate-inflammation)"
-   or similar (that you've just added) from the `Project Interpreter` drop-down list.
+   or similar (that you have just added) from the `Project Interpreter` drop-down list.
 
 Note that a number of external libraries have magically appeared under the
 "Python 3.11 (python-intermediate-inflammation)" interpreter,
@@ -170,7 +170,7 @@ and has added these libraries effectively replicating our virtual environment in
 Also note that, although the names are not the same -
 this is one and the same virtual environment
 and changes done to it in PyCharm will propagate to the command line and vice versa.
-Let's see this in action through the following exercise.
+Let us see this in action through the following exercise.
 
 > ## Exercise: Compare External Libraries in the Command Line and PyCharm
 > Can you recall two places where information about our project's dependencies
@@ -314,15 +314,15 @@ You can also verify this from the command line by
 listing the `venv/lib/python3.11/site-packages` subdirectory.
 Note, however, that `requirements.txt` is not updated -
 as we mentioned earlier this is something you have to do manually.
-Let's do this as an exercise.
+Let us do this as an exercise.
 
 > ## Exercise: Update `requirements.txt` After Adding a New Dependency
 > Export the newly updated virtual environment into `requirements.txt` file.
 >
 >  
 >> ## Solution
->> Let's verify first that the newly installed library `pytest` is appearing in our virtual environment
->> but not in `requirements.txt`. First, let's check the list of installed packages:
+>> Let us verify first that the newly installed library `pytest` is appearing in our virtual environment
+>> but not in `requirements.txt`. First, let us check the list of installed packages:
 >> ~~~
 >> (venv) $ python3 -m pip list
 >> ~~~
@@ -412,7 +412,7 @@ and use on top of virtual environments.
    (i.e. the virtual environment and interpreter you configured earlier in this episode)
    in the `Python interpreter` field.
 5. You can give this run configuration a name at the top of the window if you like -
-   e.g. let's name it `inflammation analysis`.
+   e.g. let us name it `inflammation analysis`.
 6. You can optionally configure run parameters and environment variables in the same window -
    we do not need this at the moment.
 7. Select `Apply` to confirm these settings.
@@ -438,15 +438,15 @@ and use on top of virtual environments.
 Now you know how to configure and manipulate your environment in both tools
 (command line and PyCharm),
 which is a useful parallel to be aware of.
-Let's have a look at some other features afforded to us by PyCharm.
+Let us have a look at some other features afforded to us by PyCharm.
 
 ### Syntax Highlighting
 The first thing you may notice is that code is displayed using different colours.
 Syntax highlighting is a feature that displays source code terms
 in different colours and fonts according to the syntax category the highlighted term belongs to.
 It also makes syntax errors visually distinct.
 Highlighting does not affect the meaning of the code itself -
-it's intended only for humans to make reading code and finding errors easier.
+it is intended only for humans to make reading code and finding errors easier.
 
 ![Syntax Highlighting Functionality in PyCharm](../fig/pycharm-syntax-highlighting.png){: .image-with-shadow width="1000px" }
 
@@ -569,7 +569,7 @@ We will get back to this error shortly -
 for now, the good thing is that we managed to set up our project for development
 both from the command line and PyCharm and are getting the same outputs.
 Before we move on to fixing errors and writing more code,
-let's have a look at the last set of tools for collaborative code development
+Let us have a look at the last set of tools for collaborative code development
 which we will be using in this course - Git and GitHub.
 
 

_episodes/14-collaboration-using-git.md

@@ -36,7 +36,7 @@ test it to make sure it works correctly and as expected,
 then record your changes using version control
 and share your work with others via a shared and centrally backed-up repository.
 
-Firstly, let's remind ourselves how to work with Git from the command line.
+Firstly, let us remind ourselves how to work with Git from the command line.
 
 ## Git Refresher
 Git is a version control system for tracking changes in computer files
@@ -117,7 +117,7 @@ Software development lifecycle with Git
 </p>
 
 ## Checking-in Changes to Our Project
-Let's check-in the changes we have done to our project so far.
+Let us check-in the changes we have done to our project so far.
 The first thing to do upon navigating into our software project's directory root
 is to check the current status of our local working directory and repository.
 
@@ -162,7 +162,7 @@ and stop notifying us about it.
 Edit your `.gitignore` file in PyCharm
 and add a line containing "venv/" and another one containing ".venv/".
 It does not matter much in this case where within the file you add these lines,
-so let's do it at the end.
+so let us do it at the end.
 Your `.gitignore` should look something like this:
 
 ~~~
@@ -256,7 +256,7 @@ $ git pull
 ~~~
 {: .language-bash}
 
-Now we've ensured our repository is synchronised with the remote one,
+Now we have ensured our repository is synchronised with the remote one,
 we can now push our changes:
 
 ~~~
@@ -324,11 +324,11 @@ $ git branch
 ~~~
 {: .output}
 
-At the moment, there's only one branch (`main`)
+At the moment, there is only one branch (`main`)
 and hence only one version of the code available.
 When you create a Git repository for the first time,
 by default you only get one version (i.e. branch) - `main`.
-Let's have a look at why having different branches might be useful.
+Let us have a look at why having different branches might be useful.
 
 ### Feature Branch Software Development Workflow
 While it is technically OK to commit your changes directly to `main` branch,
@@ -341,7 +341,7 @@ Each feature branch should have its own meaningful name -
 indicating its purpose (e.g. "issue23-fix").
 If we keep making changes and pushing them directly to `main` branch on GitHub,
 then anyone who downloads our software from there will get all of our work in progress -
-whether or not it's ready to use!
+whether or not it is ready to use!
 So, working on a separate branch for each feature you are adding is good for several reasons:
 
 * it enables the main branch to remain stable
@@ -382,7 +382,7 @@ Whichever is the case for you, a good rule of thumb is -
 nothing that is broken should be in `main`.
 
 ### Creating Branches
-Let's create a `develop` branch to work on:
+Let us create a `develop` branch to work on:
 
 ~~~
 $ git branch develop
@@ -435,7 +435,7 @@ the commits will happen on the `develop` branch
 and will not affect the version of the code in `main`.
 We add and commit things to `develop` branch in the same way as we do to `main`.
 
-Let's make a small modification to `inflammation/models.py` in PyCharm,
+Let us make a small modification to `inflammation/models.py` in PyCharm,
 and, say, change the spelling of "2d" to "2D" in docstrings for functions
 `daily_mean()`,
 `daily_max()` and
@@ -505,7 +505,7 @@ $ git push -u origin develop
 > We still prefer to explicitly state this information in commands.
 {: .callout}
 
-Let's confirm that the new branch `develop` now exist remotely on GitHub too.
+Let us confirm that the new branch `develop` now exist remotely on GitHub too.
 From the `Code` tab in your repository in GitHub,
 click the branch dropdown menu (currently showing the default branch `main`).
 You should see your `develop` branch in the list too. 
@@ -526,7 +526,7 @@ $ git push origin develop
 {: .language-bash}
 
 > ## What is the Relationship Between Originating and New Branches?
-> It's natural to think that new branches have a parent/child relationship
+> it is natural to think that new branches have a parent/child relationship
 > with their originating branch,
 > but in actual Git terms, branches themselves do not have parents
 > but single commits do.

_episodes/15-coding-conventions.md

@@ -65,7 +65,7 @@ a description of a new feature in Python, etc.
 > However, know when to be inconsistent -
 > sometimes style guide recommendations are just not applicable.
 > When in doubt, use your best judgment.
-> Look at other examples and decide what looks best. And don't hesitate to ask!
+> Look at other examples and decide what looks best. And do not hesitate to ask!
 >
 {: .callout}
 
@@ -279,7 +279,7 @@ Avoid extraneous whitespace in the following situations:
   augmented assignment (+=, -= etc.),
   comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is not),
   booleans (and, or, not).
-- Don't use spaces around the = sign
+- Do not use spaces around the = sign
   when used to indicate a keyword argument assignment
   or to indicate a default value for an unannotated function parameter
      ~~~
@@ -319,7 +319,7 @@ e.g HTTPServerError)
 
 As with other style guide recommendations - consistency is key.
 Follow the one already established in the project, if there is one.
-If there isn't, follow any standard language style (such as
+If there is not, follow any standard language style (such as
 [PEP 8](https://www.python.org/dev/peps/pep-0008/) for Python).
 Failing that, just pick one, document it and stick to it.
 
@@ -362,7 +362,7 @@ A good rule of thumb is to assume that someone will *always* read your code at a
 and this includes a future version of yourself.
 It can be easy to forget why you did something a particular way in six months' time.
 Write comments as complete sentences and in English
-unless you are 100% sure the code will never be read by people who don't speak your language.
+unless you are 100% sure the code will never be read by people who do not speak your language.
 
 > ## The Good, the Bad, and the Ugly Comments
 > As a side reading, check out the
@@ -396,9 +396,9 @@ def fahr_to_cels(fahr):
 ~~~
 {: .language-python}
 
-Python doesn't have any multi-line comments,
+Python does not have any multi-line comments,
 like you may have seen in other languages like C++ or Java.
-However, there are ways to do it using *docstrings* as we'll see in a moment.
+However, there are ways to do it using *docstrings* as we will see in a moment.
 
 The reader should be able to understand a single function or method
 from its code and its comments,
@@ -416,7 +416,7 @@ and comments must be accurate and updated with the code,
 because an incorrect comment causes more confusion than no comment at all.
 
 > ## Exercise: Improve Code Style of Our Project
-> Let's look at improving the coding style of our project.
+> let us look at improving the coding style of our project.
 > First, from the project root, use `git switch` to create a new feature branch called `style-fixes`
 > from our develop branch.
 > (Note that at this point `develop` and `main` branches
@@ -494,7 +494,7 @@ because an incorrect comment causes more confusion than no comment at all.
 >>     (and class) definitions with two blank lines).
 >>     Note how PyCharm is warning us by underlining the whole line below.
 >>
->> Finally, let's add and commit our changes to the feature branch.
+>> Finally, let us add and commit our changes to the feature branch.
 >> We will check the status of our working directory first.
 >>
 >> ~~~
@@ -515,7 +515,7 @@ because an incorrect comment causes more confusion than no comment at all.
 >>
 >> Git tells us we are on branch `style-fixes`
 >> and that we have unstaged and uncommited changes to `inflammation-analysis.py`.
->> Let's commit them to the local repository.
+>> let us commit them to the local repository.
 >>
 >> ~~~
 >> $ git add inflammation-analysis.py
@@ -706,7 +706,7 @@ help(fibonacci)
 > >
 > > As expected, Git tells us we are on branch `style-fixes`
 > > and that we have unstaged and uncommited changes to `inflammation/models.py`.
-> > Let's commit them to the local repository.
+> > Let us commit them to the local repository.
 > > ~~~
 > > $ git add inflammation/models.py
 > > $ git commit -m "Docstring improvements."
@@ -719,7 +719,7 @@ In the previous exercises, we made some code improvements on feature branch `sty
 We have committed our changes locally but
 have not pushed this branch remotely for others to have a look at our code
 before we merge it onto the `develop` branch.
-Let's do that now, namely:
+Let us do that now, namely:
 
 - push `style-fixes` to GitHub
 - merge `style-fixes` into `develop` (once we are happy with the changes)
@@ -742,7 +742,7 @@ $ git push origin main
 {: .language-bash}
 
 > ## Typical Code Development Cycle
-> What you've done in the exercises in this episode mimics a typical software development workflow -
+> What you have done in the exercises in this episode mimics a typical software development workflow -
 > you work locally on code on a feature branch,
 > test it to make sure it works correctly and as expected,
 > then record your changes using version control