Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #3223 > unrolled thread

Coding style for conditionals

Back to article view | Back to comp.lang.c++

Contents

  Coding style for conditionals mzdude <jsanga@cox.net> - 2011-04-06 12:05 -0700
    Re: Coding style for conditionals Victor Bazarov <v.bazarov@comcast.invalid> - 2011-04-06 15:21 -0400
    Re: Coding style for conditionals Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-06 15:24 -0700
      Re: Coding style for conditionals Michael Doubez <michael.doubez@free.fr> - 2011-04-07 05:28 -0700
    Re: Coding style for conditionals "MikeWhy" <boat042-nospam@yahoo.com> - 2011-04-06 19:58 -0500
    Re: Coding style for conditionals gwowen <gwowen@gmail.com> - 2011-04-07 00:10 -0700
      Re: Coding style for conditionals mzdude <jsanga@cox.net> - 2011-04-07 04:57 -0700
      Re: Coding style for conditionals gwowen <gwowen@gmail.com> - 2011-04-07 06:06 -0700
        Re: Coding style for conditionals gwowen <gwowen@gmail.com> - 2011-04-07 07:02 -0700
          Re: Coding style for conditionals gwowen <gwowen@gmail.com> - 2011-04-07 08:31 -0700
            Re: Coding style for conditionals Puppet_Sock <puppet_sock@hotmail.com> - 2011-04-07 13:26 -0700
            Re: Coding style for conditionals gwowen <gwowen@gmail.com> - 2011-04-07 23:07 -0700
              Re: Coding style for conditionals gwowen <gwowen@gmail.com> - 2011-04-08 01:44 -0700
                Re: Coding style for conditionals "io_x" <a@b.c.invalid> - 2011-06-05 09:04 +0200
              Re: Coding style for conditionals Michael Tsang <miklcct@gmail.com> - 2011-04-09 22:23 +0800
          Re: Coding style for conditionals Marek Borowski <marek_remove_@borowski.com> - 2011-04-08 13:23 +0200
            Re: Coding style for conditionals gwowen <gwowen@gmail.com> - 2011-04-08 05:33 -0700
          Re: Coding style for conditionals "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-04-08 16:07 -0700
            Re: Coding style for conditionals Leigh Johnston <leigh@i42.co.uk> - 2011-04-09 00:36 +0100
            Re: Coding style for conditionals "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-04-09 06:25 -0700
              Re: Coding style for conditionals Öö Tiib <ootiib@hot.ee> - 2011-04-09 07:28 -0700
    Re: Coding style for conditionals Juha Nieminen <nospam@thanks.invalid> - 2011-04-09 07:32 +0000

Page 1 of 2  [1] 2  Next page →

#3223 — Coding style for conditionals

I have no interest in starting a religious war on the subject, but
I've
been doing some code reviews and running across code like

Method 1:
int x;
if(  0 == ( x = MyFunct() ) )
    //  do something

I personally don't like the style. I seem to remember there were
reasons not to do this but
today google is not my friend. I can't find any reasons against this.
Are there valid reasons
not to do this style?

I would prefer

Method 2:
const int x = MyFunct();
if( 0 == x )
	// do something

reasons for method 2
1) declare and initialize
2) allows variable to be const

Are they any valid reasons to not do method 1?

[toc] | [next] | [standalone]

#3224

On 4/6/2011 3:05 PM, mzdude wrote:
> I have no interest in starting a religious war on the subject, but
> I've
> been doing some code reviews and running across code like
>
> Method 1:
> int x;
> if(  0 == ( x = MyFunct() ) )
>      //  do something
>
> I personally don't like the style. I seem to remember there were
> reasons not to do this but
> today google is not my friend. I can't find any reasons against this.
> Are there valid reasons
> not to do this style?

Doesn't "pronounce" well.  I can't come up with a good "spelling" of 
this when I, say, talk to somebody on the phone.

> I would prefer
>
> Method 2:
> const int x = MyFunct();
> if( 0 == x )
> 	// do something
>
> reasons for method 2
> 1) declare and initialize
> 2) allows variable to be const
>
> Are they any valid reasons to not do method 1?

They are valid.

