Design implications of returning a function with void

Question

Consider the following bar functions

#include <iostream>
void foo(){
 std::cout << "Hello" << std::endl;
}
void bar1(){
 return foo();
}
void bar2(){
 foo();
}
void bar3(){
 foo();
 return;
}
int main()
{
 bar1();
 bar2();
 bar3();
 return 1;
}

These functions do exactly the same thing, and actually godbolt produces the same code for all three (as one would hope). The question I have is simply whether there are any software engineering paradigms/guidelines that advocate one form over the other, and if there are any reasons why you would prefer one over the other. They seem to produce the same machine code, but I am imaging that one might be viewed as "easier to maintain", or something like that.

• bremen_matt: I understand that the question of 'why' is opinion based. This is why I asked about which paradigms might have anything to say on the subject. Presumably they have some rationale that we can weigh objectively.
• Bartek Banachewicz: A return in a void function is immediately suspicious to me. I say treat void functions like Pascal's procedures.
• Fabio C.: I would surely go with number 2 since the 1 is misleading, when reading the body i'm supposing to return something but the function is actually void, also the number 3 explicity states that we are returning but don't see any added value since its at the end of the function body.
• StoryTeller - Unslander Monica: I won't say bar3 is universally good, but sometimes an explicit return can tell far more than simply flowing off the end. Kate Gregory incorporated this point into her CppCon 2018 talk. You can get a lot of food for thought about such matters from the talk, and I highly recommend it.
• bremen_matt: Interesting talk. 23:46 is the time marker you are talking about. She gives an interesting take. .

Answer 1

This is quite opinion-based. Though I'd say the general consensus is to write it like bar2(). Don't return explicitly unless you have to return early and don't do return func() if func() returns a void, that just confuses readers because you're not actually returning a value.

Answer 2

I totally agree with Sombrero Chicken's answer. But I'll also add that the construct like

void bar1(){
 return foo();
}

doesn't make much sense for ordinary functions that return void, but may be useful for template code when you don't know the actual return type, e.g:

template <typename T>
auto SomeTemplateFunction(...)
{
 // do some works
 ...
 return SomeOtherTemplateFunction<T>(...);
}

This will work regardless SomeOtherTemplateFunction<T>'s return type is void or not.

• bremen_matt: One perceived advantage of writing something like this would be that I can easily change how the code structurally works. The cost is ambiguity... reading the code, it isn't clear what exactly will be returned.
• Dmitry Gordon: Yes it doesn't have to, but for non-template code if your return value is void personally I would rather not write return statement in the end of the function. For template code it's sometimes necessarily to do it.

Answer 3

It's quite opinion based, what I can say is that (3) is tagged by clang-tidy rules as part of the readibility-redundant-control-flow.

The idea is that the control flow here is already defined, the return is superfluous and should then be removed.