Using "return" with parantheses?

[Richard Bos]

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him .

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

There's nothing wrong with it from a technical POV. Some people don't
like it as a style issue, because _they_ are the ones who keep
forgetting that return is not a function if they keep seeing the parens,
but that's their problem, not yours. FTR, I don't put parens around the
argument of return, but I won't shout at you for doing so.

Richard

 

[Mike Machuidel]

Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him .

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

Thank you,
Mike Machuidel

 

[Andreas Kahari]

Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him .

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

It's not wrong, it's just not needed.

See the FAQ at

http://www.eskimo.com/~scs/C-faq/q20.19.html

 

[Tom St Denis]

It's not wrong, it's just not needed.

See the FAQ at

http://www.eskimo.com/~scs/C-faq/q20.19.html

Technically whitespace isn't needed by the compiler either [at least to the
extent most people use it, obviously you need to seperate tokens...]

Tom

 

[Tom St Denis]

Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him .

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

It isn't wrong but if your company has standards for coding I suggest you
follow them.

Also "return(0);" does look stupid I'd put a space there "return (0);"

Though I'm against returning constants alltogether. You should have some

enum {
RES_OK,
RES_ERR
};

[etc]

and return RES_OK instead.

Tom

 

[Dan Pop]

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him .

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

There is nothing wrong, if you also write such things:

i = (j) + (k);
for (i = (0); i < (sizeof(foo)); i++) ...
printf("%d\n", (i));

If you don't, then what's the point in surrounding the return
expression by a pair of completely useless parentheses? The language
accepts them for the sole reason that every expression can be
surrounded by an arbitrary number of matching pairs of parentheses
(up to 32 in C89 or 63 in C99). So, why limit yourself at a single
pair, when return(((((((((0))))))))); is so much cooler?

The other reason against parentheses in return statements is related to
what happens if you make a typo. In C89, retunr(0); is a valid function
call that doesn't require any diagnostic, while retunr 0; is a syntax
error requiring a diagnostic. Why prevent the compiler from detecting
and reporting your typos?

In short, in a C program, *unneeded* parentheses should be used only when
they improve the code readability (usually complex expressions). I don't
find return(0) and more readable than return 0 and the previous paragraph
explains why the latter is to be preferred.

During the early days of C, the syntax of the return statement required
the parentheses. Later, it was realised that they don't serve any *good*
purpose and, by the time K&R1 was printed, they were already removed from
the language syntax (but not from the code examples included in the book).
This explains why some people who learned C more than 15 years ago may
still use them.

Dan

 

[Darrell Grainger]

Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him .

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

I would never say it is 'wrong' to use:

return(0);

There could be the off chance a utility would see this as a function and
get confused (or maybe a REALLY junior programmer).

One thought could be that junior programmers might assume it is a function
call. To make it clear to everyone, don't use the parentheses so people
know it is not a function call. The same would hold true for the sizeof
operator.

What it really boils down to is people being nitpicky. I'm sure if I
wrote:

return((((((0))))));

that would bother a lot of people. There is nothing really wrong with it.
It just bothers people because there is no need for the parentheses.

 

[Fao, Sean]

It's not wrong, it's just not needed.

See the FAQ at

http://www.eskimo.com/~scs/C-faq/q20.19.html

As the FAQ points out, "parentheses are optional with the sizeof operator,
too, as long as its operand is a variable or a unary expression".

When I first started programming in C, I was asked to write a macro, which
would calculate the number of elements in an array, but couldn't use any
functions. I knew I could do it like this:

#define NUM_ELTS(x) (sizeof(x) / sizeof(x[0]))

However, at the time, the parentheses that I was taught to use made me think
that sizeof was a function.

In my opinion, any C programmer who doesn't know that parentheses are
optional in these cases, and others, has no business working on any real
projects other then the ones out of a workbook. Maybe your use of
parentheses suggested to you coworkers a lack of understanding. As you
pointed out, it's not wrong; but, they aren't necessary. What would you
think if a coworker started writing code like this:

int main(void)
{
int a = (32);
printf("%d\n", (a));
return (0);
}

Sean

 

[James Antill]

In my opinion, any C programmer who doesn't know that parentheses are
optional in these cases, and others, has no business working on any real
projects other then the ones out of a workbook. Maybe your use of
parentheses suggested to you coworkers a lack of understanding. As you
pointed out, it's not wrong; but, they aren't necessary. What would you
think if a coworker started writing code like this:

int main(void)
{
int a = (32);
printf("%d\n", (a));
return (0);
}

Probably the same as if a found a coworker who had written...

if (a && b || c && d != -1)

....parentheses are mainly about style, and yes examples can be provided at
either extreme that are terrible. Personally I find that I think of...

if (x)
while (x)
switch (x)
return (x)
exit (x)

....all as "similar" so I make them look the same. I also, personally, find
that I think of...

strlen(x)
sizeof(x)
malloc(x)

....as "similar", so I make them look the same. That doesn't mean I don't
understand that sizeof() isn't a real function (even though it's even
closer to acting like one in C99), I just prefer to see it that way.

As was said, if you have coding stds. for what you are working on then
almost any style applied consistently is better than a mixture of
anything. So if the rest of the code base used non-parentheses return
statements then you should change.

As for typing "return (0);" being typoed "reutrn (0);" and not being
caught, then..

1. Every viewer/editor[1] I use for C has syntax highlighting that show the
return as obviously wrong.
2. I've always used a compiler that warns when you use a non-prototyped
function.

[1] Well, ok, every one apart from my newsclient.

 

