# MPHY0021 - Day 9 (9th December 2021)

:::info
## :tada: Welcome to the ninth day! Construction & design :hammer: :triangular_ruler:

### Today
Today we will look at
- which factors affect coding choices
- rewriting code to improve it
:::

### :stopwatch: Time keeper
- [name=Thomas Clarke] :raised_hand: 5' before the end.
- 10:00 - 10:50
- 11:05 - 11:55
- 12:05 - 12:55

### Review from last week

- Waterfall and agile methodologies
- Communication and progress monitoring in collaborative projects

#### What was covered during the week :newspaper:

- Readability of code
- Refactoring
- Object-oriented design

### Understanding quiz

Help us understand how this week's preparation work went with [mentimeter](https://www.menti.com/6rk6kmb1n4) (or code `1096 1879`)

### Groups :handshake:

We will be using the breaking rooms functionality of Zoom.

:::danger
Remember to `rename` yourself by clicking on your zoom name (in the participants list) and change it to:
`SGX - Your name` being `X` the number of the group you have been assigned to.

If you disconnect and connect again, please rename yourself again.
:::

### Discussion
:::warning
:question: **What else is important for your code, other than correctness?**

- Write Notes in the class pad for your group.
- Nominate or volunteer one person for each group to feedback.
- Problem with group (e.g. only one person) - select your operating system in the [zoom help](https://support.zoom.us/hc/en-us/articles/115005769646-Participating-in-Breakout-Rooms) and use the `ask for help` section to get our attention!
:::

- Group 1:
- consistent code style
- easy to read
- enough commits and comments
- easy to test
- Group 2:Performance, clarity
- Group 3:
- easy to read and well-commented
- easy to maintain
- Group 4:
- Readability
- Run speed
- Clarity
- Structure
- Avoid repeats (use functions)
- Amount of RAM it takes to run
- Group 5:
- Readability of code is important as when looking at some else's code it should be easy to understand what is going on.
- East to maintain the code.

- Group 6:
- Variable names should be easy to understand and meaningful
- Use clear and complete comments to tell your partner what the variables mean and what the function does
- Optimize the algorithm to reduce time complexity
- Group 7:
- Group 8:
- Group 9:
- Well commented so you can come back and know what it does
- Instructive variable names
- Efficient - avoid repetition and e.g. use list comprehension instead of loops
- Good structure (e.g. OOP)
- Exploit python libraries (avoid unecessarily creating complicated methods)
- Appropriate error messages that tell you the problem
- Easy to read - avoid long lines of code - separate them
- Group 10:
- Keep each line shorter
- Use functions to save time coding and make code more readable
- Group 11:
- Efficiency - code should be simple and run at a good speed
- Structure - separated into sections and separate functions
- Readability - Easy for other users to understand and use the code
- Group 12:
Understandibility
Documentation
Readable code
Good variable names
Decrease use of repeated variables (Being efficient)
Better algorithm use (Faster, less space and memory)

- Group 13:

- Group 14:
- Simplicity/Easy to be used and called/Understandable/Enough Comments/Up-to-date/Better structure/
- Group 15:
- Readability
- Well-structured / modular
- Testable
- Useful error functionality
- Comments where needed
- Consistent naming conventions
- Agile and waterfall
- Group 16:
- Readability
- Modularity
- Good error messages - helps debug

- Group 17:
- Simplicity
- Readability
- Efficiency
- Good structure
- Group 18:
- Group 19:
- Performance
- Easy to understand/expressive
- Efficiency/Concise
- Structure - use of functions and classes etc
- Good documentation and comments
- No repetition of code
- Group 20:
- Efficency- using the best python libraries in the best ways
- Optimising memory useage
- Making the most out of availible hardware (i.e. hardware accelerators)
- A *Quantum Advantage* :)
- Suitable structure (i.e OOP vs functions when best suited)
- Readability/ user-friendliness
- Group 21:
- Readability
- Efficency
- Robustness
-
- Group 22:
- Easy to read and maintain
- Performance
- Memory
- Documentation
- Group 23:
- Readability
- Optimal performance
- Good documentation
- Memory optimization
- Group 24:
- Readability
- Clean
- Code easy to change
- Performance: ie. avoid unecessary for loops, avoid repetition of code
- Good documentation so that other collaborators can understand
- Group 25:
- Group 26:
- Group 27:
- Group 28:
- Group 29:

