Lecture 5 8/24/18. Writing larger programs. Comments. What are we going to cover today? Using Comments. Comments in Python. Writing larger programs

Size: px

Start display at page:

Download "Lecture 5 8/24/18. Writing larger programs. Comments. What are we going to cover today? Using Comments. Comments in Python. Writing larger programs"

Joanna Flynn
5 years ago
Views:

1 What are we going to cover today? Lecture 5 Writing and Testing Programs Writing larger programs Commenting Design Testing Writing larger programs As programs become larger and more complex, it becomes more and more important to plan out how they will work. One subfield of computer science, called software engineering, deals with the processes for constructing large pieces of software. We re not going to be handling large software in this course, but some of the principles for good software construction practice still apply. Today, we ll look at a couple of them. Comments Comments are descriptive text placed into the code of the program. Comments (for the most part) are NOT executed. They are purely for human benefit, not for the computer! As the computer reads through the code, comments are just skipped over. Comments are meant to help people understand what the purpose of the code is. Others who will read your code You, when you come back to your code in the future You, when you are dealing with a large program that s hard to keep track of Comments in Python To create a comment in Python, you can place a # in front of the comment you want. The # and everything after it on that line are totally ignored # Here is a comment before a line of code a = 3 # Here is a comment at the end of a line of code # b = 4 This whole line is a comment: the b = 4 part is not executed Using Comments You should use comments to: Describe the purpose of a line or a section of code Define the purpose of a particular variable Clarify a computation that is not present Give a reference to some external source that a person reading the code might need to be aware of Clearly separate sections of code from each other Do not use comments to: Restate what should be obvious from reading the code Add things that are irrelevant to the code itself Except for header information required for our class! 1

