CSCA08 Winter 2018 Week 3: Logical Operations, Design Recipe. Marzieh Ahmadzadeh, Brian Harrington University of Toronto Scarborough

Transcription

1 CSCA08 Winter 2018 Week 3: Logical Operations, Design Recipe Marzieh Ahmadzadeh, Brian Harrington University of Toronto Scarborough

2 Administrative Detail ex1 is up TT #1 and TT #2 info. can be found on course website. Room allocation will be announced later. FSG is on 2

3 Boolean Is another type defined by programming languages Can have only two values: True or False Boolean expressions are not strings type(true) vs type("true") 3

4 Boolean Expressions 7 common comparison operators > greater than < less than >= greater than or equal to <= less than or equal to == equal to!= not equal to is the same object as (the same memory location) Boolean Expressions resolve into Boolean ( i.e. True or False) e.g. 1 > 2 resolves into False, while 1>= 1 resolves into True 4

5 Logical Operators We can combine boolean expressions together to form new boolean expressions 3 standard logical operators: and or not MUST use brackets Python can do precedence, but we want our code to be clear not ((1 > 2) or ( a < b) and ( c == 4)) 5

6 Truth Table X Y not X not Y X and Y X or Y True True False False True True True False False True False True False True True False False True False False True True False False 6

7 Comments Is mostly used to show the algorithm (pseudocode) behind your code Is required to help you and others understand your code. Most of the jobs requires you to maintain a code (i.e. comprehending others codes) You can optimize your code if you have good comments but a good code with little or bad commenting is almost impossible to maintain. 7

8 Internal commenting are written inside your function. It is to explain what each line of code is supposed to do. It does not mean that for each line of the code you need a line of comment. It means every line of the codes should be covered by a line of comment. It helps you to figure out how to break-down the problem Comments are ignored by Python. Use hash sign # for comments so python knows which line to ignore interpreting. 8

9 External comments Documentation for people using your code. Accessible via help() function in Python AKA DocString You need to follow a specific format 9

10 External Comments 1. Type Contract ([type [, type [,type ]] ] )-> Type Specifies the type of input and output parameters 2. Description of the function In plain English you explain what this function does 3. REQ: Explain the limitations on the inputs other than type 4. Examples: combination of input and output Use the following format >>> name_of_the_function (list of inputs) Output if any 10

11 Design Recipe Combination of external documentation, internal documentation, code and test cases Why do we need it? It guides you on how to write a function by providing examples of inputs and outputs. By giving you a step-by-step process to follow It makes your code readable by others (even yourself) 11

12 Design Recipe Steps: External Commenting 1. Header: The function definition 2. Type Contract: What types come in, what type is returned 3. Description: Explanation of what the function does 4. Requirements: Limits on the input other than type 5. Examples: Some sample inputs/outputs 6. Internal Comments: plan of what your code will do 7. Code: The body of the function 8. Test: Make sure that your function works 12

13 Step 1: Header def function_name ([parameters_list, ]) function_name should be meaningful and descriptive parameters_list should be meaningful 13

14 Step 2: Type Contract It s a contract between you and whoever is using the function If you give me parameters of the types I define, I will give you output of the defined type (and I won t crash) If you don t follow the contract, I m not responsible for what happens Form: (parameter type list) -> output type 14

15 Step 3: Description A description of what the function does Should be understandable to anyone reading it They shouldn t have to know anything about the internals of your function Should mention every parameter by name 15

16 Step 4: Requirements Any other requirements that the user must obey Similar to type contract, but for things other than type Sometimes referred to a preconditions e.g. REQ : value1 > 0 tells the user that value1 must be positive 16

17 Step 5: Examples Write a few example calls to your function, including expected output Standard cases Don t worry about tricky/border cases yet This step is not necessary for functions which use random or i/o (cases where couldn t predict output given input) 17

18 Step 6: Internal Comments This is where you plan what your function will do Skipping this step = recipe for disaster Use indentation of comments to plan code May want to go back to examples to add tricky/boundary cases at this point 18

19 Step 7:Code This is the bit that actually gets executed Goal of the design recipe is that this step should be trivial Don t want to be focusing on algorithm and implementation details at the same time 19

20 Step 8: Test the Function Run all of your example cases from step 1 & 6 If there are any problems, go back to earlier steps and repeat Write a test case in following format: Function name inputs Description of what this input tests returning result 20