### Exercise: Improving code - Part 1
:::info

For this exercise, we will look at an existing piece of code and see how it can be improved.

Based on your group number, look at the following code:
| Group number | Code sample |
|--: | - |
|1-10 |[Tree plots](https://github.com/UCL-MPHY0021-21-22/refactoring-examples/tree/main/trees)|
|11-20|[Sample analysis](https://github.com/UCL-MPHY0021-21-22/refactoring-examples/tree/main/analysis) |
|21-29|[The Boids](https://github.com/UCL-MPHY0021-21-22/refactoring-examples/tree/main/boids) |

You will find a brief description of each example in its README file.

- First, discuss the code with your group. What problems do you see with it? Why?
- Write down your comments in the space below. For now, focus on the problems, and don't make any changes yet!
- Nominate one person from your group to feed back to the class.

If you need help, you can ask for us to drop in, following [these instructions](https://www.youtube.com/watch?v=yIOMPRLQIHA).
:::

Leave your comments here.

- Group 1:
- It's working out some graph
- Not so sure about the meaning of codes
- There are some coordinates
- Group 2:
- The loop can be written in a function to make the code easier for others to read
- unclear variable names
- stop hard-coding and more comments
- add more information in image (e.g. title)
- Group 3:
- The variable names are not clear
- Line 11 and 12 can be written in a function
- Use variable rather than number in Line 5
- Should comment what 0.6 stands for in Line 16
- Can improve the plot by indicating the axes and title
- Group 4:
- clarify order of opperations
- variable names are not descriptive
- add comments
- add doc string explaining the function
- is 1st for loop needed?
- write the function for calculating line 11
- have different list name for line 11 and 12
- Group 5:
- The variable names should be descriptive of what they actually are.
- The code could use another data structure rather than lists
- Add more useful comment(i.e. Why to use these codes)
- Maybe put the method in a function, so it could be used in other scripts.
- Could more in the plt.plot call such as plot title or axis title.
- the initial docstring could be more descriptive as to what the code is acutally doing.
- Group 6:
- array/variable names not very descriptive
- specify elements of list being appended beforehand so clear what they are
- loop range(5) unclear and too specific
- save arrays into variable before passing into plt.plot
- Group 7:
- Group 8:
- Group 9:
- Not entirely clear what it actually does
- Make the names of the variables more descriptive
- Assign a name to the initial variables in the plot
- Add axis labels and title
- Specify plot size (as the defualt might not be very readable)
- More descriptive comments
- Replace one of the for loops with a list comprehension
- Group 10:
- Lack of comment
- Should write all code in a function and call it in "main"
- The calculations to be done in "append" is better to be put into a function
- names of variables are unclear
- Separate data computing and plotting
- Group 11:
- Reading of data repeated 3 times when it could use a function.
- within the reading theres is unnecessary loops
- Final if statement is not needed, last line already outputs the correct value of critical
- comments to make code clearer
- use of optimised functions from external libraries
- clearer variable names
- Group 12:
- Add some comments for understandibility
- Add callable functions for brevity
- Remove obvious comments
- Group 13:
- The data reading can be simplified into one for loop
- Lack of comments of code
- The names of variables are complex and hard to understood by code reader
- The for loop of appending data into collection named result can be simplified as one function
- Group 14:
- Commom problems existing in both file:
- Reading data can be reformatted into functions
- Write some comments to help users
- Meaningful variable names (not just data1)
- Use external packages like numpy and pandas to read data into dataframe
- Group 15:
- Both two files need comments to show their functions at the beginning
- For the same content of two codes, use a function may be better
- Create classes of data analysis and builder, one for reading csv files, another one for calculating and analysis
- Compared with using append(), conprehension can be much more clear
- NumPy can be used in these codes to create arraries
- Group 16:
- Group 17:
- Documentation or comments to explain what the code does!
- Could write a function to do similar tasks (i.e. read data)
- Rename variables to help understanding
- Explain why you have commented out code
- Not obvious the difference between workflow1 and workflow2
- Group 18:
- Group 19:
- workflow1.py:
- Could implement functions rather than repeating blocks of code (i.e opening the file)
- Could replace loop with iterator
- Improve readability - comments, documentation and variable names
- workflow2.py:
- Unnecessary comments
- Create functions rather than repeating code (again)
- Use iterator instead of a loop
- Unclear variable names
- dsum = dsum + ... could be rewritten as a sum instead of a for loop
- Group 20:
- workflow1.py:
- The docstring is a bit vague (for trees)
- "They read data from files and compute some made-up summary measure." Vague
- Using arrays would be better than using 2 nested lists
- The file name is hardcoded and doesn't allow the user to have their own file structure
- They should use a function for the file reading part
- workflow2.py
- arrays (as with 1)
- Perhaps have some comments explaining all the open stuff [common to both]
- Some comments explaining the difference between workflow 1 and 2 would be helpful
- Commented out code is redunant (i.e. a debugging step that was left in the committ)
- "critical" was commented out
- Group 21:
- Name the variables
- Break up the update_boids into different fuctions
- Write a function to replace the "for" fucntion
- Create classes
- Group 22:
- No comments and documentation
- Use class to represent the boid
- Unclear variable names
- Replace numbers with variables
- Break the function update_boids into several functions
- Merge for loops into one loop
- Group 23:
- Create a variable for the number of birds, instead of having just 50. Also, renaming the name of the variable so that they are more clear and informative.
- Improve readability of the code by adding more comments.
- Data structure could be optimized. Create a class that initiates boids position and velocities, instead of having list comprehensions.
- Compressing some of the for loops and adding all the if statements inside for the three different cases.
- Define a gebnearl function for the calculations in each for loop.
- Group 24:
-Add more comments - sometimes the code is not clear at explaining what it is doing
-Define constants as variables, with a descriptive meaningful variable name
-Compressing some of the for loops, such that the code is not too long
-update_boids() should be several functions, perhaps split into 4 functions, each corresponding to the code under each comment.
- Group 25:
- Group 26:
- Group 27:
- Group 28:
- Group 29:

### Exercise: Improving code - Part 2
:::info

Based on the problems you identified and the previous discussion, how can you improve the code?
**First**, take around 5 minutes to plan your changes.
**Once that is done**, start making changes according to your plan.

To get the files on your computer and push them back:
1. Fork the repository
1. Clone your fork
3. (make changes, commit...)
4. Push back to your fork

You can submit a Pull Request for [the original repository](https://github.com/UCL-MPHY0021-21-22/refactoring-examples) when you have made some change.
- You don't have to wait until they're all done!
- Target the `main` branch of the original repository
- Indicate the example you have worked on in the title of the PR, e.g. "Boids: rename variables"

If you need help, you can ask for us to drop in, following [these instructions](https://www.youtube.com/watch?v=yIOMPRLQIHA).
:::

### Understanding quiz

Go back to [mentimeter](https://www.menti.com/6rk6kmb1n4) (or code `1096 1879`) for some final questions.

### Homework
- [Gradual refactoring](https://moodle.ucl.ac.uk/mod/url/view.php?id=2604554)
- commit and push, then create a PR for the classwork on refactoring
- Preparation for week 10: performance

# Questions

:::info
Feel free to add any question below. Remember the syntax:

- Example question
  - [name=student_a] Example answer
  - [name=TA_1] Example answer

:::

- will we receive an email when CW 1 results are released? (to not be refreshing the cw page every hour every day :) )
- [name=Stef] We're aiming to have the results released by the end of next week but we'll send an announcement when they're ready
- When will the secound coursework be released?
- [name=Stef] We're aiming to set the second coursework for the 15th of December
- .
- [name=...]

###### tags: `mphy0021` `teaching` `class`