I would prefer

    ... if (x == 0)

but I read/heard all arguments for your way (no need to repeat those, 
thank you).

Aside from satisfying someone's whim about writing in C style, I don't 
see any reason to define a variable without initializing it (in a case 
like yours).

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#3232

On Apr 6, 12:05 pm, mzdude <jsa...@cox.net> wrote:
> I have no interest in starting a religious war on the subject,

That's good. For questions of style, I think that there are two kinds
of questions:
1- entirely subjective differences, and
2- differences that result in easier to read, easier to maintain,
easier to write and prove correct, code. These differences have
objective measures in principle, though in practice it's often quite
hard to measure.

Note that there is a a very fuzzy line between these two given that
evidence in practice is so hard to obtain.

> but I've
> been doing some code reviews and running across code like
>
> Method 1:
> int x;
> if(  0 == ( x = MyFunct() ) )
>     //  do something
>
> I personally don't like the style. I seem to remember there were
> reasons not to do this but
> today google is not my friend. I can't find any reasons against this.
> Are there valid reasons
> not to do this style?

If the variable x is used nowhere else, I would argue against this
style. I accept that sometimes breaking an expression or statement
into multiple statements can increase readability, but I see
absolutely no gain of readability of
    int x;
    if(  0 == ( x = MyFunct() ) )
        // do something
over
    if (0 == MyFunct())
        // do something
I would argue that there is an objective measure in this case. We
could make a test for how fast and how accurately people can
understand the two code samples, and I argue that the evidence would
indicate that most people overall find the second easier to
understand, and they would take less time to understand it.

I would also argue that there exists an objective measure in this case
that it takes less time to read the shorter code sample, and that
there are less errors overall in this style (from having less
extraneous visible variables).

> I would prefer
>
> Method 2:
> const int x = MyFunct();
> if( 0 == x )
>         // do something
>
> reasons for method 2
> 1) declare and initialize
> 2) allows variable to be const
>
> Are they any valid reasons to not do method 1?

I agree that this is preferable under the same aforementioned
objective measures, but again, if x is unused elsewhere, then it
really should be:
    if (0 == MyFunct())
        // do something

Of course, if MyFunct() is not exactly as written, such as if it
contains a lot of arguments or something, then that might be good
reason to separate it out into separate pieces to be more quickly and
easily understandable. I'm trying to come from the perspective of
several objective measures of good code, but as I mentioned such
discussions are usually terribly nuanced, and often overall with
simply personal preferences apart from objective measures of code
quality.

[toc] | [prev] | [next] | [standalone]

#3258

On 7 avr, 00:24, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Apr 6, 12:05 pm, mzdude <jsa...@cox.net> wrote:
>
> > I have no interest in starting a religious war on the subject,
>
> That's good. For questions of style, I think that there are two kinds
> of questions:
> 1- entirely subjective differences, and
> 2- differences that result in easier to read, easier to maintain,
> easier to write and prove correct, code. These differences have
> objective measures in principle, though in practice it's often quite
> hard to measure.
>
> Note that there is a a very fuzzy line between these two given that
> evidence in practice is so hard to obtain.
>
> > but I've
> > been doing some code reviews and running across code like
>
> > Method 1:
> > int x;
> > if(  0 == ( x = MyFunct() ) )
> >     //  do something
>
> > I personally don't like the style. I seem to remember there were
> > reasons not to do this but
> > today google is not my friend. I can't find any reasons against this.
> > Are there valid reasons
> > not to do this style?
>
> If the variable x is used nowhere else, I would argue against this
> style. I accept that sometimes breaking an expression or statement
> into multiple statements can increase readability, but I see
> absolutely no gain of readability of
>     int x;
>     if(  0 == ( x = MyFunct() ) )
>         // do something
> over
>     if (0 == MyFunct())
>         // do something

But you may have a gain in a core dump (or under debug); it makes it
easier to trace back the state of the program.

[snip]

> > Method 2:
> > const int x = MyFunct();
> > if( 0 == x )
> >         // do something
>
> > reasons for method 2
> > 1) declare and initialize
> > 2) allows variable to be const
>
> > Are they any valid reasons to not do method 1?

