Is this C program doing what it is supposed to do ?

[Michael Press]

I think it might well be too much to hope for. I don't know of any
formal studies on this issue. In the absence of any such studies
we can point to, any discussion is bound to be overwhelmed by
personal opinion.

There is an entire field of study devoted to
what makes a document easier to assimilate,
and how to read for content, and how to keep
from being sidetracked. For one thing you can totally
ignore section and chapter headers when the reading text.

If you want to have a more objective discussion, perhaps you can find
some studies for us to discuss.

I have not looked into this recently. Perhaps I will.

 

[Keith Thompson]

There is an entire field of study devoted to
what makes a document easier to assimilate,
and how to read for content, and how to keep
from being sidetracked. For one thing you can totally
ignore section and chapter headers when the reading text.

How does that field of study apply to programming languages?

 

[Michael Press]

[...]
I was hoping the conversation would move away from just
being statements of personal opinion, in the general
direction of findings that are objective, verifiable, or
quantifiable. And I'm still optimistic enough to think
that's not too much to hope for.

I think it might well be too much to hope for. I don't know of any
formal studies on this issue. In the absence of any such studies
we can point to, any discussion is bound to be overwhelmed by
personal opinion.

There is an entire field of study devoted to
what makes a document easier to assimilate,
and how to read for content, and how to keep
from being sidetracked. For one thing you can totally
ignore section and chapter headers when the reading text.

How does that field of study apply to programming languages?

By reading the literature, marking important notions,
assimilating them, applying one's intelligence, and
recognizing those notions in one's own field. You do
not know me, and you do not trust Tim Rentsch.
Nevertheless, he knows whereof he speaks.

Repetition, redundancy, and saying the same thing in
different ways is typically a good thing in various
fields. In mathematics and program code it is a
hindrance. We have a language to say exactly what we
mean. Saying more distracts. Do you have to think upon
encountering "at_beginning = ch == '\n';"? The only
pause for thought is to assess who wrote it. If you
already know it is one of the greats, you do not pause
for long. If the writer is unknown to you---well, there
you are.

I choose to write to as high a level as I can reach,
and explain as necessary when asked.

 

[Keith Thompson]

By reading the literature, marking important notions,
assimilating them, applying one's intelligence, and
recognizing those notions in one's own field. You do
not know me, and you do not trust Tim Rentsch.
Nevertheless, he knows whereof he speaks.

Perhaps my question was unclear. What I meant was, how do those
who engage in that field of study (which, as you described it,
seems to apply primarily to natural-language documents) apply it
to programming languages?

