From: ImpalerCore on
On Mar 5, 12:13 pm, la...(a)ludens.elte.hu (Ersek, Laszlo) wrote:
> In article <4JydnbCdGNgatgzWnZ2dnUVZ7rydn...(a)bt.com>,
>
> Richard Heathfield <r...(a)see.sig.invalid> writes:
> > Ersek, Laszlo wrote:
> >> Because when read out loud, "i" is the subject.
>
> > Again, your comment would only be relevant if this were English, which
> > it isn't.
>
> Exactly -- I'm a staunch member of the "7 == x" camp. I just tried to
> explain why, as I perceive, Seebs thinks what he thinks. (Sorry if this
> qualifies as bad etiquette.)

Are you a staunch member of the '7 == x' because of style, or because
of the possibility of catching '7 = x' errors? I personally don't
like the style simply because it *is* more mind taxing, and it's a
result of not seeing code in that style, not writing code in that
style, and not thinking about code in that style, for about 8 years
between C++ and C, that my brain has been conditioned that way. I
would be bold enough to say that a large majority of C programmers are
conditioned that way, simply from other people's code and books that
I've seen.

Perhaps you would allow me to scramble the characters on your keyboard
in a way of my choosing that is better? Let's take 'asdfjkl;' and
make it 'arstenil' since those d, f, j, k, and ';' characters are used
much less often, and it requires more finger movement, causing more
cases of carpal tunnel syndrome. Would you be willing to give that a
try? The example is a bit hyperbolish, but that's how it feels to me
looking at '7 == x'.

And the thing is that you may actually like that keyboard better, but
everyone else will still use the standard keyboard, and still complain
if they have to use your keyboard. The inertia of the original style
'x == 7' is too large enough to overcome unless that style has
generated so many problems that I'm motivated to try out '7 == x'. If
you suffered from carpal tunnel syndrome, you may be tempted to give
the new keyboard a try.

I actually went through this process with single line if statements.

if ( condition )
statement;

I have been bitten by this syntax (spending hours pouring over code
where my brain is not registering the syntax error) so many times that
the bracket style

if ( condition ) {
statement;
}

has become my convention. It has saved me time because for whatever
reason, my brain can deal with the syntax errors better.

Lastly, I have no problem with someone wanting to use '7 == x' if it
really does help them from a style perspective. I have an issue when
people use the style just to catch '7 = x' errors when 'x == 7' would
be easier to understand. Hey, I still use 'char* p' simply because I
started in C++ and moved to C, and it's easier for me to use. I'm
sure there are a host of people that will belittle me for still using
that syntax, and I realize I may be in the minority, but I'll still
keep using it since it's more work to relearn and restyle the code
I've already written than to appease the majority.

Again, if I have to work with a team, and it's decided to use 'char
*p', I will gladly acquiesce, but unless I'm forced to code that way
for a long time, I don't foresee myself changing my ways.

Best regards,
John D.

> Cheers,
> lacos

From: Seebs on
On 2010-03-05, Ike Naar <ike(a)localhost.claranet.nl> wrote:
> In article <slrnhp1a11.hqg.usenet-nospam(a)guild.seebs.net>,
> Seebs <usenet-nospam(a)seebs.net> wrote:
>>I disagree. I was raised by mathematicians, but I view statements and
>>expressions as often being written to communicate additional meaning.

> But you must be careful not to assign additional meaning if it was
> unintended by the author.

You can never avoid both Type 1 and Type 2 errors completely. For the most
part, the benefits of assuming that idioms are intentional massively outweigh
the costs of perceiving an idiom was not intended.

> If you read my code, it would be unfortunate if you would conclude, from the
> bare fact that I wrote the addition as (a+b), that a is the larger of
> the two.

And I wouldn't draw any such conclusion. I might, however, think that a
was in some way the "base" value.

a[i] is in theory equally equivalent to both *(a+i) and *(i+a). However,
it is EXTREMELY unusual to write i+a -- because we know that we are adding
an offset to a pointer, not adding a pointer to an offset. That they do
the same thing doesn't matter. The pointer is the one which tells us what
the operation is doing.

> But that perception could be misleading.

Yes, it could.

Heuristics don't have to be 100% reliable to be worth using.

> Another reason might be that "i < 10" and "10 >= i" are not the same thing.

Whoops. >, not >=. I'm bad at symmetry sometimes. Or alternatively,
probably, "9 >= i".

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on
On 2010-03-05, Richard Heathfield <rjh(a)see.sig.invalid> wrote:
> I don't see how you get that y can't vary, just from seeing if(x != y).

