fix format

Author: Kristian Rother

class_diagram.md

@@ -48,7 +48,6 @@ The core logic of how the snake moves should not change because of that.
 A great thing about class diagrams is that you can create them to code easily.
 The Python `dataclasses` module saves you a lot of typing:
 
-    :::python3
     from dataclasses import dataclass
 
     @dataclass
@@ -74,7 +73,6 @@ But we leave the method bodies empty for now.
 The `@dataclass` automatically creates the `__init__()` and `__repr__()` methods for you, so that you can set and inspect the attribute values.
 The code is already executable:
 
-    :::python3
     pf = PlayingField(size=(10, 10))
     print(pf)
     print(pf.size)
@@ -106,7 +104,6 @@ In Python, one could even state that the data structures are practically *identi
 Using the `@property` decorator, you can translate attributes into each other.
 The following code translates the `size` attribute into two new attributes `size_x` and `size_y`:
 
-    :::python3
     @property
     def size_x(self):
         return self.size[0]
@@ -117,7 +114,6 @@ The following code translates the `size` attribute into two new attributes `size
 
 Now you can use all three attributes without storing redundant data:
 
-    :::python3
     pf = PlayingField(size=(5, 5))
     print(pf.size)
     print(pf.size_x)

coding_style.md

@@ -12,17 +12,14 @@ The **pylint** tool checks whether your code conforms to the PEP8 coding guideli
 
 Install it with
 
-    :::bash
     pip install pylint
 
 Then you can analyze any Python file:
 
-    :::bash
     pylint my_program.py
 
 Or all the files in a folder:
 
-    :::bash
     pyling *.py
 
 ----
@@ -36,7 +33,6 @@ In the output of `pylint`, there are two sections to pay attention to:
 
 At the top of the output from **pylint**, you find a section with warning messages. Each warning contains the line number the warning refers to:
 
-    :::text
     W:117,12:Template.prepare_identifiers: Unused variable 'x'
     C: 32,0: Line too long (88/80)
     C:134,16:Renumerator.get_identifiers_list: Operator not preceded by a space
@@ -47,29 +43,25 @@ These warnings point you to the following issues:
 
 #### Bugs and dead code
 
-    :::text
     W:117,12:Template.prepare_identifiers: Unused variable 'x'
 
 This message indicates that line 117 either won't work or that the code has not been used at all.
 
 #### Coding style
 
-    :::text
     C: 32,0: Line too long (88/80)
     C:134,16:Renumerator.get_identifiers_list: Operator not preceded by a space
 
 Style issues regarding spaces, indentation and line lengths raised by pylint affect readability and are generally easy to fix.
 
 #### Docstrings
 
-    :::text
     C:  1,0: Missing docstring
 
 Functions and classes without docstrings are more difficult to understand. If you get a lot of docstring warnings your code may be hard to understand for someone else.
 
 #### Variable names
 
-    :::text
     C:114,8:Renumerator.prepare_identifiers: Invalid name "fn" (should match [a-z_][a-z0-9_]{2,30}$)
 
 Descriptive variable names are a big plus for code readability. Of course, it does not help much to replace **l** by **data_list** in order to satisfy pylint. But the name **fragment** tells you a lot more than **fn**.
@@ -78,7 +70,6 @@ Descriptive variable names are a big plus for code readability. Of course, it do
 
 Pylint helps to analyze modularization by printing warning messages:
 
-    :::text
     R: 19,0:Renumerator: Too many public methods (30/20)
     R: 32,4:Renumerator.letter_generator: Method could be a function
     R: 45,0:RNAResidue: Too many instance attributes (11/7)
@@ -94,7 +85,6 @@ To assess modularization of a program as a whole, pylint is not the right tool.
 
 At the end of the pylint output you find a score of up to 10 points:
 
-    :::text
     Your code has been rated at 8.18/10
 
 When you have fixed some of the issues, re-run pylint and see your score improve. The score directly measures your success and makes working with pylint very rewarding. 
@@ -109,7 +99,6 @@ A good practice is to disable some types of warnings (those you and your team ag
 
 To ignore PEP8 warnings, create a file `.pylintrc` in your project directory. `pylint` finds it automatically. There you can list the types of warnings you would like to disable:
 
-    :::text
     [pylint]
       disable=C0103,C0111,line-too-long,too-few-public-methods
 

continuous_integration.md

@@ -28,7 +28,6 @@ GitHub Actions needs instructions how to install the program.
 Create a folder `.github/workflows/`. 
 Place a text file `check.yml` into that folder containing the following:
 
-    :::text
     name: run_tests
 
     on:
@@ -78,7 +77,6 @@ Commit and push the changes.
 
 Copy the following code into your `README.md` file:
 
-    :::text
     ![Python application](https://github.com/USER/REPO/workflows/run_tests/badge.svg)
 
 Replace **USER** and **REPO** by the data of your project.
@@ -89,4 +87,4 @@ You should see a red or green badge in the README that updates itself.
 
 ### Authors
 
-**Malte Bonart participated in the writing of this chapter.**
+**Malte Bonart participated in the writing of this chapter.**

documenting.md

@@ -16,7 +16,6 @@ That said, there are a number of good Python tools to build and maintain documen
 
 Running Sphinx could look like this:
 
-    :::bash
     sphinx-build html
 
 Sphinx has its strengths in:
@@ -37,7 +36,6 @@ If you like to know more, check out this **[Talk by Eric Holscher](https://www.y
 
 A very cool feature is that you can run a local documentation server with
 
-    :::bash
     mkdocs serve
 
 and the local website is automatically updated as you edit the Markdown documents.

environment_variables.md

@@ -18,7 +18,6 @@ In this article, you can learn how to set and read environment variables on a Un
 
 Type into the terminal:
 
-    :::bash
     export MY_TEXT=hello
 
 Note the following:
@@ -35,15 +34,13 @@ Note the following:
 
 Type into a terminal:
 
-    :::bash
     echo $MY_TEXT
 
 The Unix `echo` command is the equivalent of `print()` in Python.
 The `$` symbol dereferences the variable.
 
 If you want to see *all* environment variables that are defined, try the command:
 
-    :::bash
     env
 
 The output is usually quite a mess.
@@ -54,7 +51,6 @@ The output is usually quite a mess.
 
 No. Each environment has a local *scope*. Each program has its own variables. That means that typing
 
-    :::bash
     echo $MY_TEXT
 
 in two terminals may yield different results.
@@ -69,13 +65,11 @@ E.g. when you start a Python program from a Unix command line, it receives the c
 If you want **all** programs to have a certain environment variable, add the `EXPORT` statement to a configuration file in your home directory.
 Open the file `.bashrc` (Linux) or `.bash_profile` (MacOS) and add the same line as above:
 
-    :::bash
     export MY_TEXT=hello
 
 The changes are applied as soon as you start a new terminal.
 You can update your environment with:
 
-    :::bash
     source ~/.bashrc
 
 **Note: Restart your Python editor, if you want it to see the new environment variables.**
@@ -86,7 +80,6 @@ You can update your environment with:
 
 You can read an environment variable in two lines:
 
-    :::python3
     import os
 
     text = os.getenv('MY_TEXT')
@@ -109,5 +102,4 @@ Here are a few common ones:
 
 If you want to append a directory to an existing `PATH` or `PYTHONPATH`, this expression is useful:
 
-    :::bash
     export PATH=$PATH:/my/new/dir/

folders.md

@@ -12,7 +12,6 @@ A **Python package** is simply a folder that contains `.py` files.
 Create a folder `snake` inside your repository.
 On the bash terminal, you would use
 
-    :::bash
     mkdir snake
 
 If your git repository is also called `snake`, you may want to rename your project folder to something else like `snake_project`, `snake_repo` or similar.
@@ -26,7 +25,6 @@ You will also want to have a place where you add test code later.
 Name that folder `tests/`.
 We will leave it empty for now.
 
-    :::bash
     mkdir tests
 
 ----
@@ -37,7 +35,6 @@ You may want to create a Python module (a `.py` file) to make sure everything is
 Create a file `game.py` inside the `snake/` folder.
 Add a placeholder function to it:
 
-    :::python3
     def play_snake():
         print('this is a snake game')
 
@@ -59,14 +56,12 @@ Importing the `play_snake()` function to play the game is a bit inconvenient.
 Let's create a shortcut.
 Create a file named `__main__.py` (with double underscores on both ends) in the package folder that contains the following code:
 
-    :::python3
     from game import play_snake
 
     play_snake()
 
 Now it should be possible to start the game by typing:
 
-    :::text
     python snake
 
 ----
@@ -75,7 +70,6 @@ Now it should be possible to start the game by typing:
 
 At this point, your project folder should contain:
 
-    :::text
     LICENSE
     prototype.py
     README.md

github_issues.md

@@ -12,14 +12,12 @@ Go to the **Issues** tab on your repository on GitHub.
 Press the big **New Issue** button on the right side.
 Enter a title for the Issue, e.g.
 
-    :::text
     Features for the Snake Game
 
 In the large text field below, you can add what is to be done.
 There are plenty of controls to format text and attach files (e.g. screenshots).
 One of the buttons lets you create a **Checklist**:
 
-    :::text
     - [ ] there is a wall around the playing field
     - [ ] there is food on the playing field
     - [ ] the snake gets longer when it eats food

good_software.md

@@ -35,8 +35,6 @@ When you use a program, you need to be 100% sure that it does exactly what you t
 
 Each scientific program should include at least one set of sample data. There should be an instruction how to use the sample data and exactly what output it produces. Sometimes, this approach is broken down into small steps: a cookbook explaining small actions and their effect. Eventually, you will find an automatic test suite. This is a script that automatically checks whether different parts of the program work correctly. When you see a message like
 
-
-    :::text
     110 of 110 tests OK.
 
 you know that at least everything the developers felt important to check works.

interface.md

@@ -45,7 +45,6 @@ While both parts may change, the interface should remain stable.
 Let's separate the **User Interface** of the snake game from the **Game Logic**.
 For that, we will define a `SnakeGame` class that will be used as the only point of communication by the user interface:
 
-    :::python3
     class SnakeGame:
 
         running: bool

loc.md

@@ -9,12 +9,10 @@ More code means more work. The amount of code gives you a ballpark figure of how
 
 You can count the total number of files on Unix:
 
-    :::bash
     find . -name "*.py" | wc -l
 
 A common metric is the number of **lines of code (LOC)**. The following command gives you the total number of LOC for all Python files in a Python directory tree:
 
-    :::bash
     find . -name "*.py" | xargs wc -l
 
 Empty lines, docstrings and comments are counted, too, as they are part of the source code.