I prefer separating the function call and the test (supposing the
return value is significant as Joshua Maurice pointed).
The readability of multiple = in a condition is already horrible,
method 1 makes it worse.

The only reasonable case for using method 1 is in a while loop.
while( (x=foo()) == OK )
{
  // do something
}
if( x == ERROR )
{
  // ... reason of loop end
}

I would also add that it is better to use braces:
if( x == 0 )
{
  // do something
}

Concerning the "'constant' == variable", IMHO there used to be valid
reason to do so but nowadays compilers warn you about assignment in
conditional so I prefer the readability rather than the supposed added
security.

--
Michael

[toc] | [prev] | [next] | [standalone]

#3236

"mzdude" <jsanga@cox.net> wrote in message 
news:b8402511-f313-4b06-90da-6ccbcc9cb817@a17g2000yqn.googlegroups.com...
>I have no interest in starting a religious war on the subject, but
> I've
> been doing some code reviews and running across code like
>
> Method 1:
> int x;
> if(  0 == ( x = MyFunct() ) )
>    //  do something
>
> I personally don't like the style. I seem to remember there were
> reasons not to do this but
> today google is not my friend. I can't find any reasons against this.
> Are there valid reasons
> not to do this style?
>
> I would prefer
>
> Method 2:
> const int x = MyFunct();
> if( 0 == x )
> // do something
>
> reasons for method 2
> 1) declare and initialize
> 2) allows variable to be const
>
> Are they any valid reasons to not do method 1?

A not so tenuous reason is return types other than int, possibly involving 
non-trivial default construction, or reference types.

const Foo & YourFunct();
...
const Foo & bar = YourFunct();
if (!!bar)
{    // do stuff
}

//------ or,
Foo baz(YourFunct());
if (!baz)
{}   // intentionally blank
else
{    // do non-const stuff.
}
//==========

As you can see, consistent stylistic rules still leave too much room 
individual deviation.

As a stylistic concern, I'll often insist on a bool operator!() const in the 
class rather than an operator bool() const. This leads to the bang-bang 
test, which in turn leads repetitively to answering the inevitable "what the 
heck" question.

Embrace the differences, unless they're truly awful. I personally dislike 
many things that I see in your code, but to change each occurrence as I 
encounter them will keep us both busily unproductive for quite some time. 
(All of them little things.... if( test ), rather than if (test), for 
starters. Unrelated, but still topical: operator++() versus operator++(int). 
I'll often define a pre-increment but not a post-increment, so code should 
default to pre-increment, following STL convention, if no other compelling 
reason exists.)

[toc] | [prev] | [next] | [standalone]

#3247

On Apr 6, 10:44 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> >int x;
> >if( !( x = MyFunct() ) )

The trouble with this is if you're testing for non-zero, rather than
zero, then the natural analogues are

if(x = MyFunct()) { ... }

if(!!(x = MyFunct())) { ... }

one of which is ugly, and the other of which is a maintainence
disaster waiting to happen.

const int x = MyFunct();
if(x != 0) { ... } // I'd accept if(x){ ... } here

[toc] | [prev] | [next] | [standalone]

#3257

Thanks for the feedback. I think I'll suggest moving to
method 2 but stop short of failing the code review. Nobody
has given a concrete example of why it's bad.

[toc] | [prev] | [next] | [standalone]

#3261

On Apr 7, 1:33 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> gwowen <gwo...@gmail.com> writes:
> >if(x = MyFunct()) { ... }
> >if(!!(x = MyFunct())) { ... }
> >one of which is ugly, and the other of which is a maintainence
> >disaster waiting to happen.
>
>   For amateur maintainers.

Well, if you can guarantee that your code will be maintained in
perpetuity by dedicated professionals then lucky you.

Even so, if I saw
if(x = MyFunct()) {

}

I'd immediately think ... "do I really mean assignment"? or has
someone mistyped x==Myfunc().  In fact, if I were ever to use that
construction (probably in while() rather than if), I'd feel obliged to
comment the intent, to make the maintainers job easier.

while(cached_x = expensive_function()){ /* NB: NOT == */
  // do something with cached_x
}

