### CS51A - Spring 2019 - Class 3

#### Example code in this lecture

bbq-functions.py
print_vs_return.py
bbq-functions-commented.py

#### Lecture notes

- lab 1
- how did it go?
- due tomorrow night
- assignment 1: due Thursday at 11:59pm
- follow the assignment handout regarding submission
- ignore any warning about late submissions
- Mentor session hours location
- Practice problems
- videos at the beginning of class

• bbq functions
- Look at the other functions in bbq-functions.py code: what do they do?
- The rest of these functions don't really have any new features from the ones we've previously seen
- notice that we can build up more complicated functions by using the simpler functions
- don't forget that if you want to combine a string and an int/float, you need to convert the int/float to a string using str

• naming variables and functions
- it's important to make your code as readable as possible by both yourself and other people who may look at it
- what does this code do?
- more or less the same code as we just looked at (bbq-functions.py code)
- much, much harder to understand what's being calculated!
- one critical part of this is giving variables and functions appropriate names
- they should be informative and describe what's in them (but not too long, you're going to have to type them!)
- all lowercase
- if they're multiple words, separate the words by underscores (e.g. total_hotdogs)

• print vs. return
- print
- the print function prints the value to the screen/shell
- return
- a return statement has two parts:

return [expression]

- when the program gets to this line, it evaluates the expression. Whatever value this expression evaluates to then is "returned" from that function and represents the value at where the function was called.
- Consider the following two functions (found in print_vs_return.py code ):

def print_square(number):
print(number * number)

def return_square(number):
return number * number

- They do similar things, but their behavior is VERY different
- What would be printed out if the following was typed into the Python shell after defining these functions?

print_square(10)
return_square(10)
x = print_square(10)
x
y = return_square(10)
y

- the first two statements appear to do the same thing, but it is different. print_square is actually printing to the shell inside the function. return_square(10) evaluates to 100, then that value is printed because the default behavior for the shell is to print the value
- This difference is highlighted in the next 4 statements
- when we call print_square, it prints out the value, but does NOT return a value. Therefore, x remains undefined
- when we call return_square, it will NOT print out the value, because it is part of an assignment statement. However, if we look at y, it gets the value returned.

- What would happen if we added the lines below to the end of a file and the run it?

print_square(5)
return_square(5)
print print_square(5)
print return_square(5)

- When you run a file, it starts at the top and executes each statement/line one at a time

- The first call to print_square prints 25
- The first call to return_square does NOTHING. It returns a value, but then we don't do anything with it (just as if we'd typed 5*5 there)
- The second call the return_square print 25 again, then when we return we try and print out the value that was returned from print_square. Since print_square does not return a value, we get "None"
- Finally, we print out another 25 for the 2nd call to return_square. In this case when the value is returned, we print it out.

- other differences
- return also affects the flow of the program. When you hit a return statement, that indicates to the program to leave the function

• Look at the other functions in bbq-functions-commented.py code
- What's new here?

• multiline strings
- So far we've seen double quotes and single quotes for strings
- If we want a string to span over multiple lines we have a few options
- there is a special character '\n' that represents the end of the line
- we can put this in a string

>>> print "This is a string\nthat spans over multiple\nlines"
This is a string
that spans over multiple
lines

- drawbacks of this approach?
- hard to read as a human
- hard to get formatting/alignment right
- if it's a long string (e.g. a paragraph) it's going to go off the screen
- pain to copy and paste multiline text from somewhere else
- Python also includes multi-line strings
- Use triple quotes (or triple single quotes) around a multiline string

>>> print """This is a multiline string
... I can continue to type
... over many different lines
... and it won't stop until
... I close the strings"""
This is a multiline string
I can continue to type
over many different lines
and it won't stop until
I close the strings

- notice that until we close/end the triple quotes, Python continues to prompt us with "..." to let us know that we're still in the middle of something (at least at the shell)

• docstrings
- So, the long string after the function definition of hotdogs is a multiline string
- Any idea why we put it here?
- We can put a string immediately following the definition. This string is called a "docstring".
- The docstring is another form of commenting
- Besides being a useful comment, once we run this program, we can also get the docstring from the shell using the "help" functions

>>> help(hotdogs)
Help on function hotdogs in module __main__:

hotdogs(teran, jasmin)
Returns the number of hotdogs required for the party.

Parameters:
teran -- the number of hotdogs teran will eat
jasmin -- the number of hotdogs jasmin will eat

- This can be VERY useful when you're using code that you haven't written
>>> help(abs)
Help on built-in function abs in module __builtin__:

abs(...)
abs(number) -> number

Return the absolute value of the argument.
- conventions
- We're going to be defining docstrings for ALL functions we write from here on out
- We'll always use triple quotes for docstrings (even if they're just one line)
- For simple functions, a one line docstring is sufficient
- For longer ones, first give a description of what it does, then describe what each of the parameters represents.

• good style
- use good variable/function names
- use whitespace (both vertical and horizontal) to make code more readable
- comment code, including both comments and docstrings
- try and write code as simply as possible (more on this as we go)