Esoteric definitions of TRUE and FALSE

[Tim Rentsch]

(e-mail address removed)-berlin.de (Stefan Ram) writes:

This is a vacuous statement unless some effort is made to
identify which reasons might be sufficiently compelling
to justify a longer wording and which others are not.

I disagree. There can be any number of reasons to prefer one equivalent
wording over another, and those reasons can vary wildly depending on
the problem domain. [snip example]

I believe you have misunderstood my statement. I'm not saying
there is never any reason to prefer one wording over another,
only that the quoted "general style guideline" doesn't tell
us anything. Basically all it says is, "you should use the
shorter form, except when you shouldn't". True statement,
but it doesn't tell us anything we didn't already know.

 

[Stefan Ram]

all it says is, "you should use the shorter form, except when
you shouldn't".

When two wordings are equivalent, and you are not aware
of a significantly good reason to prefer one of them,
use the shorter one.

(»Significantly good« is still vague, but this vagueness is
intended to give the user of this rule some freedom for his
personal taste.)

 

[Tim Rentsch]

When two wordings are equivalent, and you are not aware
of a significantly good reason to prefer one of them,
use the shorter one.

(>>Significantly good<< is still vague, but this vagueness is
intended to give the user of this rule some freedom for his
personal taste.)

Sounds suspiciously like "Choose the shorter unless you
think it should be longer." That advice doesn't provide
any meaningful content.

Also, if there is a significantly good reason to prefer
one wording over another, the two wordings are not
equivalent, are they?

 

[Keith Thompson]

Sounds suspiciously like "Choose the shorter unless you
think it should be longer." That advice doesn't provide
any meaningful content.

I tend to agree.

Also, if there is a significantly good reason to prefer
one wording over another, the two wordings are not
equivalent, are they?

I'd say that clarity is a "significantly good reason", even when the two
forms are exactly equivalent as far as the language is concerned.

For example, I find
if (c != '\0')
clearer than
if (c)

(Yes, I know others might find the shorter form clearer.)

 

[J. J. Farrell]

Sounds suspiciously like "Choose the shorter unless you
think it should be longer." That advice doesn't provide
any meaningful content.

Certainly it does. I come to write a line of code; two ways of writing
it are immediately obvious to me, one longer than the other. Both have
pros and cons, the merits of which I judge to be equal. I can dither for
ever in an agony of indecision, or I can toss a coin, or I can turn to
the style guide. This rule deals exactly with this situation, albeit a
situation which is probably vanishingly rare.

Also, if there is a significantly good reason to prefer
one wording over another, the two wordings are not
equivalent, are they?

The wordings being equivalent is from the compiler's point of view but
the reason for the choice is from the coder's point of view.

 

[Stefan Ram]

Sounds suspiciously like "Choose the shorter unless you
think it should be longer." That advice doesn't provide
any meaningful content.

This was not what I wrote. But it has meaningful content.

Also, if there is a significantly good reason to prefer
one wording over another, the two wordings are not
equivalent, are they?

»Equivalent« means »semantically equivalent«, here.

 

[Stefan Ram]

»Equivalent« means »semantically equivalent«, here.

Another attempt:

When two pieces if code are semantically equivalent, their
overall fitness is given as a function of the estimated
performance, the estimated readability, the length, and
other factors, which can be approximated as

a · estimated_performance +
b · estimated_readability +
c · lenght + ...

. In my case, c is negative and possibly smaller than in
the case of the average of the programmers.

 

[Tim Rentsch]

Certainly it does. I come to write a line of code; two ways of writing
it are immediately obvious to me, one longer than the other. Both have
pros and cons, the merits of which I judge to be equal. I can dither
for ever in an agony of indecision, or I can toss a coin, or I can
turn to the style guide.

If I may paraphrase: "If you can't find any other reason
to prefer one over the other, always choose the shorter one."

That still doesn't offer any guidance as to what reasons
might be good reasons to prefer one or the other, which
is my point.

This rule deals exactly with this situation,
albeit a situation which is probably vanishingly rare.

The rarity depends on unstated and unknown factors, and
could range anywhere from 0 to 1 depending on how those
are chosen. The same point.

The wordings being equivalent is from the compiler's point of view but
the reason for the choice is from the coder's point of view.

One might have said so in the first place. The
original statement didn't have this meaning.

 

[Tim Rentsch]

This was not what I wrote.

No, it isn't. That's why I said "sounds suspiciously like".

But it has meaningful content.

In the same way that a Rorschach test has meaningful content?
What it means is all in the eye of the beholder.


Then say so. I can't respond to what you're thinking,
only what you write.

 

[Tim Rentsch]

Another attempt:

When two pieces if code are semantically equivalent, their
overall fitness is given as a function of the estimated
performance, the estimated readability, the length, and
other factors, which can be approximated as [edited]

a * estimated_performance +
b * estimated_readability +
c * length + ...

. In my case, c is negative and possibly smaller than in
the case of the average of the programmers.

Now we're starting to get somewhere...

 

[Keith Thompson]

Equivalent<< means >>semantically equivalent<<, here.

Another attempt:

When two pieces if code are semantically equivalent, their
overall fitness is given as a function of the estimated
performance, the estimated readability, the length, and
other factors, which can be approximated as [edited]

a * estimated_performance +
b * estimated_readability +
c * length + ...

. In my case, c is negative and possibly smaller than in
the case of the average of the programmers.

Now we're starting to get somewhere...

Yes, to a possible record for the longest conversation about
conciseness. }

 

[Stefan Ram]

Yes, to a possible record for the longest conversation about
conciseness. }

« Je n'ai fait celle-ci plus longue que parce que je
n'ai pas eu le loisir de la faire plus courte. »

Blaise Pascal, Lettres Provinciales, XVI, 14 Dec 1656

 

[Keith Thompson]

« Je n'ai fait celle-ci plus longue que parce que je
n'ai pas eu le loisir de la faire plus courte. »

Blaise Pascal, Lettres Provinciales, XVI, 14 Dec 1656

Now, if we can just keep this thread going for another 355 years ...

 

[John Gordon]

Basically all it says is, "you should use the shorter form, except when
you shouldn't". True statement, but it doesn't tell us anything we
didn't already know.

Fair enough.

It does say, though, that length is not the only criteria; without that
exception, some writers might feel obligated to always use the shorter
phrasing.

 

[Tim Rentsch]

Basically all it says is, "you should use the shorter form, except when
you shouldn't". True statement, but it doesn't tell us anything we
didn't already know.

Fair enough.

It does say, though, that length is not the only criteria; [snip]

It implies that, yes, and also implies that there are
circumstances where length will be the only important
determining factor. My complaint (if it may be called
a complaint) is that nothing is said about where the
dividing line is between the two kinds of criteria.