what is difference between sizeof and strlen

[Tim Rentsch]

Now, if you want /religious/ arguments, indentation, tab-size, global
variables, ncspellingOfVariableNames, i++ vs ++i vs i += 1, for(; vs
while(1), &co, all seem to be waiting, fuel-soaked and steaming gently,
in the wings.

Discussions about formatting and layout (not to mention the
others) often take on a "religious" tone, but they don't
have to. As an example consider the question of where to
put closing braces. Here are two common alternatives:


if/for/while ...
... body line goes here ...
... another body line goes here ...
...
} /* choice A */


if/for/while ...
... body line goes here ...
... another body line goes here ...
...
} /* choice B */


(To simplify the question we consider only these two
choices, and ignore the question of where to put the opening
brace; please imagine opening braces to be placed where
ever you believe they are most appropriate.)

Which choice do you prefer and why?

If your answer is along the lines of "choice A looks more
natural to me, so I write using choice A" -- that's a
statement that has a good chance of leading to a "religious"
argument.

If your answer is along the lines of "choice B is what I'm
used to, and choice A looks funny, so of course I write
using choice B (muttering 'any sensible person would') --
that's a statement that has a good chance of leading to a
"religious" argument.

If your answer is along the lines of "there have been
studies done on this question, and all the studies I'm aware
of have concluded that choice B has lower error rates;
lower errors rates are clearly beneficial, and I write using
choice B for that reason" -- that's a statement that is less
likely to lead to a "religious" argument.

If your answer is along the lines of "our in-house coding
standards mandate use of choice A; I don't have any
preference for either choice, except that I prefer to keep
my job, so I write using choice A" -- that's a statement
that is less likely to lead to a "religious" argument (even
if it might be less than completely satisfactory for other
reasons).

We've all heard and read so many times (including even the
original K&R) statements to the effect that questions of
style are just personal preference, and can't be resolved
one way or the other, that we accept these statements as
fact. Worse, whenever there is an unresolvable difference
in minor programming choices, it often gets chalked up as a
"style preference". I don't mean to suggest that there is
always a single "right" answer; to the contrary, different
people have different weighting functions for the costs and
benefits of various style guidelines (or other development
practices) and a choice that's a net win for me might very
well turn out to be a net loss for one of my co-workers.

However, we can try to be objective about what the costs and
benefits are for different choices; if the C&B are person
dependent, so be it, but those statements also can be made
objective. The main thing is attitude. If someone insists
on saying nothing more than "choice X seems right to me"
then that someone is encouraging "religious" discussion.
Conversely, trying to find a rational basis for choices
made, and to be objective about both the costs and the
benefits of each of the different choices possible, is more
likely to lead to shared understanding of what choices to
make, and why.

The C development community is both very diverse and (I
believe) very emphatic in their opinions, both individual
and collective; hence the comments here are especially
important for developers working in C.

 

[Baxter]

"Style" should aid readability. Translate those marks into words and
punctuation and see how it reads.

For instance:
var++;
or
++var;

Translated into English:
"var increment."
vs.
"increment var."

 

[Richard Tobin]

"Style" should aid readability. Translate those marks into words and
punctuation and see how it reads.

For instance:
var++;
or
++var;

Translated into English:
"var increment."
vs.
"increment var."

But you haven't translated it, you have just transliterated it according
to your idiosyncratic correspondence between C tokens and English
words. I don't use such a transliteration, so I don't find the difference
in readability you suggest.

-- Richard

 

[Michael Wojcik]