[Serve Lau]

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".

I'm dying to know, how old is that programmer?

 

[E. Robert Tisdale]

Today, at work, a colleague (a C++ programmer) yelled at me.
I'm a bad C programmer
because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a statment,
like I didn't know already.
The other colleagues also agreed with him .

Can someone please explain
what's so wrong about using "return" with parentheses?
I've used them like that from the beginning.

> cat main.c

#define return(value) return value

int main(int argc, char* argv[]) {
return(0);
}

> gcc -Wall -std=c99 -pedantic -E main.c

# 1 "main.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "main.c"


int main(int argc, char* argv[]) {
return 0;
}

 

[Glen Herrmannsfeldt]

Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him .

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

I sometimes use them. One reason might be that I used to use PL/I, where
they are required for return statements returning a value.

The syntax of if, for, and while, to name a few, C statements, requires
parenthesis and I don't think it makes them look like functions.

In any case, I think putting the return value on the return statement is
better than the traditional Fortran method of assigning to a variable named
after the function. (Though for Fortran implementations with the ENTRY
statement, assigning to a variable is probably better, because of
type/conversion problems.)

-- glen

 

[Fao, Sean]

...parentheses are mainly about style, and yes examples can be provided at
either extreme that are terrible.

[...]

Style is a touchy subject because the language rules only provide a starting
ground. I personally hate seeing code with the opening { on the same line
as the if statement, while loops, etc...However, I do like them to be on the
same line as a do and with the while on the same lines as the closing }, for
some reason (don't ask me why, I don't know; I just like it that way). I
don't want to get into an argument over who is right because who's to say I
am? I like how I write my code and that's the reason I do it thay way.
I've also never had a complaint about my style. I just hope that the
company I work for doesn't decide to make any style changes while I'm still
around.

Sean

 

[Keith Thompson]

When I first started programming in C, I was asked to write a macro, which
would calculate the number of elements in an array, but couldn't use any
functions. I knew I could do it like this:

#define NUM_ELTS(x) (sizeof(x) / sizeof(x[0]))

However, at the time, the parentheses that I was taught to use made me think
that sizeof was a function.

I would write that as

#define NUM_ELTS(x) (sizeof(x) / sizeof((x)[0]))

References to macro arguments should always be enclosed in
parentheses; otherwise you can run into some really nasty problems
with operator precedence. Remember that the argument is expanded into
the text, not into the expression tree.

This rule applies to function-like macros whose arguments are
expressions; it may not apply to more bizarre macro definitions.

#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}

 

[Mark McIntyre]

Hi,

Can someone please explain what's so wrong about using "return" with
parantheses?

There's nothing wrong, they're just not needed. For not particular
reason I tend to use them if the return is a messy expression,
otherwise not.

 

[August Derleth]

cat main.c

#define return(value) return value

int main(int argc, char* argv[]) {
return(0);
}

gcc -Wall -std=c99 -pedantic -E main.c

# 1 "main.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "main.c"


int main(int argc, char* argv[]) {
return 0;
}

Eh, but if you have to run your code through the pre-processor to make it
conform to your company's standards, you'll probably find yourself on the
short end of the chewed-out stick. After all, at least on my system,
running the pre-processor on any of my code produces something that's full
of odd magic numbers and rather ugly lines of stuff I didn't write.

So, what does your code really prove? We all know the pre-processor phase
comes before the compilation phase.

 

[nobody]

cat main.c

#define return(value) return value

int main(int argc, char* argv[]) {
return(0);
}

gcc -Wall -std=c99 -pedantic -E main.c

# 1 "main.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "main.c"


int main(int argc, char* argv[]) {
return 0;
}

Eh, but if you have to run your code through the pre-processor to make it
conform to your company's standards, you'll probably find yourself on the
short end of the chewed-out stick. After all, at least on my system,
running the pre-processor on any of my code produces something that's full
of odd magic numbers and rather ugly lines of stuff I didn't write.

So, what does your code really prove? We all know the pre-processor phase
comes before the compilation phase.

You are right in your statements, but wrong in reasoning. We all
know that preprocessing phase comes *after* reviewing phase ;-)
It's about human readers of code, compiler doesn't care about
parentheses in this particular case, and proposed "solution" only
adds more useless clutter into code.

OTOH, I've seen ([sur]real code in [sur]real system) something like:

#define return(x) \
{ \
printf("%d\n", x); \
/* 10 or so lines of "debugging" code */
return 0; \
}

In order to use this "facility", return *had* to be coded with parentheses
around value. If that was a good practice is beside the point on hand.

 

[Joona I Palaste]

In my opinion, any C programmer who doesn't know that parentheses are
optional in these cases, and others, has no business working on any real
projects other then the ones out of a workbook. Maybe your use of
parentheses suggested to you coworkers a lack of understanding. As you
pointed out, it's not wrong; but, they aren't necessary. What would you
think if a coworker started writing code like this:

int main(void)
{
int a = (32);
printf("%d\n", (a));
return (0);
}

Your printf statement has too few parantheses. It's much more legible
as:

(printf)(("%d\n"), (a));

 

[CBFalconer]

.... snip ...

So, what does your code really prove? We all know the
pre-processor phase comes before the compilation phase.

It proves him to be a troll. If we all ignore him, apart from
correcting the persistent errors, maybe he will go away.

 

[Fao, Sean]

Your printf statement has too few parantheses. It's much more legible
as:

(printf)(("%d\n"), (a));

You missed one too ;-)

((printf)(("%d\n"), (a)));