I don't.

I just get the impression that it is much less likely to be the member
whose value is in question.

And I'd guess that if you took a random sample of C code (say, a hundred lines
from each of a couple thousand projects), you'd find that this was true
in the VAST majority of cases. Well over 90%.

Note that a limit like "max" is invariant *in context*, normally.

while (i < len)

usually means that, for the duration of the loop, i will be changing and len
won't. Not always, but it's true often enough that exceptions are surprising.

> It's been done both ways before.

But one of them much, much, more often.

> Then, much of the time, you expect the wrong thing, since much of the
> time there is no invariant involved. If you were reading my code, you
> would very often find that, where an invariant /is/ involved in a
> comparison for equality, it's on the left. So your preconceptions would
> mislead you.

With your code, yes. So I'd realize you were one of the people who does
it the other way. Same as, if I went to England and noticed people driving
on the wrong side of the road, after a couple of hours I'd be used to that.

> I am always suspicious of "we do it this way because most people do it
> this way". Sturgeon's Law and all that. I'm not saying we should do Y
> *because* most people do X; but following the crowd *just* for the sake
> of following the crowd is very often a bad idea, because the crowd is
> very often heading in the wrong direction.

There is no significant objective advantage to either... But, as with the
side of the road, there is a substantial advantage to having everyone agree.

> Sure. So which one is the constant you were expecting to see?

Neither. But I'm fine with a heuristic being imperfect. They are.

It's just that, IF there is one that's more changeable than the other, I
expect it to be on the left.

>> K&R. I don't think you'll find a single test in there which goes the
>> other way.

> That's a rather weak basis for claiming a "standard idiom".

It works for 1TBS.

And again, consider why it is that every test in K&R, and in King's book (I
believe), and anywhere else I've looked, uses the same idiom. One of the
reasons is that, having seen it that way, people tend to expect it and write
it that way, and the net result is additional communication.

It's like indentation. We indent code to make it reasonable. We do not,
to borrow your phrase, "keep in mind what the brackets do with their contained
blocks" and ignore indentation conventions; we use them because presenting
things with consistent structure makes it easier for people to chunk the
information and process it effectively.

Imagine that you have two code bases, which are precisely identical, except
that in one of them, this idiom is used consistently wherever it applies, and
in the other, the first code base has been copied, and then half of the
comparisons have had their operands flipped (and the operator changed if
needed). Now have a large number of people try to find a number of difficult
bugs in them.

I would bet you that you would notice a measurable performance cost to the
reliability and speed of debugging from losing the idiom, especially if the
tests were significant to the bugs. It's only a few cycles here and there, or
one slot of short term memory, but sometimes that's what makes the difference
between catching something and not catching it.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on
On 2010-03-05, Ersek, Laszlo <lacos(a)ludens.elte.hu> wrote:
> ... It's either me, or now two of you not noticing (or ignoring) that
> "10 == i" satisfies the second but not the first.

I often introduce fencepost errors when I swap relationships. No idea
why. It's the same as my mysterious inability to learn to reliably add
single-digit numbers. (I can do it about 95% of the time, give or take.)

> Because programmatically, "i" changes over time, 10 does not, and when
> one reads out loud the controlling expression in English, the subject of
> that sentence ("the actor") should be the entity that is acting.

That's pretty much it.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on
On 2010-03-05, Ersek, Laszlo <lacos(a)ludens.elte.hu> wrote:
> Yes, I thought (and think) that that was not unpossible. If my memory
> serves, both Keith and Seebs have pointed out that they need to reorder
> reverse-ordered relational operators in their heads (sorry if I'm making
> this up now) or that it causes extra mental load or something to that
> effect. So the typo may be related to the reversing process.

It probably is. Actually, that's clarified it. Here's the thing.

(x < 10)
!(x >= 10)

That kind of reversal requires adding/removing an =. So if I'm flipping
a comparison relationship, I'm likely to add/remove an =. It turns out
that merely changing the direction isn't the same thing as flipping.

(x < 10)
(10 > x)
!(x >= 10)
!(10 <= x)

.... Yup. I got the >< in the second pair wrong on the first try, had to
go back and think about them.

I can do one flip or the other, usually, but if two of them are on offer,
I tend to screw them up.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
First  |  Prev  |  Next  |  Last
Pages: 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Prev: integer
Next: shared memory question