Recommended style

[Bonj]

A benefit of including spaces is if you don't, then when you do Ctrl-left or
Ctrl-right to skip words, you skip about half a line if you haven't left
spaces. Although I admit I can never be bothered.

 

[jjf]

A benefit of including spaces is if you don't, then when you do
Ctrl-left or Ctrl-right to skip words, you skip about half a line
if you haven't left spaces. Although I admit I can never be bothered.

Just use w or b instead.

 

[Keith Thompson]

Neither:
fp = fopen("xyz.txt", "r");
if (fp == NULL) {
...
}
is nearly right, but that's java style. Since your question is titled
'Recommended style', the correct style is
fp = fopen("xyz.txt", "r");
if (fp == NULL)
{
...
}

is correct,

[...]

First, please don't top-post. Your response belongs after any quoted
text, not before it. See most of the articles in this newsgroup for
examples.

Your indentation is messed up in the second example, but I'll assume
that's a typo. If you're saying that

if (fp == NULL) {
...
}

is incorrect, but

if (fp == NULL)
{
...
}

is correct, I disagree. Both styles are popular (and both predate
Java). The former is used in K&R and in examples in the standard, and
is sometimes referred to as the One True Brace Style (and I personally
prefer it). If you prefer the latter, that's fine.

 

[Raymond Martineau]

Hi all,

Which is the recommended style in production code for the following -

[...]

Anyone who tells you that either of these is "recommended style" except
with reference to your local coding standards is blowing smoke.

That is correct.

For what it's worth, I prefer
if (!(fp = fopen("xyz.txt","r"))) {
/* handle error */
}

One problem with this code - some compilers (specifically some old ones)
are a bit overzealous and might suggest that you should use "==" insteaed
of "=". It's possible to disalbe the warning, but they either require a
bit more typing or prevent you from immediatly detect another problem
caused by confusing the operators.

 

[Keith Thompson]

Just use w or b instead.

Which, of course, depends on which text editor you use, which is
off-topic.

 

[Martin Ambuhl]

Hi all,

Which is the recommended style in production code for the following -

[...]

Anyone who tells you that either of these is "recommended style" except
with reference to your local coding standards is blowing smoke.

That is correct.

For what it's worth, I prefer
if (!(fp = fopen("xyz.txt","r"))) {
/* handle error */
}

One problem with this code - some compilers (specifically some old ones)
are a bit overzealous and might suggest that you should use "==" insteaed
of "=".

You might be right, but name one.

It's possible to disalbe the warning,

It should not be needed. The form of the statement is
if (!(p))
not
if (p)

When p is 'a = b',
if (a = b)
might trigger such a warning, but
if (!(a = b))
should never do so.

 

[jjf]

Neither:
fp = fopen("xyz.txt", "r");
if (fp == NULL) {
...
}
is nearly right, but that's java style.

Where do you get that idea from?

Since this brace style is preferred by the guy who invented C a
decade or two before Java was invented, and used in his seminal
book on the language, it's hard to see why it would be described
as "java style".

 

[Emmanuel Delahaye]

E. Robert Tisdale wrote on 30/12/04 :

I might write:

FILE* fp = fopen("xyz.txt", "r");
if (NULL != fp) {
// read from xyz.txt
}
else { // (NULL == fp)
fprintf(stderr, "Couldn't open file xyz.txt!\n");
}

I prefer to deal with the normal, usual or expected condition first
and handle the error (exception) condition in the else part.

Agreed.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++

 

[Chris Croughton]

Why would you be surprised that someone would violate *your* rule? I
didn't even know about it until now. (And, to tell the truth, still
don't feel any particular obligation to conform to it.)

Actually, his 'rules' are the ones I use as well, but I've seen so many
coding styles that I'm not at all surprised at code which is differently
laid out. I've had to conform to a number of them in different jobs,
and each time my own coding style (as in code I write for myself) has
either been re-validated or has altered slightly. Thank gnu for indent
and other 'beautifiers'...

Chris C

 

[Chris Croughton]

A benefit of including spaces is if you don't, then when you do Ctrl-left or
Ctrl-right to skip words,

.... nothing at al happens in the editor I use.

you skip about half a line if you haven't left
spaces. Although I admit I can never be bothered.

On the other hand, if I use W and B to skip to words delimited by spaces
I get the effect you describe (if I use w or b then it stops at non
alphanumeric characters).

Saying anything about what keys do what in an editor is even less
portable than specific implementations of C, because there are no
standards at all...

