You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is actually a four-step process. To streamline this chapter, we’re just providing the main steps for this process below. However, there are more detailed instructions available in the following locations:
In the appendix of this book, there are detailed instructions for setting up your system for both PC and MacOS. As these websites might change after we write this book, we encourage you to use a combination of the link above and the appendix together.
13
+
*In the appendix of this book, there are detailed instructions for setting up your system for both PC and MacOS. As these websites might change after we write this book, we encourage you to use a combination of the link above and the appendix together.
14
14
15
-
In the online book forum, you can ask for help and see a list of answers to frequently asked questions.
15
+
*In the online book forum, you can ask for help and see a list of answers to frequently asked questions.
16
16
17
17
The primary steps you’ll need to accomplish are as follows:
Now that you have your system set up, let’s get acquainted with the VSCode interface shown in figure 2.1. (You may need to click on the “Explorer” icon in the middle/top left to have this same view.) The following regions are identified in figure 2.1:
10
10
11
-
Activity Bar - on the far left is the activity bar where we can open file folders or install extensions (as you did to install the Github Copilot extension in the previous section).
11
+
*Activity Bar - on the far left is the activity bar where we can open file folders or install extensions (as you did to install the Github Copilot extension in the previous section).
12
12
13
-
Side Bar – shows what is presently open in the Activity Bar. In figure 2.1, the Activity Bar has the “Explorer” selected and hence the Side Bar is showing the files in the present folder.
13
+
*Side Bar – shows what is presently open in the Activity Bar. In figure 2.1, the Activity Bar has the “Explorer” selected and hence the Side Bar is showing the files in the present folder.
14
14
15
-
Editor Pane(s) - these are the primary areas we will be using to create our software. The editor in the Editor Pane is similar to any other text editor in that you can write text, edit text, copy and paste using the clipboard, and so on. What is special about it, however, is that it is designed to work well with code. As we’ll see in the next example, you will be primarily working in this window by asking Copilot to generate code and then testing that code.
15
+
*Editor Pane(s) - these are the primary areas we will be using to create our software. The editor in the Editor Pane is similar to any other text editor in that you can write text, edit text, copy and paste using the clipboard, and so on. What is special about it, however, is that it is designed to work well with code. As we’ll see in the next example, you will be primarily working in this window by asking Copilot to generate code and then testing that code.
16
16
17
-
Output and Terminal Panel – this is the area of the interface for seeing the output of your code or any errors that have occurred. It has the tabs “Problems”, “Output”, “Debug Console”, and “Terminal.” We will primarily be using the “Problems” tab where we can see potential errors in our code and the “Terminal” tab that allows us to interact with Python and will be where we see the output of our code.
17
+
*Output and Terminal Panel – this is the area of the interface for seeing the output of your code or any errors that have occurred. It has the tabs “Problems”, “Output”, “Debug Console”, and “Terminal.” We will primarily be using the “Problems” tab where we can see potential errors in our code and the “Terminal” tab that allows us to interact with Python and will be where we see the output of our code.
18
18
19
19
We highlighted the Copilot logo in the bottom right of figure 2.1 as you should be seeing this symbol (or similar) if you setup Copilot properly in the previous section.
We already mentioned that functions are critical in performing problem decomposition. Beyond problem decomposition, functions are valuable in software for a number of other reasons, including:
10
10
11
-
**Cognitive Load.** You may have heard of cognitive load \[1\] before. It’s the amount of information your brain can handle at any given time and still be effective. If you are given four random words and asked to repeat them back, you might be able to do that. If you are given the same task with 20 words, most of us would fail as it’s too much information to handle at once. Similarly, if you’ve ever been on a road trip with your family and are trying to optimize the travel time, combined with stops for the kids, lunch breaks, bathroom stops, gas station stops, good locations for hotels, and so on, you might have felt your head swimming
11
+
***Cognitive Load.** You may have heard of cognitive load \[1\] before. It’s the amount of information your brain can handle at any given time and still be effective. If you are given four random words and asked to repeat them back, you might be able to do that. If you are given the same task with 20 words, most of us would fail as it’s too much information to handle at once. Similarly, if you’ve ever been on a road trip with your family and are trying to optimize the travel time, combined with stops for the kids, lunch breaks, bathroom stops, gas station stops, good locations for hotels, and so on, you might have felt your head swimming
12
12
13
13
14
14
15
15
to manage all those constraints at once. That point when you can’t handle it all at once is when you’ve exceeded your own brain’s processing power. Programmers have the same problem. If they are trying to do too much at once or solve too complex a problem in one piece of code, they struggle to do it correctly. Functions are designed to help programmers avoid doing too much work at once.
16
16
17
-
**Avoid Repetition.** Programmers (and, we’d argue, humans in general) aren’t very excited about solving the same problem over and over. If I write a function that can correctly compute the area of a circle once, I don’t need to write that code ever again. That means if I have two sections of my code that need to compute the area of a circle, I’d write one function that computes the area of the circle and then I’d have my code call that function in each of those two places.
17
+
***Avoid Repetition.** Programmers (and, we’d argue, humans in general) aren’t very excited about solving the same problem over and over. If I write a function that can correctly compute the area of a circle once, I don’t need to write that code ever again. That means if I have two sections of my code that need to compute the area of a circle, I’d write one function that computes the area of the circle and then I’d have my code call that function in each of those two places.
18
18
19
-
**Improve Testing.** It's a lot harder to test a section of code that does multiple things compared to code that does one thing. Programmers at companies use a variety of testing techniques, but a key technique is known as _unit testing_. Every function takes some input and produces some output. For a function that computes the area of a circle, for example, the input would be the circle’s radius and the output would be its area. Unit tests give a function an input and then compare that input to the desired result. For the area-of-a-circle function, we might test it by giving it varying inputs (e.g., some small positive numbers, some large positive numbers, and 0) and compare the result of the function against the values we know to be correct. If the answers from the function match what we expect, we have a higher degree of confidence that the code is correct. If the code produces a mistake, we won’t have much code to check to find and fix the problem. But if a function does more than one task, it vastly complicates the testing process as you need to test each task and the interaction of those tasks.
19
+
* **Improve Testing.** It's a lot harder to test a section of code that does multiple things compared to code that does one thing. Programmers at companies use a variety of testing techniques, but a key technique is known as _unit testing_. Every function takes some input and produces some output. For a function that computes the area of a circle, for example, the input would be the circle’s radius and the output would be its area. Unit tests give a function an input and then compare that input to the desired result. For the area-of-a-circle function, we might test it by giving it varying inputs (e.g., some small positive numbers, some large positive numbers, and 0) and compare the result of the function against the values we know to be correct. If the answers from the function match what we expect, we have a higher degree of confidence that the code is correct. If the code produces a mistake, we won’t have much code to check to find and fix the problem. But if a function does more than one task, it vastly complicates the testing process as you need to test each task and the interaction of those tasks.
20
20
21
-
**Improve Reliability.** When we write code as experienced software engineers, we know we make mistakes. We also know Copilot makes mistakes. If you imagine you are an amazing programmer and each line of code you write is 95% likely to be correct, how many lines of code do you think you can write before at least one of those lines is likely to be incorrect? The answer ends up being only 14. We think 95% correctness per line is probably a high bar for even experienced programmers and is likely a higher bar than what Copilot produces. By keeping the tasks
22
-
23
-
24
-
25
-
small, things solvable in 12-20 lines of code, we reduce the likelihood that there’s an error in the code. If combined with good testing as noted above, we can feel even more confident that the code is correct. Lastly, nothing is worse than code that has multiple mistakes that interact together, and the likelihood of multiple mistakes grows the more code you write. Both of us have been on multi-hour debugging expeditions because our code had more than one mistake and, for both of us, we became a lot better at frequent testing of short pieces of code as a result! **Improve Code Readability**. In this book, we’re going to mostly use Copilot to write code from scratch. But that’s not the only way to use Copilot. If you have a larger piece of software that you or your coworkers are all editing and using, Copilot can jump in to help write code for that, too. It’s in everyone’s interest to understand the code, whether most of it is written by humans or by Copilot. That way, we can find bugs more easily, determine what code to start modifying when we want to add new features, and understand at a high level what would be easy or difficult to achieve with our overall program design. Having tasks broken down into functions helps us understand what each part of the code is doing so we can gain a better understanding of how it all works together. It also helps divide up the work and responsibility for ensuring the code is correct.
21
+
* **Improve Reliability.** When we write code as experienced software engineers, we know we make mistakes. We also know Copilot makes mistakes. If you imagine you are an amazing programmer and each line of code you write is 95% likely to be correct, how many lines of code do you think you can write before at least one of those lines is likely to be incorrect? The answer ends up being only 14. We think 95% correctness per line is probably a high bar for even experienced programmers and is likely a higher bar than what Copilot produces. By keeping the tasks small, things solvable in 12-20 lines of code, we reduce the likelihood that there’s an error in the code. If combined with good testing as noted above, we can feel even more confident that the code is correct. Lastly, nothing is worse than code that has multiple mistakes that interact together, and the likelihood of multiple mistakes grows the more code you write. Both of us have been on multi-hour debugging expeditions because our code had more than one mistake and, for both of us, we became a lot better at frequent testing of short pieces of code as a result! **Improve Code Readability**. In this book, we’re going to mostly use Copilot to write code from scratch. But that’s not the only way to use Copilot. If you have a larger piece of software that you or your coworkers are all editing and using, Copilot can jump in to help write code for that, too. It’s in everyone’s interest to understand the code, whether most of it is written by humans or by Copilot. That way, we can find bugs more easily, determine what code to start modifying when we want to add new features, and understand at a high level what would be easy or difficult to achieve with our overall program design. Having tasks broken down into functions helps us understand what each part of the code is doing so we can gain a better understanding of how it all works together. It also helps divide up the work and responsibility for ensuring the code is correct.
26
22
27
23
These benefits are huge for programmers. Programming languages haven’t always had functions. But even before they did, programmers did their best to use other features to mimic functions. They were ugly hacks (Google “goto statements” if you’re interested), and all programmers are happy that we have proper functions now.
Copy file name to clipboardExpand all lines: content/chapter-3/330.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -56,13 +56,13 @@ Continuing this example, the next line of the code executed will be the line tha
56
56
57
57
So, we’re back in funct1, on the line print(""). Printing an empty piece of text just causes a new line. Now funct1 is finished, so it transfers execution back to the next line in main after it was called. We suspect you are getting the idea by now, so let’s move a bit more quickly:
58
58
59
-
Main next prints “I'm” and then calls funct4.
59
+
*Main next prints “I'm” and then calls funct4.
60
60
61
-
funct4 prints “well” and then returns back to main where the next line of code calls funct3.
61
+
*funct4 prints “well” and then returns back to main where the next line of code calls funct3.
62
62
63
-
funct3 prints a “.” and then returns back to main. Notice that funct3 was called both by funct1 and by main, but that’s okay because functions remember how to return back to the function that called them. In fact, having multiple functions calling the same function is a sign that the function being called multiple times is a good function, because of its reuse.
63
+
*funct3 prints a “.” and then returns back to main. Notice that funct3 was called both by funct1 and by main, but that’s okay because functions remember how to return back to the function that called them. In fact, having multiple functions calling the same function is a sign that the function being called multiple times is a good function, because of its reuse.
64
64
65
-
After funct3 returns to main, it will print a “” which causes a new line to be started, and then it prints the word “Bye.”
65
+
*After funct3 returns to main, it will print a “” which causes a new line to be started, and then it prints the word “Bye.”
66
66
67
67
> Figure 3.2 Flow of function execution in our example from listing 3.1.
0 commit comments