and even then I'd try and rewrite it to avoid that construction.  It's
simply too easy to misread the '=' as '==' while trying to get a
synoptic view of the algorithm.  I'm confident enough in my
intelligence that I don't need to prove it at every turn (Hi Leigh!).

> "Quite frankly, even if the choice of C were to do
> *nothing* but keep the C++ programmers out, that in
> itself would be a huge reason to use C." -- Linus Torvalds

"Programs should be written for people to read, and only incidentally
for machines to execute." -- from "Structure and Interpretation of
Computer Programs" by Abelson and Sussman

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." -- Brian Kernighan

[toc] | [prev] | [next] | [standalone]

#3267

On Apr 7, 2:17 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> gwowen <gwo...@gmail.com> quotes Abelson and Sussman:
>
> >Programs should be written for people to read
>
>   Yes, but obviously for people who already
>   /know the programming language/.

Yes, but that doesn't mean that all valid language constructs are
equally easy to maintain even for people skilled in the language ...
that's, if not demonstrably untrue, then at least widely considered
untrue.

Code that can be immediately and correctly understood at a glance is
easier to maintain than code that is a single glyph different from far-
more-common idiom with wildly different semantics.

"if(y == f()){}" is common, idiomatic C. "if(y = f()){}" is not.
Since you, and those who maintain your code, never ever make mistakes
while reading code, that won't matter.  For the rest of us, clarity is
a genuine benefit.

[toc] | [prev] | [next] | [standalone]

#3270

On Apr 7, 3:09 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> gwowen <gwo...@gmail.com> writes:
> >"if(y == f()){}" is common, idiomatic C. "if(y = f()){}" is not.
>
>   To me, the meaning of both is immediately obvious.

The point isn't mental, its visual.  It isn't that one doesn't *KNOW*
the difference between x=f() and x==f(), its that one doesn't *SEE*
the difference between x=f() and x==f().  If your eyesight and mind
are so razor sharp that you cannot imagine mistaking one for another
while reading code, then I'm very jealous of you.

It's like this: what does following code do

int k = 8, l = 9;
int x = (k*k) - (7*l) ;
if(x = l)  printf("x is one\n");
if(x == l) printf("x is one\n");

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

[toc] | [prev] | [next] | [standalone]

#3297

On Apr 7, 11:31 am, gwowen <gwo...@gmail.com> wrote:
[snip]
> It's like this: what does following code do
>
> int k = 8, l = 9;
> int x = (k*k) - (7*l) ;
> if(x = l)  printf("x is one\n");
> if(x == l) printf("x is one\n");
>
> printf("%d\n",x);

It triggers comments from me in code review.
That's what it does.
Socks

[toc] | [prev] | [next] | [standalone]

#3305

On Apr 7, 11:49 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:

[snip many many lines]

>   This is my answer to what it does.

Right.  Because my code was really unclear.  You couldn't see
immediately, what was going on - not least because on many fonts  the
glyphs '1' and 'l' look very  similar.  The statements were all
simple, but the constructions had no clarity. It was written for a
compiler, not for a human, so it ridiculous a lot of work to untangle
it.

> Inded, I at least once mistyped = for == (while I knew
> the difference), but I can not remember having misread them.

Which is my point *exactly*, you write "Inded", but on a quick my mind
translates it to indeed.It is a well known truth that the human mind
sees language elements that aren't there, in order to fit the text to
established norms[0]. It's why we indent code in blocks - the
structure and logic of the algorithm is then obvious without having to
inspect every glyph. The indentation means nothing to the compiler, we
do it for the reader.

And tests in if() are a normal idiom, and assignments in if() are non-
idiomatic[0], so the brain has a tendency to see a test, even when you
wrote (and meant) and assignment.

You probably don't recall having misread them, because you've rarely
seen third-party code that uses them.  It's bad style, because its
sufficiently non-idiomatic to that it looks like an error.

But hey, its just style.  If you like it, be my guest, but I pity the
poor bastard who has to maintain your deliberately-unclear code. If
there's an alternative construction that isn't to tortuous, it
wouldn't pass code review here.  We write for people.

