Prev: integer
Next: shared memory question
From: Vladimir Jovic on 4 Mar 2010 09:02
Keith Thompson wrote:
> Vladimir Jovic <vladaspams(a)gmail.com> writes:
>> Scott Lurndal wrote:
>>> I personally place the condition operator at the front, as
>>> William does, but nested.
>>>
>>> if ((pointer1 != NULL)
>>> && (pointer1->field7 == 0x152)) {
>>> return;
>>> }
>> if ( ( pointer1 =! NULL )
>> && ( pointer1->field7 = 0x152 ) ) {
>> return;
>> }
>>
>> ops && ops
>
> if ( pointer1 != NULL &&
> pointer1->field7 == 0x152 )
> {
> return;
> }
>
> I put the opening brace on the same line as the "if" if it fits.
> If it doesn't, I put it on a line by itself, so it doesn't get lost.
> It's probably not entirely consistent, but it works well for me.
>
> Note that I also dropped some extraneous parentheses. Too many
> parentheses can be as confusing as too few, and I think it's
> sufficiently obvious that "==" and "!=" bind more tightly than "&&".
> The alignment of the subexpressions helps.
>
> I do not suggest that my style is the only correct one.
>

Yes, you missed the point. I prefer this way :

if ( NULL != pointer1 &&
0x152 == pointer1->field7 )
{
return;
}

Can save you some debugging time :)
From: Casper H.S. Dik on 4 Mar 2010 09:25
Vladimir Jovic <vladaspams(a)gmail.com> writes:

>Yes, you missed the point. I prefer this way :

>if ( NULL != pointer1 &&
> 0x152 == pointer1->field7 )
> {
> return;
> }

>Can save you some debugging time :)

But it makes the code much more difficult to read.

You're not testing that NULL now has a different value or that
0x152 has a different value.


Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
From: Richard on 4 Mar 2010 09:40
Vladimir Jovic <vladaspams(a)gmail.com> writes:

>
> Yes, you missed the point. I prefer this way :
>
> if ( NULL != pointer1 &&
> 0x152 == pointer1->field7 )
> {
> return;
> }
>
> Can save you some debugging time :)
>

I congratulate you : it has everything that sucks in pseudo styling.

1) unnecessary waste of vertical screen usage
2) horrible "Non english" comparisons.

When discussing vars in computing it is normal to discuss the variables
b name.

You dont say "if pi is larger than p".You say "if p is larger than
pi". You're style is nothing more than fancy for fancy's sake IMO.

> if (pointer1 && pointer1->field7==0x152)
> return;

Is less code and more readable and doesnt use any clever clogs
reversals.


--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
From: John Gordon on 4 Mar 2010 10:52
In <oct467-nu6.ln1(a)news.eternal-september.org> Richard <rgrdev_(a)gmail.com> writes:

> When discussing vars in computing it is normal to discuss the variables
> b name.

> You dont say "if pi is larger than p".You say "if p is larger than
> pi". You're style is nothing more than fancy for fancy's sake IMO.

No, it does actually do something: it will throw a compile error if you
mistype == as =.

To demonstrate, imagine that you intended to type this:

if (x == 7)

But you mistakenly typed this:

if (x = 7)

This is legal code but will not behave in the way you intended.

But if you had typed it this way:

if (7 = x)

The compiler will throw an error.

--
John Gordon A is for Amy, who fell down the stairs
gordon(a)panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

From: Nicolas George on 4 Mar 2010 10:53
John Gordon wrote in message <hmokvi$53g$1(a)reader1.panix.com>:
> No, it does actually do something: it will throw a compile error if you
> mistype == as =.

Any half-decent compiler can throw a warning for that.
First  |  Prev  |  Next  |  Last
Pages: 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
Prev: integer
Next: shared memory question