As often the case when using parenthesis, I think that's just for readability (e.g., Ruby supports method calls w/o parenthesis enclosing the arguments but recent books and articles advise otherwise).
There really isn't a reason...it's just old convention.
To save space, programmers would often do the final math in the return line instead of on it's own line and the parens ensure are mostly there to make it easier to see that it is a single statement that is returned, like this:
if/while/for/etc. are all control keywords which must have parens. So it often seems natural to always put them on return too.
sizeof is the only other keyword that can either have them or not, except that in some cases you must use parens. So it's easier to get into the habit of always using parens. for sizeof, which implies a logic of: if you can, always do.
case/goto are the only keywords where you never use parens. ... and people tend to think of those as special cases (and like them both to stand out from other control keywords, esp. goto).
A practical, but unlikely, motive is if you put parenthesis around the value, you can define return as a macro, and then insert some logging code to watch all your returns.
I've worked with at least one programmer who thought return was some special sort of function call, and was suprised when he saw that my code complied without the parens.
Using parentheses in a return statement shows a deficient grasp of C/C++ syntax. It's as simple as that. But it's not as bad as putting everything in curly braces:
int foo(int x) {
if (x) {
return (-1);
}
else {
return (0);
}
}
So many programmers do this. If one of you reads this, perhaps you might like to explain.
Perhaps it's custom--after all, the folks who brought us Unix and C came from the Multics project. Multics was written in PL/I, and in PL/I the parentheses are mandatory.
The Parenthesis in a return statement indicate to the compiler that you intend for this value to be returned on the stack instead of in memory.
In the old days this was rigorously enforced(typically), but today most compilers only take it as a hint.
This is something I do frequently, since an error could corrupt anything being returned via a memory reference, but typically wont effect a variable being returned on the stack.
Using the stack for transient variables also cuts down on memory usage and typically makes the function call/return quicker because that's what the stack is designed for, transient data/variables.
In the original C specification, parentheses were required around the return value. While modern C compilers and the ANSI C standard do not require them, the presence of parentheses does not affect the return value, and programmers sometimes still include them out of habit, unfamiliarity with the standards, for consistency with a stylistic convention that requires them, or possibly for backward compatibility.
I should add, for people that are thinking about C++: This question is about C and C is not C++; these are two different languages with different standards, capabilities, levels of difficulty, and different styles of usage that emerge -- whatever they have in common, it is wise to treat them as two totally separate things. For a similar question that covers C++, see Are parentheses around the result significant in a return statement?.