(Oh, and top-posting doesn't help either...)

Chris C

 

[Alan Balmer]

A benefit of including spaces is if you don't, then when you do Ctrl-left or
Ctrl-right to skip words, you skip about half a line if you haven't left
spaces. Although I admit I can never be bothered.

Depends on what your text editor calls a word.

 

[Mabden]

We've discussed this at length here recently. Opinions vary
considerably on this. A lot of people (including myself) find things
like "if (4 == x)" just plain ugly for insufficient benefit.

I agree that it is ugly. I agree that a C programmer rarely falls for
the = vs. == "problem". It would be helpful for recent VB programmers,
or the occasional Pascal programmer. But I have recently begun using it
because of the Real Programmer credo:

"If it was hard to write, it should be hard to read!", Dammit!

 

[E. Robert Tisdale]

"If it was hard to write, it should be hard to read!", Dammit!

Sigh.

 

[Raymond Martineau]

You might be right, but name one.

#include <stdlib.h>

int main()
{
void *asl;
if (!(asl = malloc(15) )) /* Line 7 */
{
exit(1);
}
free(asl);
return 0;

}

When compiled under Turbo C++ 4.5 for Windows:
Warning NONAME00.C 7: Possibly incorrect assignment in function main()

The warning doesn't appear if you use "== NULL" instead.

Now that I think of it, I only remember this form of warning appearing
under Borland's compilers. It's probably more specific case than I
expected.

It should not be needed. The form of the statement is
if (!(p))
not
if (p)

When p is 'a = b',
if (a = b)
might trigger such a warning, but
if (!(a = b))
should never do so.

Of course, warnings that appear under these circumstances are quite often
false positives when both sides are variable (e.g. variables or function
calls.) That's probably why I haven't seen this warning in a long time...

 

[Stephen Sprunk]

Which is the recommended style in production code for the following -

...
fp = fopen("xyz.txt", "r");
if (fp == NULL) {
...
}

OR
fp = fopen("xyz.txt", "r");
if (!fp) {
...
}

Thanks.

The recommended style is generally specified in your employer's or project's
coding standards, if they exist. If that's not applicable, then stick to
the style used elsewhere in the same file and/or project. If it's a totally
new file/project or there is no consistent example to follow, then it's your
decision.

Personally, I prefer the latter because it's slightly less typing plus I
find it more readable since it's a common C idiom. However, consistency is
far more important than personal preference in most cases.

S

 

[Chris Croughton]

I agree that it is ugly. I agree that a C programmer rarely falls for
the = vs. == "problem". It would be helpful for recent VB programmers,
or the occasional Pascal programmer. But I have recently begun using it
because of the Real Programmer credo:

"If it was hard to write, it should be hard to read!", Dammit!

I've recently started writing[1] my code with exactly 78 characters on
each line, and all variables held in global arrays (one for each type),
for the same reason. It makes it very unlikely that anyone will be able
to read my code (it's full of gotos as well), as well as being hard to
write.

[1] This is actually a lie, I really write for good clarity and
maintainability, because I might have to maintain it in several years
time when I've forgotton everything about it. I recently came across
some code I wrote almost 20 years ago, aside from being pre-C89 (no
function prototypes) it was still pretty readable...

Chris C

 

[Victor Nazarov]

I too feel that doing this makes the code more readable.

I usually use this:

{
fp = fopen (fn, fmode);
if (!fp) {
error ();
goto fail;
}
rc = foo (fp);
fail:
if (!fp)
fclose (fp);
}

 

[Emmanuel Delahaye]

Victor Nazarov wrote on 01/01/05 :

I usually use this:

{
fp = fopen (fn, fmode);
if (!fp) {
error ();
goto fail;
}
rc = foo (fp);
fail:
if (!fp)
fclose (fp);
}

Isn't it a little bit complicated for the purpose ? Or is it a troll ?

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.

 

[The Dragon]

Nah, that's just naff. That just says "I'm someone who often forgets to put
== instead of = and therefore I always stick to putting the operand on the
left".

Argh, Top-posting =P... But... seriously, no its saying "Im not perfect,
you're not perfect, no ones perfect, and this is a method of avoiding
more mistakes." Period. If you don't like it, you don't have to do it.
No one forces it on you, but I find (and I've been in this field longer
than most), that most "software developers" (and I use that term lightly
too because most that I've met couldn't develop thier way out of a
straw dry paper bag with a lighter) think they're a hell of a lot better
than they really are. This business contains too many ego's and too few
brain cells.

-- The Dragon

 

[Mike Wahler]

Victor Nazarov wrote on 01/01/05 :

Isn't it a little bit complicated for the purpose ? Or is it a troll ?

Probably a troll. Note the OP's "name".

-Mike