[0] see http://www.chiff.com/a/Ed_Word_Recog.htm - here the if() as
the short conjunctions that allow the mind to process the wider
meaning
[1] Sufficiently non-idiomatic for gcc -Wall to warn me its a possible
error.

[toc] | [prev] | [next] | [standalone]

#3313

On Apr 8, 8:33 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> gwowen <gwo...@gmail.com> writes:
> >You probably don't recall having misread them, because you've rarely
> >seen third-party code that uses them.
>
>   I thought to have seen this often in the C code I used to read.
>   The following looks very natural and idiomatic to me:
>
> if( f = fopen( ... ))...
> if( m = malloc( ... ))...

Actually, those ones I do see, although usually in the negation:
if((f=fopen(...) == NULL){
  // handle error
}

I'll accept those as exceptions, though because (i) fopen() and
malloc() are incredibly common, and everyone can be expected to know
how the signal failure (ii) FILE and void are (informally) opaque
types - you can't do anything to FILE* and void* directly, so return
value is essentially a bool.

Personally, since I can't declare f in the if(), and I believe in
initialisation on declaration, I'm still going to do

FILE* f = fopen();
if(f==NULL) {
  // handle error
}

char* ptr = malloc(32);
if(ptr == NULL) {
  // handle error
}

> while( *p++ = *q++ );

<BEGIN RANT TYPE="IRRATIONAL, BORDERING ON CERTIFIABLY CRAZY">
I hate that idiom with a passion - a single statement that does seven
things, in an order implicitly dependent on operator precedence. Its
the archetypal victory of cleverness over clarity. Like obscure
technical jargon, its well understood by people who've seen it before,
but a royal pain in the arse to decipher on first exposure. Perfectly
fine in short, low level library functions - unspeakable as part of a
longer algorithm.

This is not Perl golf - unless you can demonstrate, using profiling
and disassembly, that
(i) the compiler will produce more efficient code
(ii) this efficiency actually matters to overall performance.
introducing barriers to comprehension merely to increase brevity is
premature optimisation, and premature optimisation is a very bad idea.

I want my high level code to read like pseudo-code -- the closer the
code looks is to a language-agnostic description of the algorithm, the
easier it is to see its correctness. Separating high and low level
details also makes it easier to refactor.
<END IRRATIONAL RANT>

[toc] | [prev] | [next] | [standalone]

#6232

"gwowen" <gwowen@gmail.com> ha scritto nel messaggio
news:271770ff-8795-4719-8437-72ae2268751a@z31g2000vbs.googlegroups.com...
On Apr 8, 8:33 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> gwowen <gwo...@gmail.com> writes:
> >You probably don't recall having misread them, because you've rarely
> >seen third-party code that uses them.
>
> I thought to have seen this often in the C code I used to read.
> The following looks very natural and idiomatic to me:
>
> if( f = fopen( ... ))...
> if( m = malloc( ... ))...

Actually, those ones I do see, although usually in the negation:
if((f=fopen(...) == NULL){
  // handle error
}

I'll accept those as exceptions, though because (i) fopen() and
malloc() are incredibly common, and everyone can be expected to know
how the signal failure (ii) FILE and void are (informally) opaque
types - you can't do anything to FILE* and void* directly, so return
value is essentially a bool.

Personally, since I can't declare f in the if(), and I believe in
initialisation on declaration, I'm still going to do

FILE* f = fopen();
if(f==NULL) {
  // handle error
}

char* ptr = malloc(32);
if(ptr == NULL) {
  // handle error
}

> while( *p++ = *q++ );

io> this below is clearer for me
io> while(9){*j=*i; if(*i==0) break; ++j; ++i;}

<BEGIN RANT TYPE="IRRATIONAL, BORDERING ON CERTIFIABLY CRAZY">
I hate that idiom with a passion - a single statement that does seven
things, in an order implicitly dependent on operator precedence. Its
the archetypal victory of cleverness over clarity.

io> exist only what is written in the paper
io> so hidden ficturares, and macro that hide code, are wrong

Like obscure
technical jargon, its well understood by people who've seen it before,
but a royal pain in the arse to decipher on first exposure. Perfectly
fine in short, low level library functions - unspeakable as part of a
longer algorithm.

This is not Perl golf - unless you can demonstrate, using profiling
and disassembly, that
(i) the compiler will produce more efficient code
(ii) this efficiency actually matters to overall performance.
introducing barriers to comprehension merely to increase brevity is

io> brevity is good, what is not good is the brevity that not make
io> the aye to see what happen

premature optimisation, and premature optimisation is a very bad idea.

I want my high level code to read like pseudo-code -- the closer the
code looks is to a language-agnostic description of the algorithm, the

io> the key point is if the languages scale well with complexity
io> and the complexity "kills" :)

easier it is to see its correctness. Separating high and low level
details also makes it easier to refactor.
<END IRRATIONAL RANT>

[toc] | [prev] | [next] | [standalone]

#3356

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Ram wrote:

> gwowen <gwowen@gmail.com> writes:
>>You probably don't recall having misread them, because you've rarely
>>seen third-party code that uses them.
> if( o )...
> 
>   for a class instance o can mean anything, which has to be
>   looked up in the documentation of the class.

It is unclear because it uses one-letter variable name. If the name is more 
descriptive, the meaning will be clear.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk2ga+EACgkQZ1Turg5KUClSagCeMaRv/KbRXK17IPP/MeeeAkEw
WQgAn1L7sLGuWtr8H5NA2e0k0WrlZG1h
=JRup
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#3314

On 07-04-2011 16:02, gwowen wrote:
> On Apr 7, 2:17 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> gwowen<gwo...@gmail.com>  quotes Abelson and Sussman:
>>
>>> Programs should be written for people to read
>>
>>    Yes, but obviously for people who already
>>    /know the programming language/.
>
> Yes, but that doesn't mean that all valid language constructs are
> equally easy to maintain even for people skilled in the language ...
> that's, if not demonstrably untrue, then at least widely considered
> untrue.
>
> Code that can be immediately and correctly understood at a glance is
> easier to maintain than code that is a single glyph different from far-
> more-common idiom with wildly different semantics.
>
> "if(y == f()){}" is common, idiomatic C. "if(y = f()){}" is not.
Common is "if(f()==y){}"  and "if(y=f(x))". Those construction are hard 
t to be mistaken.  The new age programmers intro introduced
awful "if(y==f(x))" which can be mistaken with "if(y=f(x))".


Regards

Marek

[toc] | [prev] | [next] | [standalone]

#3315

On Apr 8, 12:23 pm, Marek Borowski <marek_remo...@borowski.com> wrote:

> The new age programmers intro introduced ...

who where the what now?

[toc] | [prev] | [next] | [standalone]

#3338

On Apr 7, 9:09 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> gwowen <gwo...@gmail.com> writes:
> >"if(y == f()){}" is common, idiomatic C. "if(y = f()){}" is not.
>
>   To me, the meaning of both is immediately obvious.


And to me.  *But* the second form will immediately send me off trying
to figure out if assignment was actually intended instead of
comparison, and thus is a hindrance to understanding the code, because
of the time taken on the side trip.  The "if ((y=f())!=0)" form at
least makes it obvious what was intended.

[toc] | [prev] | [next] | [standalone]

#3340

On 09/04/2011 00:12, Stefan Ram wrote:
> "robertwessel2@yahoo.com"<robertwessel2@yahoo.com>  writes:
>> The "if ((y=f())!=0)" form at
>> least makes it obvious what was intended.
>
>    Not to me! Therefore, I have to ask:
>
>        - What is it that was intended?
>
>        - And how does it make this obvious?

The act of adding the extra parenthesis is an affirmation that 
assignment was intended (and it can inhibit a compiler warning that 
comparison was perhaps intended).

/Leigh

[toc] | [prev] | [next] | [standalone]

#3354

On Apr 8, 6:12 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> "robertwess...@yahoo.com" <robertwess...@yahoo.com> writes:
> >The "if ((y=f())!=0)" form at
> >least makes it obvious what was intended.
>
>   Not to me! Therefore, I have to ask:
>
>       - What is it that was intended?
>
>       - And how does it make this obvious?


By making both the assignment and the comparison explicit, it's clear
(FSVO "clear") that both were intended.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web