[Heavily snipped for the sake of concision; hopefully I've retained
the flavor of Tim's post.]

As an example consider the question of where to put closing braces....

Which choice do you prefer and why?

... "choice A looks more natural to me, so I write using choice A"
[is likely to lead to a religious argument]

"choice B is what I'm used to, and choice A looks funny, so of
course I write using choice B" [religious]

"there have been studies done on this question, and all the studies
I'm aware of have concluded that choice B has lower error rates"
[less religious]

"our in-house coding standards mandate use of choice A"
[less religious]

True, and there are other possible answers with varying degrees of
subjectivity. For example, I use vi-derived editors; those editors
have useful commands for finding braces in the first column, so I
always write functions with their opening and closing braces in the
first column. That particular choice is not especially subjective,
though my choice of tool is.

Because my function-body braces are indented at the same level as
their "controlling" line of code, I also like to indent opening and
closing braces for control structures at the same level as their
controlling line. That *is* subjective, but I have a slightly
stronger justification for it (consistency) than a simple "it looks
better to me".

Obviously, though, deciding "how subjective" any of these arguments
are (or even what metric to use for gauging subjectivity) is itself a
subjective matter. So while I think many of us can agree that there
are some reasons for style choices which are less idiosyncratic and
more rational than others, arriving at a consensus on how to rank
specific reasons could be difficult.

I don't think that means the question should just be abandoned - I
still find it interesting - but it is a difficulty.

 

[Richard Heathfield]

Baxter said:

"Style" should aid readability. Translate those marks into words and
punctuation and see how it reads.

For instance:
var++;

This reads "var plus plus" to me.

or
++var;

And that reads "plus plus var".

Really, that's how I say them in my head thing. I have no particular
preference of one over the other in places where either may be used. In
C++, I would tend (paradoxically!) to use ++var, and I suspect this is
rubbing off in my C code too, even though I don't use C++ terribly often
and thus have little reason to develop this "habit".

 

[Tim Rentsch]

But you haven't translated it, you have just transliterated it according
to your idiosyncratic correspondence between C tokens and English
words. I don't use such a transliteration, so I don't find the difference
in readability you suggest.

The important thing is that he explained his metric. This
particular metric may be somewhat person-dependent, and you
might think it's not an especially good metric for measuring
readability, but at least we know what it is.

The problem with the response is it doesn't counter-propose
a different metric. If all you say is "I don't find it
readable", that moves the discussion in the direction of
being more "religious". Conversely, to move the discussion
in the direction of being less "religious", suggest a
different metric. Sometimes this requires a bit of
introspection to discover what qualities are important. But
however you come up with one, if you want the discussion to
stay in the rational half plane rather than the "religious"
half plane, it's important to offer another metric for
consideration.

By the way, I don't think using "increment" for '++' is
especially idiosyncratic. I expect many C developers might
say something along these lines, and essentially all would
understand it if they heard it or read it. But that's
incidental to the main point about proposing another metric
in response.

 

[Baxter]

By the way, I don't think using "increment" for '++' is
especially idiosyncratic. I expect many C developers might
say something along these lines, and essentially all would
understand it if they heard it or read it. But that's
incidental to the main point about proposing another metric
in response.

"++" is known as the "increment operator". It can be either prefix or
postfix.

 

[akarl]

Discussions about formatting and layout (not to mention the
others) often take on a "religious" tone, but they don't
have to. As an example consider the question of where to
put closing braces. Here are two common alternatives:


if/for/while ...
... body line goes here ...
... another body line goes here ...
...
} /* choice A */


if/for/while ...
... body line goes here ...
... another body line goes here ...
...
} /* choice B */

With tools like GNU Indent the whitespace issues of coding style is not
very important as the code can be transformed to anyones liking.

August

 

[Richard Bos]

Baxter said:


This reads "var plus plus" to me.


And that reads "plus plus var".

Really, that's how I say them in my head thing.

YAMeAICM5Euros.

Richard

 

[Mabden]

"++" is known as the "increment operator". It can be either prefix or
postfix.

I don't like postfix on a single variable. I always see it as:
var++ : Do nothing with var, then increment var before the next
instruction.

Instead of just doing what you are there to do:
++var : Increment var.

No need to wait until after "var;" is executed (a null operation), IMO.

 

[Michael Wojcik]

With tools like GNU Indent the whitespace issues of coding style is not
very important as the code can be transformed to anyones liking.

This plays havoc with typical source-code change control mechanisms,
as it produces a vast number of non-substantive changes, which in
turn makes it difficult to identify the substantive ones. While
the change control software will happily deal with a revision where
90% of the lines have changed, human maintainers will not.

--
Michael Wojcik (e-mail address removed)

Q: What is the derivation and meaning of the name Erwin?
A: It is English from the Anglo-Saxon and means Tariff Act of 1909.
-- Columbus (Ohio) Citizen

 

[Richard Heathfield]

Michael Wojcik said:

This plays havoc with typical source-code change control mechanisms,
as it produces a vast number of non-substantive changes, which in
turn makes it difficult to identify the substantive ones.

Well, that's easily fixed. On checking out, you indent the code to your
liking. Before checking in, you indent it to the house style. Problem
solved.

 

[Tim Rentsch]

