previous section | next sectionWeek 10: Functions III
Section 3: Where to Put the Return Statement
The issue of where to put the return statement in your function is also debatable. I used to tell my students to always put their return statements ONLY as the very last statement in their functions, and this approach does have some merit. I could argue that putting a return in the middle of a function violates the "single entry -- single exit" rule (see the Style Conventions section of the syllabus, under "Miscellaneous"). Code is more predictable if you can always assume that the first statement in a function is the first one to be executed and the last statement is the last to be executed. However, it turns out that allowing return statements in other places in a function can often lead to much cleaner code. The problem is that it is very difficult for a novice programmer to know when it is resulting in cleaner code and when it is resulting in messy code. I haven't figured out a way to describe the difference, and I'm not sure it's possible. My recommendation: try writing the function with only one return statement (at the bottom), and then write it with multiple return statements, and choose the one that seems cleanest and clearest. Don't use a return statement in the middle of a function if it is just a desperate attempt to get out of a tight situation. Restructure your code instead.
Let's do another value-returning function example where we will use multiple return statements. At the same time we will illustrate another concept: many value-returning statements return the bool data-type. This type of value-returning function would typically be called inside an if or while condition. For example, C++ has a built in value-returning function named isdigit. It takes a single parameter, a character, and returns true if the character is a digit, false otherwise. It might be called like this:
cout << "enter a character: "; cin >> ch; if (isdigit(ch)){ cout << "you entered a digit."; }It is very common for these
bool value returning functions to be named "issomething". Other examples are isalpha, islower, ispunct, and isspace. Let's write our own bool value-returning function named isLeapYear. You may use this function in your Calendar program (project 2). The requirements given in the text for this program allow you to assume that any year that is divisible by 4 is a leap year. I'm going to require you to determine with complete accuracy whether or not a year is a leap year. So you'll want to pay close attention to this discussion.First we need to know what is a leap year and what isn't. Here's the rule.
- If a year is not divisible by 4, it is NOT a leap year.
- If a year is divisible by 4, it IS a leap year
- EXCEPT, if a year is divisible by 100, then it is NOT a leap year,
- EXCEPT, if a year is divisible by 400, the it IS a leap year.
Notice that we live in a pretty special year, since 2000 is divisible by 400. Was the year 2000 a leap year?
When we write our code for this function, it will actually turn out to be easier if we turn the rule above around and start with what we know for sure. We know for sure that if a year is divisible by 400, it is a leap year. After that, once we have taken care of the "divisible by 400" case, we then know for sure that if the year is divisible by 100, then it is NOT a leap year. And so on. Here's how we would code that:
bool isLeapYear(int year) { if (year % 400 == 0){ return true; } if (year % 100 == 0){ return false; } if (year % 4 == 0){ return true; } return false; }Notice that although we only want to execute the second
if statement if the first condition is false, we don't need to use else here, because when C++ hits the return statement the function instantly ends.In my in-person classes I spend quite a bit of time this week developing a large program interactively with the students. I use Dale Chapter 7, programming problem 5 as the example. This type of exercise is hard to reproduce in the online setting; however, I will post the final solution to the problem later this week. My suggestion is that you try to write the program on your own, then peek at the solution when you get stuck. Only peek at enough of the solution to get you back on track (for example, just the main function), and then try again. When you finish, compare your solution to my solution. You will gain a lot more from this exercise than you will from just staring at the final product.
previous section | next section
Created by David Harden.
Please do not print or copy except for a single copy
for students taking CIS10A at Santa Rosa Junior College