Return statements are optional

[apblack]

A student wrote in a report on a homework, where I asked for comments about Grace:

I just realized that majority of the hardships that I had with reading grace code at the beginning of this class (it has gotten better) is due to the lack of return statements in the given code ( I know Grace has this statement and I use it). I think return statements are some kind of visual cues that help us skim the code faster and help us spatially understand the code. Or, in the worst case, we have this expectation to see a return at the end, and not seeing it there slowed/confused me.

In contrast, @KimBruce Kim Bruce wrote:

I think it is bad style to write return result at the end of a method. It should just be result. I teach my students that return is there only to change the flow of control — e.g., in the middle of a method you determine the answer in an intermediate result and can return immediately.

I have sympathy with both of these points of view, and also with Michael Koening's principle that there should be just a single way of doing things.

It seems that whatever we choose, we can't win.

[kjx]

talking to andrew, we see a stylistic rule here: if the method uses any explicit returns, then all returns (including default at the end) should be explicit.

a very short method shouldn't use an explicit return

the question is for methods longer than a couple of lines, to write the return or not.

This is really a stylistic issue rather than a language one. I guess an other rule could be "never write an explicit return at the end of a method"

[KimBruce]

The problem with the rule that any explicit return requires all to use "return" is that a minor modification to code early in a method body will trigger the requirement to add returns at the end of the method. That kind of non-local side-effect is difficult for students to keep track of. It's similar to, but worse than the problem in Java where writing

if (cond) 
     stat1

is fine, but adding a second statement requires the addition of curly braces

if (cond) {
    stat1
    stat2
}

This is one of those plaes (like while {...} do) that requires them to do something different from other languages, so experienced programmers experience some dissonance, but I don't see that as a big problem.

When I'm teaching, I don't mention the return statement until well into the semester, so the students get used to methods simply returning whatever is the last expression in the method. When I introduce return I tell them the purpose is to explicitly change the flow of control to return from a method early -- with or without a value.

I like this way of approaching it, but I think it is also consistent to always require "return". It might be an interesting problem to give a student: determine what is more intuitive to novices, always require "return" or only when there needs to be an explicit change to the flow of control. I expect that experience programmers would always prefer requiring return because that is what other languages do.

Of course an even more drastic policy would be to never allow the use of "return", instead forcing the use of complicated conditionals to get an early return from a method. I believe there were such languages in the 70's or early 80's (structured programming required single exits from procedures), but they drove everyone crazy.

[kjx]

determine what is more intuitive to novices

you will just measure the other programming languages to which they've been exposed.

languages in the 70's or early 80's ... never allow the use of "return", ... drove everyone crazy

Pascal. Modula-2 has return ("RETURN") and break (aka "EXIT").

[apblack]

As far as I remember, Algol 60 did not have return, and neither did Algol 68. Which is why Pascal doesn’t have it.

The right experiment to perform with novices would involve program understanding and modification. But I suspect that James is right: any short experiment would show that they perform best with a language like the previous one that they have used.