You imply (and I certainly don't doubt it) that there are extensive
studies regarding making natural-language documents easierto read.
Are there similar studies that apply to programming languages?

(I do not mean to suggest that there are no such studies. I'm just
asking.)

 

[Tim Rentsch]

I think it might well be too much to hope for. I don't know of any
formal studies on this issue.

Even if you don't know of any formal studies you can move in the
direction of more objective discussion. There may be informal
studies, or anecdotal evidence. One can do personal experiments
and report on those. Or propose an experiment and ask for
comments. Even more fundamental, there is a question of what to
measure. What does it mean for something to be "more readable"?
What measure(s) would quantify that? Any of those would be an
improvement over simply stating a personal opinion and nothing
else.

In the absence of any such studies
we can point to, any discussion is bound to be overwhelmed by
personal opinion.

That depends on the participants. A journey of a thousand
miles starts with a single step.

 

[Tim Rentsch]

ImpalerCore <[email protected]> writes:

[... discussing 'a = b == c;' vs 'a = (b == c);' ...]

Put simply, if the expected statement is [a = b == c;] and the two
typo statements are [a = b = c;] or [a = (b = c);], I would detect the
second typo with less effort. [snip elaboration]

So is it fair to say you also are just expressing a personal
opinion?

Sure it's my personal opinion, but the style of using of parentheses
to emphasize precedence is pretty common in the teaching and books used
when I was learning C and C++.

Remember Dijkstra's admonition: don't think something is _convenient_
just because it is _conventional_. Advising students to use extra
parentheses has been around at least since the 1960's when I first
learned how to program. Offered in beginning classes, it's the
programming equivalent of training wheels on a bicycle -- useful to
get people started, but no real help once the necessary skills have
been acquired. I no longer use training wheels on my bicycle, and I
don't think it's important in my everyday riding to cater to beginners
who still need them.

Use of spaces, not so much. In fact I
think you're the first person I've met that advocates using space over
parentheses to emphasize precedence in the manner you're describing.

People used to think the Earth was the center of the universe and
everything else revolved around it. Are you charging me with being
a heretic? Just because you're hearing an idea for the first time
doesn't mean the idea is bad; it's much more convenient to think of
the Earth as going around the Sun than vice versa, as repulsive as
that idea was to people when it was first proposed.

It would be nice if you tried to engage in an actual discussion
of the merits and shortcomings of a proposed alternative, rather
than just making an ad hominem remark and dismissing it.

No seriously, I didn't intend anything as an ad hominem. I have
simply not encountered it. I have not seen fellow posters rush to
defend your style as common. Sorry if it insulted you.

I didn't take it that way. I was just making a factual
observation that your comment is a lot more about me than it
is about the idea. Even though a remark isn't insulting or
belittling it still can be ad hominem.

Well, you sure sounded insulted. [snip elaboration]

No, just disappointed.

I think I'll just let the topic go from here on.

Have you said anything more than "here is my opinion,
and I think a lot of other people share the same
opinion"?

Nope. Again, I don't consider whether you use whitespace or
parentheses good or bad; I can read either fine. I choose as a habit
to use them to emphasize precedence; you don't like them. We don't
work on the same code, so it's not an issue. I don't think there's
much else to say.

I was hoping the conversation would move away from just
being statements of personal opinion, in the general
direction of findings that are objective, verifiable, or
quantifiable. And I'm still optimistic enough to think
that's not too much to hope for.

I think it's hard to have that conversation when most style
preferences (in my opinion) lie in the realm of personal opinion.

I don't agree with that thesis. Or to say that another way,
different people make different choices because they have
chosen (often unconsciously) to optimize different metrics.
Sometimes this is labelled as "personal opinion", but in
many cases (most cases?) there is an underlying mechanism
that explains the different choices. Some people may refuse
to examine themselves to find out why they make the choices
they do, but I think anyone who is willing to join the
conversation would benefit from trying to discover a more
a more quantifiable result than just "here's what I think".

I should say explicitly: I don't mean to imply that everyone
is the same - certainly different nervous systems are different,
and what you find easy I may find difficult and vice versa. Still
we can try to be objective about what really makes a difference
(to each individual and also to groups as a whole).

It's like trying to find evidence that demonstrates that the 1TBS is
objectively superior to another.

In fact there have been studies about bracing styles that
have produced results that appear to apply to essentially
all people, but let's not get off on that tangent right
now.

From a single person's perspective,
I can agree that there are cognitive advantages to using one over
another. I believe that you do understand the version without
parentheses better.

I _understand_ both versions. It's just that I have to put in
more effort to read the one with redundant parentheses.

The main issue with style is when multiple programmers (with varying
levels of experience, preferences) are involved. Do you allow each
programmer to use their best cognitive style, while sacrificing
overall code consistency? Do you try to have a consistent style
throughout a project at the cost of varying levels of individual
comprehension? I don't know the answers to these questions.

The answers depend on who is involved. The point of my comments
is to get people talking about their different reactions in a way
that's productive rather than counter-productive. Simply stating
a personal opinion and nothing more is not productive. If someone
isn't willing to try to have an objective conversation about their
style preferences there isn't much point in engaging them. Which
group would you rather be part of?

 

[Tim Rentsch]

[snip] [Parentheses can be]
used to emphasize existing grouping. In fact I often use them that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

I do this very often.

In fact, I have absolutely no idea whether I'm using them to change
grouping or to emphasize grouping. I just use them to show what grouping
I intend, and I don't waste my limited cognitive bandwidth trying to guess
whether or not I'd have gotten that grouping anyway.

That seems reasonable, as long as you don't think it necessarily
applies to people who are not mentally differently-abled in the
way that you are.

I believe it does.

Let me see if I have this right. You believe this practice
_necessarily_ applies to all people, regardless of the
strengths and balance of their different brain functions;
that it's the best choice of tradeoffs among all the
choices that anyone could make, regardless of the individual;
that if someone else has a different opinion about the
right practice for themselves, that their opinion is wrong
and yours is right. Because if you say it "necessarily
applies" then that's what it sounds like you're saying.

 

[Keith Thompson]

[snip] [Parentheses can be]
used to emphasize existing grouping. In fact I often use them that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

I do this very often.

In fact, I have absolutely no idea whether I'm using them to change
grouping or to emphasize grouping. I just use them to show what grouping
I intend, and I don't waste my limited cognitive bandwidth trying to guess
whether or not I'd have gotten that grouping anyway.

That seems reasonable, as long as you don't think it necessarily
applies to people who are not mentally differently-abled in the
way that you are.

I believe it does.

Let me see if I have this right.

You don't.

You believe this practice
_necessarily_ applies to all people, regardless of the
strengths and balance of their different brain functions;
that it's the best choice of tradeoffs among all the
choices that anyone could make, regardless of the individual;
that if someone else has a different opinion about the
right practice for themselves, that their opinion is wrong
and yours is right. Because if you say it "necessarily
applies" then that's what it sounds like you're saying.

No, I merely meant that it does apply to at least some such people.

You'll note that I didn't say that your statement was false.
You said it doesn't *necessarily* apply; I say it does apply.

 

[Chris H]

[snip] [Parentheses can be]
used to emphasize existing grouping. In fact I often use them that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

I do this very often.

In fact, I have absolutely no idea whether I'm using them to change
grouping or to emphasize grouping. I just use them to show what grouping
I intend, and I don't waste my limited cognitive bandwidth trying to guess
whether or not I'd have gotten that grouping anyway.

That seems reasonable, as long as you don't think it necessarily
applies to people who are not mentally differently-abled in the
way that you are.

I believe it does.

So do I.

I will go further.....

This is the way we will do it because it works for the majority. It
makes things more readable and therefore safer. If it does not work
that way for you not a problem. You will just not be on the
team/project/company. Please go away.

BTW this will include any source code supplied under contract. It *WILL*
be to this coding standard.

Harsh? Maybe but try asking a military training instructor if you can
do things a little differently because you are "mentally differently
able" and see what he says..... not a chance because people's lives
depend on things behaving in a certain way when under stress.

Now that may not seem a relevant analogy but in most high reliability
and safety critical systems it comes down to mistakes cost lives. For
most non critical Sw it does not directly cost lives but just costs time
and or money.... which may have knock on effects.

There is a time and place for "mentally differently-abled" but it is not
a right to be different on my time/money.

Architects design some wonderful buildings but they have a pile of rule
books called the laws of physics. Then a pile of rule books called the
rules of Engineering, another pile called the rules of health and safety
and finally another pile larger than the rest called Local Planning
Laws.

Yes they still design these wonderful and varied buildings with artistic
flair and imagination..

It is about time the children writing software grew up and behaved as
professionals: there are rules you need to work to that have been shown
to be good. Either work to them or work somewhere else.

 

[Keith Thompson]

[snip] [Parentheses can be]
used to emphasize existing grouping. In fact I often use them that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

I do this very often.

In fact, I have absolutely no idea whether I'm using them to change
grouping or to emphasize grouping. I just use them to show what grouping
I intend, and I don't waste my limited cognitive bandwidth trying to guess
whether or not I'd have gotten that grouping anyway.

That seems reasonable, as long as you don't think it necessarily
applies to people who are not mentally differently-abled in the
way that you are.

I believe it does.

So do I.

I will go further.....

This is the way we will do it because it works for the majority. It
makes things more readable and therefore safer. If it does not work
that way for you not a problem. You will just not be on the
team/project/company. Please go away.

BTW this will include any source code supplied under contract. It *WILL*
be to this coding standard.

[...]

What coding standard are you referring to?

I presume you wouldn't require parentheses in *all* cases, making the
precedence rules superfluous. For example, I presume you'd accept
x = y + z;
rather than
x = (y + z);
(assuming more sensible names).

What rules would you impose?

 

[Chris H]

On 02/15/11 07:24 AM, Keith Thompson wrote:
[snip] [Parentheses can be]
used to emphasize existing grouping. In fact I often use them that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

I do this very often.

In fact, I have absolutely no idea whether I'm using them to change
grouping or to emphasize grouping. I just use them to show what grouping
I intend, and I don't waste my limited cognitive bandwidth trying
to guess
whether or not I'd have gotten that grouping anyway.

That seems reasonable, as long as you don't think it necessarily
applies to people who are not mentally differently-abled in the
way that you are.

I believe it does.

So do I.

I will go further.....

This is the way we will do it because it works for the majority. It
makes things more readable and therefore safer. If it does not work
that way for you not a problem. You will just not be on the
team/project/company. Please go away.

BTW this will include any source code supplied under contract. It *WILL*
be to this coding standard.

[...]

What coding standard are you referring to?

The house coding standard. (What ever that is)

What rules would you impose?

(To the tune of "If I ruled the world" or " Crown imperial" )

The following rules will be obeyed...

Probably something based on MISRA -c or C++

 

[Keith Thompson]

In message <[email protected]>, Ian Collins <ian-
(e-mail address removed)> writes
On 02/15/11 07:24 AM, Keith Thompson wrote:
[snip] [Parentheses can be]
used to emphasize existing grouping. In fact I often use them that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

I do this very often.

In fact, I have absolutely no idea whether I'm using them to change
grouping or to emphasize grouping. I just use them to show what grouping
I intend, and I don't waste my limited cognitive bandwidth trying
to guess
whether or not I'd have gotten that grouping anyway.

That seems reasonable, as long as you don't think it necessarily
applies to people who are not mentally differently-abled in the
way that you are.

I believe it does.

So do I.

I will go further.....

This is the way we will do it because it works for the majority. It
makes things more readable and therefore safer. If it does not work
that way for you not a problem. You will just not be on the
team/project/company. Please go away.

BTW this will include any source code supplied under contract. It *WILL*
be to this coding standard.

[...]

What coding standard are you referring to?

The house coding standard. (What ever that is)

What rules would you impose?

(To the tune of "If I ruled the world" or " Crown imperial" )

The following rules will be obeyed...

Probably something based on MISRA -c or C++

And what if the house coding standard forbids extraneous parentheses?

Are you actually disagreeing with Tim Rentsch? It certainly sounded
as if you were trying to, but as far as I can tell you haven't
actually refuted anything he said. "I like extra parentheses" and
"You should follow coding standards" seem to be unrelated statements
(the use of quotation marks is not intended to imply that these are
direct quotations).

 

[Chris H]

In message <[email protected]>, Ian Collins <ian-
(e-mail address removed)> writes
On 02/15/11 07:24 AM, Keith Thompson wrote:
[snip] [Parentheses can be]
used to emphasize existing grouping. In fact I often use them
that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

I do this very often.

In fact, I have absolutely no idea whether I'm using them to change
grouping or to emphasize grouping. I just use them to show
what grouping
I intend, and I don't waste my limited cognitive bandwidth trying
to guess
whether or not I'd have gotten that grouping anyway.

That seems reasonable, as long as you don't think it necessarily
applies to people who are not mentally differently-abled in the
way that you are.

I believe it does.

So do I.

I will go further.....

This is the way we will do it because it works for the majority. It
makes things more readable and therefore safer. If it does not work
that way for you not a problem. You will just not be on the
team/project/company. Please go away.

BTW this will include any source code supplied under contract. It *WILL*
be to this coding standard.
[...]

What coding standard are you referring to?

The house coding standard. (What ever that is)

What rules would you impose?

(To the tune of "If I ruled the world" or " Crown imperial" )

The following rules will be obeyed...

Probably something based on MISRA -c or C++

And what if the house coding standard forbids extraneous parentheses?

Are you actually disagreeing with Tim Rentsch? It certainly sounded
as if you were trying to, but as far as I can tell you haven't
actually refuted anything he said. "I like extra parentheses" and
"You should follow coding standards" seem to be unrelated statements
(the use of quotation marks is not intended to imply that these are
direct quotations).

Well I prefer the use of parenthesis in the A=B==C case we were
arguing. But my point was that you need clear maintainable code and
claiming you are "mentally differently-abled" for doing it differently
ain't a valid reason.

 

[Keith Thompson]

In message <[email protected]>, Keith Thompson <kst-
(e-mail address removed)> writes [...]

Are you actually disagreeing with Tim Rentsch? It certainly sounded
as if you were trying to, but as far as I can tell you haven't
actually refuted anything he said. "I like extra parentheses" and
"You should follow coding standards" seem to be unrelated statements
(the use of quotation marks is not intended to imply that these are
direct quotations).

Well I prefer the use of parenthesis in the A=B==C case we were
arguing. But my point was that you need clear maintainable code and
claiming you are "mentally differently-abled" for doing it differently
ain't a valid reason.

Oh, so *that* was your point. I honestly couldn't figure that out from
what you wrote. The main point I got was that one should follow coding
standards, something I don't recall Tim Rentsch ever disputing.

(For the record, I thought Tim's use of the phrase "mentally
differently-abled" was inappropriate, but not enough for me to jump
in and mention it; Seebs can say something about it if he likes
(and it did refer to things Seebs has said about himself). And I
also prefer parentheses in "a = (b == c);", but not as strongly
as you do; the version without parentheses, "a = b == c;", doesn't
bother me a whole lot.)

 

[Tim Rentsch]

[snip] [Parentheses can be]
used to emphasize existing grouping. In fact I often use them that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

I do this very often.

In fact, I have absolutely no idea whether I'm using them to change
grouping or to emphasize grouping. I just use them to show what grouping
I intend, and I don't waste my limited cognitive bandwidth trying to guess
whether or not I'd have gotten that grouping anyway.

That seems reasonable, as long as you don't think it necessarily
applies to people who are not mentally differently-abled in the
way that you are.

I believe it does.

Let me see if I have this right.

You don't.

You believe this practice
_necessarily_ applies to all people, regardless of the
strengths and balance of their different brain functions;
that it's the best choice of tradeoffs among all the
choices that anyone could make, regardless of the individual;
that if someone else has a different opinion about the
right practice for themselves, that their opinion is wrong
and yours is right. Because if you say it "necessarily
applies" then that's what it sounds like you're saying.

No, I merely meant that it does apply to at least some such people.

I believe you have misread my earlier comment. What I said was

"... as long as you don't think it necessarily applies
to people [restrictive clause]... "

There really is only one way to parse this quote sensibly, namely,

as long as you don't think (it necessarily applies ...)

When you write in response "I believe it does", the natural
expansion would be "I believe it does necessarily apply".

You'll note that I didn't say that your statement was false.
You said it doesn't *necessarily* apply; [snip]

I did not say that something _does_ necessarily apply, nor did I
say that something _does not_ necessarily apply. What I _did_
say was that the original comment was reasonable, **as long as the
commenter didn't think** that it necessarily applies (to a class
of other people). [the **'ed emphasis added]

The net result is, I think you responded to something you imagined I
had said, but not what I actually did say. Reading the response in
the context of what I actually did say leads to a different sense of
your statement (ie, different from what you intended). You see what
I mean?

 

[Tim Rentsch]

In message <[email protected]>, Keith Thompson <kst-
(e-mail address removed)> writes
In message <[email protected]>, Ian Collins <ian-
(e-mail address removed)> writes
On 02/15/11 07:24 AM, Keith Thompson wrote:
[snip] [Parentheses can be]
used to emphasize existing grouping. In fact I often use them
that way
myself. (I'm no longer trying to convince you that it's a good idea,
just that it's commonly done.)

I do this very often.

In fact, I have absolutely no idea whether I'm using them to change
grouping or to emphasize grouping. I just use them to show
what grouping
I intend, and I don't waste my limited cognitive bandwidth trying
to guess
whether or not I'd have gotten that grouping anyway.

That seems reasonable, as long as you don't think it necessarily
applies to people who are not mentally differently-abled in the
way that you are.

I believe it does.

So do I.

I will go further.....

This is the way we will do it because it works for the majority. It
makes things more readable and therefore safer. If it does not work
that way for you not a problem. You will just not be on the
team/project/company. Please go away.

BTW this will include any source code supplied under contract. It *WILL*
be to this coding standard.
[...]

What coding standard are you referring to?

The house coding standard. (What ever that is)

What rules would you impose?

(To the tune of "If I ruled the world" or " Crown imperial" )

The following rules will be obeyed...

Probably something based on MISRA -c or C++

And what if the house coding standard forbids extraneous parentheses?

Are you actually disagreeing with Tim Rentsch? It certainly sounded
as if you were trying to, but as far as I can tell you haven't
actually refuted anything he said. "I like extra parentheses" and
"You should follow coding standards" seem to be unrelated statements
(the use of quotation marks is not intended to imply that these are
direct quotations).

Well I prefer the use of parenthesis in the A=B==C case we were
arguing. But my point was that you need clear maintainable code and
claiming you are "mentally differently-abled" for doing it differently
ain't a valid reason.

I believe you have misundertood my comment. A style rule that
makes sense for someone who is mentally differently-abled (in some
particular way) may not make sense for the general population. We
might want to take the abilities of such people into account when
deciding on shared style rules, but we shouldn't assume that just
because a particular rule works for them it also works for other
people generally. Neither should we assume that it does _not_
work for other people generally.

 

[Tim Rentsch]

[snip]

What rules would you impose?

(To the tune of "If I ruled the world" or " Crown imperial" )

The following rules will be obeyed...

Probably something based on MISRA -c or C++

And what if the house coding standard forbids extraneous parentheses?

Are you actually disagreeing with Tim Rentsch? [snip elaboration]

If so that would be surprising, because I haven't really said
much more than "I find it easier to read X than Y", and given
some reasons about why I think that's so.

In fact I believe my reactions are shared by some other people,
but I haven't made any sort of extensive claims in that regard.
So I guess a disagreement would mean he thinks my reactions
aren't shared by anyone else.

 

[Tim Rentsch]

[snip]
Well I prefer the use of parenthesis in the A=B==C case we were
arguing. But my point was that you need clear maintainable code and
claiming you are "mentally differently-abled" for doing it differently
ain't a valid reason.

Oh, so *that* was your point. I honestly couldn't figure that out from
what you wrote. The main point I got was that one should follow coding
standards, something I don't recall Tim Rentsch ever disputing.

(For the record, I thought Tim's use of the phrase "mentally
differently-abled" was inappropriate, but not enough for me to jump
in and mention it; Seebs can say something about it if he likes
(and it did refer to things Seebs has said about himself). [snip]

I wouldn't have mentioned it except that Peter ('Seebs') has brought
it up in public conversation, including some ways that it affects
his personal development process. I certainly didn't mean for
the term to carry any sort of stigma; a 'differently-abled' person
might have enhanced abilities relative to the general population,
as for example a person with eidetic memory. The point is not to
generalize from /people known to be unusual/ to the general population.

Personal example: I have no use for colorizing editors, IME they
are worse than useless. However, I don't assume this reaction holds
for people generally, because the color balance of my photoreceptors
is known to be atypical, ie, I am 'visually differently-abled'; it
seems only sensible not to generalize my reactions in this arena as
applying to other people. The same kind of reasoning applies when
there are differences in cognitive abilities.