what is difference between sizeof and strlen

[Gordon Burditt]

Re: Style isn't always religious

>> On checking out, you indent the code to your[color=blue][color=green]
>> liking. Before checking in, you indent it to the house style. Problem
>> solved.[/color]
>
>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.[/color]

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]

Re: Style isn't always religious


"Tim Rentsch" <txr@alumnus.ca ltech.edu> wrote in message
news:kfnvf1omun u.fsf@alumnus.c altech.edu...[color=blue]
> mwojcik@newsguy .com (Michael Wojcik) writes:[/color]
<even bigger snips than tim made>[color=blue]
> 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?[/color]

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]

Re: Style isn't always religious

"Mark B" <sober@localbar .com> wrote in message
news:BBKQe.1854 $X25.168959@mon ger.newsread.co m...[color=blue]
>
> "Tim Rentsch" <txr@alumnus.ca ltech.edu> wrote in message
> news:kfnvf1omun u.fsf@alumnus.c altech.edu...[color=green]
> > mwojcik@newsguy .com (Michael Wojcik) writes:[/color]
> <even bigger snips than tim made>[color=green]
> > 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?[/color]
>
> Not sure about vi-tools, but in the past I had used 'Brief'[/color]
exclusively[color=blue]
> 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[/color]
though[color=blue]
> I did do some tweaking to the default settings, I never messed with[/color]
the[color=blue]
> routines macro as I personally liked the style they supported by[/color]
default[color=blue]
> which happened to also be compatible with FreeBSD's (man) 'style'[/color]
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.

--
Mabden

[Richard Bos]

Re: Style isn't always religious

Tim Rentsch <txr@alumnus.ca ltech.edu> wrote:
[color=blue]
> 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" .[/color]

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

Richard

[Richard Bos]

Re: Style isn't always religious

"Mabden" <mabden@sbc_glo bal.net> wrote:
[color=blue]
> 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.[/color]

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]

Re: Style isn't always religious

rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:
[color=blue]
> Tim Rentsch <txr@alumnus.ca ltech.edu> wrote:
>[color=green]
> > 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" .[/color]
>
> It does? May I remark that I find your usage of the word "religious"
> less than optimally readable?[/color]

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

[Mabden]

Re: Style isn't always religious

"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
news:43147ffc.1 0002367@news.xs 4all.nl...[color=blue]
> "Mabden" <mabden@sbc_glo bal.net> wrote:
>[color=green]
> > 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),[/color][/color]
IMO.[color=blue]
>
> You are, of course, free to prefer one style over another as you[/color]
please;[color=blue]
> 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[/color]
++var.[color=blue]
> It seems that you do not understand how these operators work.[/color]


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.

--
Mabden

[Michael Wojcik]

Re: Style isn't always religious


In article <devkji$9od$3@n wrdmz01.dmz.ncs .ea.ibs-infra.bt.com>, Richard Heathfield <invalid@invali d.invalid> writes:[color=blue]
> Michael Wojcik said:[color=green]
> > In article <otiQe.145089$d P1.501277@newsc .telia.net>, akarl
> > <fusionfive@com hem.se> writes:[color=darkred]
> >>
> >> With tools like GNU Indent the whitespace issues of coding style is not
> >> very important as the code can be transformed to anyones liking.[/color]
> >
> > 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.[/color]
>
> 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.[/color]

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 "significan t" 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 michael.wojcik@ microfocus.com

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

[Michael Wojcik]

Re: Style isn't always religious


In article <kfnvf1omunu.fs f@alumnus.calte ch.edu>, Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=blue]
> mwojcik@newsguy .com (Michael Wojcik) writes:[color=green]
> > In article <kfnslwwlxbj.fs f_-_@alumnus.calte ch.edu>, Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=darkred]
> > >
> > > As an example consider the question of where to put closing braces....[/color]
> >
> > 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.[/color]
>
> 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).[/color]

A fair analysis.
[color=blue][color=green]
> > Because my function-body braces are indented at the same level as
> > their "controllin g" line of code, I also like to indent opening and
> > closing braces for control structures at the same level as their
> > controlling line.[/color]
>
> 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).[/color]

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.
[color=blue]
> 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?[/color]

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.)
[color=blue]
> 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.[/color]

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...)
[color=blue]
> 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.[/color]

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 michael.wojcik@ microfocus.com

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