[Heavily snipped for the sake of concision; hopefully I've retained
the flavor of Tim's post.]

As an example consider the question of where to put closing braces....

Which choice do you prefer and why?

... "choice A looks more natural to me, so I write using choice A"
[is likely to lead to a religious argument]

"choice B is what I'm used to, and choice A looks funny, so of
course I write using choice B" [religious]

"there have been studies done on this question, and all the studies
I'm aware of have concluded that choice B has lower error rates"
[less religious]

"our in-house coding standards mandate use of choice A"
[less religious]

True, and there are other possible answers with varying degrees of
subjectivity. For example, I use vi-derived editors; those editors
have useful commands for finding braces in the first column, so I
always write functions with their opening and closing braces in the
first column. That particular choice is not especially subjective,
though my choice of tool is.

I would put this under the heading of "increased productivity."
Putting function open braces at the left edge is a better match
to your tools, and so allows you to write code faster (or write
code at the same rate, but with less effort, which is almost the
same thing).

Because my function-body braces are indented at the same level as
their "controlling" line of code, I also like to indent opening and
closing braces for control structures at the same level as their
controlling line. That *is* subjective, but I have a slightly
stronger justification for it (consistency) than a simple "it looks
better to me".

Other things being equal, more consistent expression is normally
better, again because more consistency usually translates into
increased productivity.

Of course there is the qualifying phrase, "other things being
equal". For myself I find that putting opening braces on lines
by themselves lowers my productivity, both because my eyes have
to work a little bit harder skipping the extra vertical space
and because my hands and fingers have to work a little bit
harder doing "page turning" (scrolling commands). It's also
possible (less common, but possible) to put a line of code on
the same line as an open brace, which doesn't use any extra
vertical space. I find this form also lowers my productivity
somewhat, although for different reasons; the most obvious is
what work needs to be done in an editor when cutting/pasting,
etc. I haven't done objective measurements; I'm confident
though that objective measurements would bear out my informal
observations.

In this particular area, consistency has moved me in the other
direction: open braces for functions go just after the close
parenthesis following the function parameters. This placement
seems more consistent with K&R-style placement; given how other
braces are placed in K&R, I suspect they would have put braces
at the end of the line with function parameters if the
ANSI-style function prototypes had been used in the original
language. I don't usually use vi-based tools, so that isn't a
factor for me. It seems to me that some vi-based tools offer
some degree of extensibility/programmability; can commands be
added that know how to deal with function braces placed at the
end of the line for function parameters?

Obviously, though, deciding "how subjective" any of these arguments
are (or even what metric to use for gauging subjectivity) is itself a
subjective matter. So while I think many of us can agree that there
are some reasons for style choices which are less idiosyncratic and
more rational than others, arriving at a consensus on how to rank
specific reasons could be difficult.

There are two factors: what is the metric, and is the metric
"any good"? Sometimes there are multiple metrics, in which
case some sort of weighting function of the different metrics
is taken; this situation can be thought of as just one larger,
more elaborate, metric.

The first question, "what is the metric?", is most often
answered in one of three ways: increased productivity, lower
defect rate, or better expression of programmer intent. (The
expression of programmer intent usually is expected to yield
improvements in the other areas, either directly, or indirectly
through improved team morale, lower turnover, or other similar
factors.) Each of these can be measured, and measured fairly
objectively. Note that the "expression of programmer intent"
needs to be measured relative to the set of people who will be
reading the code in question, perhaps by having questionnaire
surveys done; but still it can be measured.

The second question, "is the metric any good?", isn't an
objective question, and doesn't have to be. Whether a metric is
good or not depends on the goals of the group or company writing
the software, and those goals can change from company to
company, or even in the same company over time or from project
to project. Naturally we would like there to be agreement that
a particular metric is the right choice; even without that,
however, there is great value in having shared understanding of
what metric is to be followed, or what metrics are being
proposed. The key first step is to make the metrics explicit
rather than left as unstated assumptions.

I don't think that means the question should just be abandoned - I
still find it interesting - but it is a difficulty.

Certainly it's difficult to reach unanimous agreement or even
just consensus. What I think is the important point is that
making the metrics objective and explicit allows the discussion
to proceed, rather than get stalled as often happens otherwise.

 

[Ben Pfaff]

On checking out, you indent the code to your
liking. Before checking in, you indent it to the house style. Problem
solved.

Does anyone do this in practice? I have not, but I suspect that
it would lead to a large number of whitespace-only changes,
because adherence to style is not normally done religiously.

 

[Gordon Burditt]

On checking out, you indent the code to your

Does anyone do this in practice? I have not, but I suspect that
it would lead to a large number of whitespace-only changes,
because adherence to style is not normally done religiously.

CVS can be made to do things like re-indenting code on the way IN
and/or OUT of the repository, automatically. It would seem (but I
haven't tested this) that "cvs diff" (without -b) between the
working copy and the repository would pick up a lot of whitespace-only
changes, but diffs between two checked-in versions would not.

I don't use this feature, largely because it messes up imported
distributions (submitting diffs or bug reports based on re-indented
source code won't get much attention).

Gordon L. Burditt

 

[Mark B]

(e-mail address removed) (Michael Wojcik) writes:

In this particular area, consistency has moved me in the other
direction: open braces for functions go just after the close
parenthesis following the function parameters. This placement
seems more consistent with K&R-style placement; given how other
braces are placed in K&R, I suspect they would have put braces
at the end of the line with function parameters if the
ANSI-style function prototypes had been used in the original
language. I don't usually use vi-based tools, so that isn't a
factor for me. It seems to me that some vi-based tools offer
some degree of extensibility/programmability; can commands be
added that know how to deal with function braces placed at the
end of the line for function parameters?

Not sure about vi-tools, but in the past I had used 'Brief' exclusively
to write code, and one of Brief's many features was that it
automatically indexed function definitions (ctrl-g brought up the
index and you could select and jump to the definition) In order
for the indexing to happen by default, the closing paren had to be
the last character on the line... opening brace could be preceded
by whitespace on the next line, but it could not be on the same line
as the parameters. I only mention Brief because it too was a very
popular editor (now emulated by microsoft's vc++) used by
many programmers, and yes, it was fully customizable, you could
program it do (with macros) anything you wanted... including
modifying the 'routines' macro to support your particular style.
Then again, it was much easier to adapt (or in my case, fashion)
one's style according to the default rules set forth by brief, and though
I did do some tweaking to the default settings, I never messed with the
routines macro as I personally liked the style they supported by default
which happened to also be compatible with FreeBSD's (man) 'style' specs!

Mark

 

[Mabden]

Not sure about vi-tools, but in the past I had used 'Brief' exclusively
to write code, and one of Brief's many features was that it
automatically indexed function definitions (ctrl-g brought up the
index and you could select and jump to the definition) In order
for the indexing to happen by default, the closing paren had to be
the last character on the line... opening brace could be preceded
by whitespace on the next line, but it could not be on the same line
as the parameters. I only mention Brief because it too was a very
popular editor (now emulated by microsoft's vc++) used by
many programmers, and yes, it was fully customizable, you could
program it do (with macros) anything you wanted... including
modifying the 'routines' macro to support your particular style.
Then again, it was much easier to adapt (or in my case, fashion)
one's style according to the default rules set forth by brief, and though
I did do some tweaking to the default settings, I never messed with the
routines macro as I personally liked the style they supported by default
which happened to also be compatible with FreeBSD's (man) 'style'

specs!

I still keep a copy of Brief around for DOS editing. I remember it from
when it was written by a company called Underware, before Sage bought
it. The last version I have is 3.1 which was put out by Borland of all
people.

Its coding style was so good it was easy to get all the programmer to
agree to "just do it like Brief". It ended a lot of religious wars just
by being a reasonable standard.

 

[Richard Bos]

The important thing is that he explained his metric. This
particular metric may be somewhat person-dependent, and you
might think it's not an especially good metric for measuring
readability, but at least we know what it is.

The problem with the response is it doesn't counter-propose
a different metric. If all you say is "I don't find it
readable", that moves the discussion in the direction of
being more "religious".

It does? May I remark that I find your usage of the word "religious"
less than optimally readable?

Richard

 

[Richard Bos]

I don't like postfix on a single variable. I always see it as:
var++ : Do nothing with var, then increment var before the next
instruction.

Instead of just doing what you are there to do:
++var : Increment var.

No need to wait until after "var;" is executed (a null operation), IMO.

You are, of course, free to prefer one style over another as you please;
but in this case, your reasons for doing so are entirely fictitious.
There is no wait whatsoever in var++ that is not also present in ++var.
It seems that you do not understand how these operators work.

Richard

 

[Tim Rentsch]

It does? May I remark that I find your usage of the word "religious"
less than optimally readable?

Certainly! I use the term "religious" only because
everyone else seems to understand it. But please
feel free to suggest something better.