2 The comment that s not a comment Sometimes, you will see people use a triple-quoted string as a type of comment. Either with single quotes or double quotes: ''' or """ Basically, you can put anything in a triple-quoted string, but not assign the string to anything, and the string is effectively ignored, thus it s like a comment. a = 3 ''' This is a string that spans multiple lines, and that acts sort-of like a comment ''' People sometimes use this when they want a comment spanning multiple lines. But, it is better practice not to use this! Later, we ll see a real use for this sort of comment Visual Breaks in Code Whitespace refers to blank lines and spaces in code Whitespace can be used to separate different sections of the code. Helps identify sections of the code that have different purposes a = 3 b = 5 print( The sum is, a+b) Sometimes, comments are used to provide visual breaks: ################################## ##### New Section ##### Program Design When faced with a large task, the first thing to do is to think. This goes for almost anything: building a house, designing a bridge, etc. Writing software is the same way: think before writing code! Usually, the time spent thinking about a problem before trying to solve it will save more time later. There are many approaches to program design, but all of them involve stopping to think about design before trying to implement. A first approach to program design Consider the major stages the program will follow Typically, a sequence of operations e.g. Get input from user -> Perform calculation -> Output result List these in order (outside of a program) Convert your steps of the program to comments Fill in the regions between comments with code Example (initial steps/design): Task: write a program to calculate a person s BMI and output their weight category. Steps: 1. Read user s height and weight 2. Calculate BMI 3. Output weight category Example: Making steps into comments #Read user's height and weight #Calculate BMI #Output weight category 2

3 Example: Filling in code Writing Tests #Read user's height and weight height = float(input("enter height in inches: ")) weight = float(input("enter weight in pounds: ")) #Calculate BMI BMI = weight/(height*height)*709 #Output weight category if BMI < 18.5: print("underweight") elif BMI <=25: print("normal Weight") elif BMI <=30: print("overweight") else: print("obese") To find if a program is working, you need to test it! Never assume it s working without testing You will need to understand what your code should do This is sometimes more difficult than it might seem you often are writing a program since it is difficult to do the same thing by hand Tests should be basic input to a program (or part of a program) where you know what you should expect as output Tests could be values you enter as a user Tests could be values of variables set in the code Writing Tests (ideally) Ideally, write your tests before you write your program This will help you think through what the program should be doing This will give you a way to test your code as soon as you write it Sometimes it helps to have someone write tests who is not writing the code Ideally, if you do a good job writing tests, then if your code passes all tests, it should work. Realistically, people often write tests after writing (at least some) code and don t write sufficiently thorough tests How to write tests Test the Typical case You usually don t need to test too many of these just enough to ensure the program is basically working Test the edge cases or corner cases These are the special cases, that are less common/typical Example: on a chess board: The typical case would be a square near the middle (touching 8 other squares) Would also want to test edge squares (touching 5 other squares), and corner squares (touching 3 other squares) This is where the term edge case or corner case comes from! Exercise: Coming up with tests Imagine a program that had to process dates in a year What dates would you test? Exercise: Coming up with tests Imagine a program that had to process dates in a year What dates would you test? Typical: some dates in middle of year: e.g. May 25 or November 9 Some edge cases: First/last days of months: July 1, June 30, July 31, February 28 First/last day of the year: January 1, December 31 Special case: February 29 3

to fix it! This is called debugging: find where the program is failing, determine the error, and fix it.

4 Implementing Tests If you have a complete program, you can test the whole process. But, it often helps to test just a piece of the program. To do this: Can read in values from a user Can set variable values to specific test cases Can print out values at various points using print statements When you find something doesn t work, you need to fix it! This is called debugging: find where the program is failing, determine the error, and fix it. Later, we will learn more formal debugging approaches An analogy for software construction There are two common architectural forms, both of which have produced structures that have lasted since ancient times: Pyramids Arches An analogy for software construction Though both pyramids and arches end up with good structures, the way they are built is quite different. Pyramid: Place stones at the bottom. Once stones underneath are set, place more on top of them. Arch: Place all stones in the arch, holding it up with temporary scaffolding. Place all stones in the arch before removing the scaffolding. An analogy for software construction With Pyramids, you can stop at any point You always have a stable structure. You can test the lower levels before adding upper levels With Arches, you can t stop at an intermediate point The structure is not stable until every stone is in place You can t really test the arch until all pieces are there So, how does this relate to software construction? Incremental Development Sometimes, people try to follow the arch style of development with their code Only after they ve written all of the code do they stop to test/evaluate it If any one piece is missing or broken, the whole program falls apart! The pyramid style lets you develop incrementally You can write small pieces of code, test them, and ensure that they are working before adding more code You always have a stable piece of software, even when not complete! When building software, try to use a pyramid process, not an arch process! Example Let s see development of a piece of code. Back to our learning example, let s say we want to compute the concepts learned getting a time of study from a user and computing how much they can expect to learn Rate of Learning 2. But perhaps there is a warm-up period where we remember what we had learned before 1. We might assume a constant learning rate 3. And, maybe when we get fatigued we learn worse Time since start of study session 4

5 Thinking about the problem What information will we need to perform the computation? Initial rate of learning Length of study session Time at which warmup stops Constant rate of learning Time when fatigue begins Time we stop learning anything new Rate of Learning Thinking about the problem What information will we need to perform the computation? Initial rate of learning Length of study session Time at which warmup stops Constant rate of learning Time when fatigue begins Time we stop learning anything new What variables will we use? (might find we need more later) rate_initial, rate_constant time_constant, time_fatigue, time_stop study_time Time since start of study session What will our general process be? Set up specific model for learning Setting variable values will hard-code them Read time from user Calculate the amount learned Output result to user Writing Code Writing Code Testing Typically, we should stop and test after each section But, for this simple program, the setup has very little we can test it s just variable assignment. We WILL stop and test future sections. 5

6 Testing study_time = input("how long will you study? ") We ll want to see if we re reading the data correctly. Let s add a single print statement in to output what we read in. study_time = input("how long will you study? ") print("entered: ", study_time) Testing Run the program, see if the input matches output. How long will you study? 10 Entered: 10 OK, it seems like it s working But was that enough of a test? Maybe we want to make sure we can do something with the value, so we might also want to test that we can compute with it Let s try, say, adding 1 to the value we read in. study_time = input("how long will you study? ") print("entered: ", study_time) Now test: How long will you study? 10 Entered: 10 Traceback (most recent call last): File "C:/Users/John/PycharmProjects/ENGR102/Test Development.py", line 12, in <module> TypeError: must be str, not int Process finished with exit code 1 Oh no! What happened that was an error! If you read the output from the failure, it gives us a hint as to what went wrong That won t always be the case, but it is, here How long will you study? 10 Entered: 10 Traceback (most recent call last): File "C:/Users/John/PycharmProjects/ENGR102/Test Development.py", line 12, in <module> TypeError: must be str, not int Process finished with exit code 1 Line number is shown, along with the statement on that line. And, it says we have a TypeError We tried to add a number to a string! 6

7 Fix the bug: study_time = input("how long will you study? ") We forgot to convert the input from a string to a number! print("entered: ", study_time) This is where the program failed, but it s not where the error is. print("entered: ", study_time) Now re-test Writing tests How long will you study? 10 Entered: 10.0 Adding 1: 11.0 Process finished with exit code 0 Before we write the next section, computing study, let s think of some tests. Study times to test: Typical points: during the warmup, during the constant period, during the fatigue period Edge cases: 0, at transition points, negative values, values past stop point Looks good, now We could do more tests, but for illustration, let s move on. Rate of Learning Time since start of study session Other tests Need to come up with specific values for learning model, and should test with multiple such values Will need to determine actual values. For the values we ve put into code, we could test study times, and expect values of: 0: 0 8: : : : : : : (after stop period) -1: 0 (before) Now write code Code will require if-elif-else statements Went through an example in last lecture Will add comments throughout Need a new variable to store answer: concepts_learned And maybe some others along the way! Test pieces incrementally First write and test the warmup calculation Then write and test the constant period of time Then write and test fatigue period Test all the other cases Will use the overall output as our test output, in this instance. 7

8 Now test warmup period Test for time 0, time 8, time 15 For this example, we won t have more bugs in the code, but in general, you might find them if (study_time >=0) and (study_time <= time_constant): #warmup period end_learn_rate = rate_initial + (rate_constant - rate_initial) / time_constant * study_time concepts_learned = study_time * (rate_initial + end_learn_rate) / 2 print("you learned",concepts_learned,"concepts in that time.") Adding constant period (then should test) Adding fatigue period (then should test) if (study_time >=0) and (study_time <= time_constant): if (study_time >=0) and (study_time <= time_constant): #warmup period #warmup period end_learn_rate = rate_initial + (rate_constant - rate_initial) / time_constant * study_time end_learn_rate = rate_initial + (rate_constant - rate_initial) / time_constant * study_time concepts_learned = study_time * (rate_initial + end_learn_rate) / 2 concepts_learned = study_time * (rate_initial + end_learn_rate) / 2 elif (study_time > time_constant) and (study_time <= time_fatigue): elif (study_time > time_constant) and (study_time <= time_fatigue): #constant period #constant period concepts_learned = 2.25 #concepts learned during warmup concepts_learned = 2.25 #concepts learned during warmup concepts_learned += rate_constant * (study_time - time_constant) concepts_learned += rate_constant * (study_time - time_constant) elif (study_time > time_fatigue) and (study_time <= time_stop): #fatique period print("you learned",concepts_learned,"concepts in that time.") concepts_learned = #concepts learned through constant period end_learn_rate = (study_time - time_fatigue) / (time_stop-time_fatigue) concepts_learned += (study_time - time_fatigue) * (rate_constant * end_learn_rate) / 2 print("you learned",concepts_learned,"concepts in that time.") if (study_time >=0) and (study_time <= time_constant): #warmup period end_learn_rate = rate_initial + (rate_constant - rate_initial) / time_constant * study_time concepts_learned = study_time * (rate_initial + end_learn_rate) / 2 elif (study_time > time_constant) and (study_time <= time_fatigue): #constant period concepts_learned = 2.25 #concepts learned during warmup concepts_learned += rate_constant * (study_time - time_constant) elif (study_time > time_fatigue) and (study_time <= time_stop): #fatique period concepts_learned = #concepts learned through constant period end_learn_rate = (study_time - time_fatigue) / (time_stop-time_fatigue) concepts_learned += (study_time - time_fatigue) * (rate_constant * end_learn_rate) / 2 elif (study_time > time_stop): #post-fatque: nothing more to learn concepts_learned = else: #negative time - nothing can be learned! concepts_leanred = 0 Adding before/after periods (then should test) Summary Think about the program What do you need to do Determine key variables Write some comments Think about testing (the earlier the better) Code incrementally Test each section of code after you write it print("you learned",concepts_learned,"concepts in that time.") 8

9 For more complex programs As the computation becomes more complex, design will increase in importance. There are more formalized methods for ways of designing We ll see a couple of these, top-down and bottom-up, later in the course 9

Difference Between Dates Case Study 2002 M. J. Clancy and M. C. Linn

Difference Between Dates Case Study 2002 M. J. Clancy and M. C. Linn Problem Write and test a Scheme program to compute how many days are spanned by two given days. The program will include a procedure