what is difference between sizeof and strlen

[Mabden]

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.

I just said that that is the way it "scans" to me. That's where the
words "I always see it as" differ from "the computer will take 3 less
cycles to perform this operation". I see it as "do nothing" then
increment, but that does not mean I think the computer sits there
wasting cycles. When I said "no need to wait".. I didn't really mean the
computer actually waits. I meant it as a way of thinking about prefix
and postfix. Sorry for the confusion, I should have reread that.

Besides, a compiler should drop a statement like "null;" as a do-nothing
statement anyhow.

It's kinda like how I prefer for (; which reads as "forever", better
than while (1) since "while one" doesn't really click with anything in
my mind.

That is what style is all about.

 

[Michael Wojcik]

Michael Wojcik said:

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.

I suspect that in practice this would not work well, but I happily
admit that I have not tried it.

It does suggest the interesting possiblity of using some intermediate
representation for the repository, so that only "significant" changes
are preserved. Determining what changes are significant could be
difficult, however. At times I deviate from my normal use of
whitespace when another arrangement seems clearer in a particular
case; such a scheme would lose that information.

--
Michael Wojcik (e-mail address removed)

Painful lark, labouring to rise!
The solemn mallet says:
In the grave's slot
he lies. We rot. -- Basil Bunting

 

[Michael Wojcik]

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).

A fair analysis.

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).

A plausible argument. Obviously it can be taken to extremes (the
same charges can be levelled against vertical whitespace, for
example), but I think that only shows that the cost and benefit of
vertical spacing of various elements depends on the individual
reader.

I use small fonts and large windows, and consequently I find that
vertical space is not usually a scarce resource when I work on my
own code; and so the cost of a separate line for each opening or
closing brace is relatively small for me. On the other hand, I
like ample whitespace and visual separation of control structures,
so the benefit is correspondingly greater.

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. ...
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?

Yes, at least for any reasonably modern vi-based editor. It would
be relatively easy to change the "next function" and "previous
function" operators from a search for a brace in the first column
to a search for a brace at the outermost nesting level, regardless
of where it is on the line. (That would also find such things as
file-scope structure definitions, but then so do the current
operators, if you put their opening brace in the first column.)

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.

I suspect you could boil these three factors down into one:
define productivity as a function of feature implementation rate
versus defect rate, and assume (or demonstrate) that better
expression of intent correlates with better productivity in
maintenance work (which, in most cases, seems to dominate total
programming over the long term).

I agree those can be measured to some degree of confidence. I
imagine the real struggle would be convincing all your developers
that the metric and measurements are valid, and that a demonstrated
improvement in results justifies changing their habits. (We can't
expect everyone to be reasonable...)

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 agree, particularly with the final point.

I'd also note that one aspect of Derek Jones' _The New C Standard_
(discussed recently in other threads) that I particularly like is
his ample citations of studies of programmer productivity, as
justifications for his comments about using C in particular ways.

--
Michael Wojcik (e-mail address removed)

Auden often writes like Disney. Like Disney, he knows the shape of beasts --
(& incidently he, too, might have a company of artists producing his lines) --
unlike Lawrence, he does not know what shapes or motivates these beasts.
-- Dylan Thomas