Coding standards

[Keith Thompson]

Sorry. I often omit the attribution when the quote is
a paraphrased or consensus opinion, of limited relevance,
simply for context, or even in the interest of brevity.

If you paraphrase, you're not quoting, and you should clearly indicate
that you're paraphrasing. You should also indicate whose words you're
paraphrasing. But it seldom makes sense to do so anyway, since
quoting directly and accurately is easier.

Here's a hypothetical example:

| Fred Foo writes:
| > Here's a long-winded explanation of some concept or other.
|
| So you're saying that we should just avoid it altogether?

By providing both a direct quote and a paraphrase, you let your
readers see the actual context and judge whether your paraphrase is
accurate.

If you want to make a statement of your own without referring to what
someone else has written, just make the statement; if there's no
quotation, there's no need for attribution.

As for omitting the attribution for other reasons, please don't do
that. An attribution is just a line or two, and omitting it is just
rude, even if you don't mean to be rude.

Please note that readers who need the source can easily find
it, e.g. at Groups.Google.

Yes, I can switch from my newsreader to my web browser, go to
groups.google.com, figure out how to search for your article, and then
come back to my newsreader. Or you can include the attribution and
save each of us the effort of doing that dozens of times a day for
multiple articles.

(Also posting at both Groups.Google
and Groups-Beta.Google seems to be broken these days. I
had to cut and paste to get the remark and attribution above.
Suggestions welcome, but be aware I post from Internet cafe.)

Yes, groups.google.com has some problems. If you click on "Reply"
while viewing an article, it gives you a tiny text box and no way to
quote the article to which you're replying other than manual
cut-and-paste. But if you click on "show options" and then click on
the "Reply" that appears below the article headers, you get a larger
text box with the article properly quoted, including an attribution
line. It's not surprising that a lot of people miss that.

Also, to avoid disharmony, I often omit the attribution for a quoted
idea when I argue against the *idea*, but not against the ideator.

Again, please don't do that. If you want to disagree with something
I've written, that's fine (especially if you're right), but do me the
courtesy of acknowledging who made the statement you're arguing
against. I scan articles for my own name so I can see which
discussions I've participated in. If you omit the attribution, I
might miss a response and lose the opportunity either to explain why I
was right or acknowledge that I was wrong.

 

[Michael Wojcik]

Sorry. I often omit the attribution when the quote is
a paraphrased or consensus opinion, of limited relevance,
simply for context, or even in the interest of brevity.

You can, of course, do as you please in this regard - none of us
can force you to do otherwise (practically speaking). However,
this practice is idiosyncratic and opposed to what passes for
official consensus on good Usenet practice (eg Son-of-1036 and
its successor Internet-drafts).

Please note that readers who need the source can easily find
it, e.g. at Groups.Google.

Not necessarily. Google Groups is not always available; it may
not have received all the relevant articles when the reader
searches it; the reader may be using a system where searching
Google Groups is difficult or impossible. At the very least it
will require switching to a different application, which is
cumbersome, for many readers.

(Also posting at both Groups.Google
and Groups-Beta.Google seems to be broken these days. I
had to cut and paste to get the remark and attribution above.
Suggestions welcome, but be aware I post from Internet cafe.)

Well, yes, this is both unfortunate and outside your control.
Google's Usenet interface continues to deteriorate. For a
company so keen on boasting of the prowess of their staff, they
are remarkably thick-headed.

Also, to avoid disharmony, I often omit the attribution for a quoted
idea when I argue against the *idea*, but not against the ideator.

That strikes me as decidely poor practice in any forum. It gives
your readers no recourse for identifying the source of the idea
you disagree with, and hence for discovering whether you are
representing it accurately and how its author may have supported
it. In short, it strikes me as distinctly unfair.

Speaking of harmony, let's please do avoid frivolous
objections or "straw-man" debates.

One man's frivolous objection may be another's compelling argument.

But if you *do* name the reference in an excerpt,
it is Netiquette to give quotee the benefit of his own
words. It is unreasonable to imply that jdallen2000
extrapolates a claim about the readability of
j } else {
to promote construction like
j char *s, *commap; int cnt;
j s = Begp; if (*s == '\0') return 0;
j for (cnt = 1; commap = index(s, ','); cnt++) {
j *commap = '\0'; plain_ups(s);
j s = commap + 1; while (*s == ' ') ++s;
j } plain_ups(s); return cnt;

Sure. However, I've no idea whom you're responding to.

Hunh? What's your point?

My point is that your understanding of English is flawed; that
there is no universal foundation for establishing what consititutes
"right" and "wrong" usage of English.

Are you one of the guys that writes, "i saw the lite"?

No. I would guess that my knowledge of the conventions of English
usage, and cognate areas such as English grammar, is better than
that of most speakers; and my preference is to employ the conven-
tions usually preferred by those with similar expertise. (I hold
one degree in the field, and expect to be receiving another in
the near future.)

You seem to be from the laissez-faire school,

I fear you've misapprehended. I do not encourage novel, sloppy,
or inconsistent usage, generally speaking; but I recognize that
my preferences - popular though they may be with my peers - are
not law.

but your arguments shed more heet than lite.

I believe it showed that your analogy was flawed. If you believe
otherwise, I'd be glad to hear why.

[True Style] was in very widespread use among the most elite C
programmers. ... proud to emulate the style of so many Masters.

Someone responded, and I paraphrase:

No, this list of True Style programmers is not particularly
more or less skilled than [some other groups].

Really? Are you guys comparing yourselves to Bill Joy?

Some of us may be. I haven't completed a comprehensive study of
source he's produced, so I couldn't say. I have seen quite a bit of
C source produced by some of the regulars in this group that is
correct, portable, robust, clear, reasonably concise, and readable;
I'm not sure how your "Masters" could have improved on it.

The best C code I've examined has been Unix kernels, shells, etc.

I've seen good and bad there. In my youth I fixed quite a number
of bugs in the BSD 4.3 kernel and system utilities (BSD Mail was
particularly fraught, IIRC).

Still, no one has deigned to post a rebutter here.

I'm afraid I don't use indent. When I maintain code, I maintain its
style as well. Reformatting poses too great a challenge to source
code control systems and the like.

Which of the following is more easily read?
Do be open-minded, setting aside any convention.

Both your style (with the three "for" statements at the same level of
indentation) and the one you call "approved" seem perfectly readable
to me. I have no argument with deviating from conventions of style
for special cases. But that is because I don't believe conventions
of style have any special intellectual, social, or metaphysical force.
They are just conventions.

 

[E. Robert Tisdale]

So is dot (period, full stop).

English uses the same glyph for both period and decimal point.

If I were writing C programs using
English punctuation rules I would write:

x = a. b? fred. bill + joe: foo. bar;

That's a bad analogy. The member selection operator
resembles a decimal point in placement and function
and therefore should have no leading or trailing white space.

(it is conventional typography to put two spaces after a terminator
but that looks even sillier).

For that matter, ! is also a terminator in English,
Do you also write (! a)?

No.
But I might write (a! ) if C had defined not
to be a postfix instead of a prefix operator.
Spanish exclamations may begin with an [upside-down] exclamation point
but English exclamations never do.
And, I believe the rule in ordinary Spanish typesetting is that
*no* space appears between the [upside-down] exclamation point
and the beginning of the exclamation.

Do you put the terminator inside the quotation marks
as style guides for English say you should?
I thank the gods (particularly God Ritchie and God Kernighan)
that I don't have to maintain your code...


Which is irrelevant, I am writing C not English.

C doesn't specify whitespace around any punctuation marks.
Evidently, you've made up your own style rules
which is fine as long as you're consistent.
People who read and maintain a lot of your code
will eventually become habituated to your style.
But I think that it's easier for other people to read my code
because I follow standard ordinary English [mathematical]
typesetting rules.

The fact that they may be used to represent operators
in C programs should not matter.
I think that C programs are more readable
if they follow the same rules that are used
in ordinary [mathematical] typesetting.

They don't mean the same thing
(what do ? and : mean in mathematical typesetting anyway?).

They are punctuation.

Certainly = doesn't mean the same as it does in mathematics
(something which trips a lot of mathematics students
when learning programming).

This is a design flaw in the Fortran and C programming languages.
Pascal uses := for the assignment operator.
I would prefer <--.
But, in any case, there should be [at least] one whitespace
before and one white space after the assignment operator.

Nor does ^ have its conventional meaning of exponentiation.

I am aware of no such convention.

C is not English. C is not mathematics. Different languages --
even Real World(tm) ones, have different conventions for typography.
Live with it...

C doesn't have *any* rules
for white space around operators and other punctuation.
Live with it.

If you want to make up your own rules, go ahead.
But don't that expect other programmers will find your code
easier to read, understand and maintain.
I am only suggesting that
other programmers might find your code easier to read
if you used a style that they are likely to be familiar with
like ordinary English [mathematical] typesetting.

 

[Default User]

Well, yes, this is both unfortunate and outside your control.
Google's Usenet interface continues to deteriorate. For a
company so keen on boasting of the prowess of their staff, they
are remarkably thick-headed.

While the google interface leaves much still to desire, jdallen's
contention is false. I am, right now, posting through google. You can
see that proper attributions and quoting is available.

The problem is that it's not obvious how to do this. The Reply button
at the bottom of the post is not the one to use. Rather, the Show
Options button should be clicked, revealing a set of buttons previously
hidden. The Reply there works as expected.

Why google chose the plain Reply as the default I can't say. It was a
BAD decision. It's led to a rash of people posting in violation of
basic netiquette, not because they want to but because they can't
figure out how to do it correctly.




Brian

 

[Lawrence Kirby]

I've tried to write a precedence-based parser for C expressions. It's
all fine apart from the ternary operator, as far as I could determine
nothing makes that come out right (I tried all combinations of left and
right precedence, and none gave the right answer for a ? b ? c : d : e).

Odd. There's no ambiguity here, there's only one possible way to parse it
so precedence is not relevant. In that respect it is similar to a[b[c]]

Which was annoying since I did not want to use a top-down BNF parser for
it. I eventually 'solved' it with a hack which did special things with
the ternary operator...

The conditional operator IS right associative in the sense that
a ? b : c ? d : e is parsed as a ? b : (c ? d : e) and
not (a ? b : c) ? d : e

Lawrence

 

[Chris Croughton]

I've tried to write a precedence-based parser for C expressions. It's
all fine apart from the ternary operator, as far as I could determine
nothing makes that come out right (I tried all combinations of left and
right precedence, and none gave the right answer for a ? b ? c : d : e).

Odd. There's no ambiguity here, there's only one possible way to parse it
so precedence is not relevant. In that respect it is similar to a[b[c]]

OK, so what (numeric or relational) precedence do you give ? and : on
the left and right?

The conditional operator IS right associative in the sense that
a ? b : c ? d : e is parsed as a ? b : (c ? d : e) and
not (a ? b : c) ? d : e

But my example was a ? b ? c : d : e. The problem is that although
visually (or with a top-down parser) it is not ambiguous, with a
bottom-up parser based on numerical precedence it doesn't (as far as I
could tell) produce the right answer in all circumstances. It generates
oddities like (a ? (b ? c) : (d : e)).

Chris C

 

[Richard Bos]

That's most amusing. I can't believe a man of your calibre doesn't
know the precedence table on p53 of "The C Programming Language",
2nd edition.

I know it exists. I don't tend to remember page names. (And, as you
know, it isn't normative; only the Standard is.)

Richard

 

[Richard Bos]

So is dot (period, full stop). If I were writing C programs using
English punctuation rules I would write:

x = a. b? fred. bill + joe: foo. bar;

(it is conventional typography to put two spaces after a terminator,

Not anywhere else but in the USA, it isn't; and even then, not in
professional typesetting. Note that K&R was _not_ professionally
typeset: TeX gets this wrong.

Richard

 

[infobahn]

I know it exists. I don't tend to remember page names.
Numbers.

(And, as you
know, it isn't normative; only the Standard is.)

Yes, you're right; I did know that. I also know that the Standard,
whilst undoubtedly an excellent and indeed uniquely authoritative
definition of the language, makes a lousy tutorial. It's not even
much use as a reference, since I have bought just the one copy and
have no intention whatsoever of printing it out and carrying the
resulting half-ton of paper everywhere I go. (I am, however,
considering transferring it to a memory stick. That would be
quite handy.)

So I use K&R as my day-to-day reference. It's unlikely to betray
me except in odd corners of the language which I'm unlikely to use
anyway. And yes, p53 is well-worn. Of course, I don't need that
information when I *write* code; only when I read it.

The use to which the Standard appears to be most commonly put is
as a stick to beat people with; this is a great shame.

 

[Chris Croughton]

Not anywhere else but in the USA, it isn't;

In the UK it has been for the last 40 or so years, unless they've
changed it recently (of course, almost all typesetting is done in
proportional fonts now so it isn't obvious). It was certainly that way
for dissertations when I took my degree (University of Kent at
Canterbury, UK, 1978).

and even then, not in professional typesetting. Note that K&R was
_not_ professionally typeset: TeX gets this wrong.

In professional typesetting, the post-terminator gap was still greater
than the inter-word one (how much greater depends on the typesetters).
But it was usually proportionally spaced, and so less noticable.

Chris C

 

[infobahn]

In the UK it has been for the last 40 or so years, unless they've
changed it recently (of course, almost all typesetting is done in
proportional fonts now so it isn't obvious).

The whole point of the two spaces was an attempt to get around the
inflexibility of fixed-pitch fonts. In the days before proportional
fonts existed (which, from my perspective, would have been 1990 or
before, although of course other people here will undoubtedly have
encountered them much earlier than that), I always left two spaces
after a full stop. When I encountered proportional fonts, I realised
immediately that this rather unnatural practice was no longer
necessary (because the word processor logic would, or at least
*should*, be able to sort out the right amount of space to leave at
the end of a sentence), so I stopped using the second space whenever
I was using proportional fonts... and I seem to have stopped using
it with fixed pitch fonts too!

 

[Chris Torek]

... I've not examined much of Chris Torek's
code but he'd qualify: what style does he use?

Within limits:

- for existing code, the style in the code being maintained or
extended; or

- for new code, the mandated corporate (or, in earlier days,
academic) style, if any; or

- the style I personally prefer.

The style I most *prefer* is largely that of the 4.xBSD systems (x

= 3), with indentation at either four spaces or one DEC-VT100-style-tab

(i.e., 8 spaces). Full-tab indents are a bit large, and in code
I post here, I use four-space indents:

/*
* Block comment describing f()'s raison d'etre, parameters,
* and so on.
*/
int f(char *arg1, int arg2) {
int localvar;
/* other declarations */

/* one blank line between declarations and code */
code();
if (expr) {
code();
controlled();
by();
if_expr(); /* rhs comments are rare but do occur */
} else
otherwise();
return 42; /* RIP DNA [frivolous comments occur ] */
}

This style can (mostly) be produced via indent (either the old
net.lang.c-era version, or, with more options, GNU indent).

 

[E. Robert Tisdale]

Within limits:

- for existing code, the style in the code being maintained or
extended; or

- for new code, the mandated corporate (or, in earlier days,
academic) style, if any; or

- the style I personally prefer.

The style I most *prefer* is largely that of the 4.xBSD systems (x


(i.e., 8 spaces). Full-tab indents are a bit large, and in code
I post here, I use four-space indents:

[snip]

You really don't need to store all of those space characters.
You can use tabs and set tab stops where you want them:

> expand -t 4 f.c

/*
* Block comment describing f()'s raison d'etre, parameters,
* and so on.
*/
int f(char *arg1, int arg2) {
int localvar;
// other declarations

// one blank line between declarations and code
code();
if (expr) {
code();
controlled();
by();
if_expr(); // rhs comments are rare but do occur
} else
otherwise();
return 42; // RIP DNA [frivolous comments occur]
}

 

[Keith Thompson]

You really don't need to store all of those space characters.
You can use tabs and set tab stops where you want them:

[snip]

If you set tab stops to something other than 8 columns, the result
will be a text file that can't be viewed properly without filtering it
through "expand" or using a text editor with the proper settings (and
8-column indentation is too much for my taste).

Just use space characters; they don't take up enough room to be worth
worrying about.

 

[Mark L Pappin]

Note that K&R was _not_ professionally typeset:
TeX gets [extra space between sentences] wrong.

You seem to be implying some causal relationship between these two
statements. My copy of K&R2 says "pic|tbl|eqn|troff-ms". No TeX
there.

mlp

 

[Richard Bos]

Note that K&R was _not_ professionally typeset:
TeX gets [extra space between sentences] wrong.

You seem to be implying some causal relationship between these two
statements. My copy of K&R2 says "pic|tbl|eqn|troff-ms". No TeX
there.

No, I was simply misremembering. What I meant to say was that troff gets
this wrong. (I'll check Knuth this evening to see what TeX does).

Richard

 

[CBFalconer]

[snip]

If you set tab stops to something other than 8 columns, the result
will be a text file that can't be viewed properly without filtering
it through "expand" or using a text editor with the proper settings
(and 8-column indentation is too much for my taste).

Just use space characters; they don't take up enough room to be
worth worrying about.

Besides which you will normally find that a source file using
blanks and not tabs compresses better than the version with tabs.
The tabs don't even reduce the storage or transmission time needed!

 

[Arthur J. O'Dwyer]

Note that K&R was _not_ professionally typeset:
TeX gets [extra space between sentences] wrong.

You seem to be implying some causal relationship between these two
statements. My copy of K&R2 says "pic|tbl|eqn|troff-ms". No TeX
there.

No, I was simply misremembering. What I meant to say was that troff gets
this wrong. (I'll check Knuth this evening to see what TeX does).

Adds some extra space, but not (by default) a full space's worth.
Unless 'frenchspacing' is on, in which case it doesn't. See pp. 72--77
in the TeXbook.
In other words, IMHO Chris Croughton gets closest to the right answer
--- true, it's not typical to put /two/ spaces after a period, but it is
atypical to put only /one/ "space's worth" of whitespace.

Way OT,
-Arthur

 

[Micah Cowan]

In the UK it has been for the last 40 or so years, unless they've
changed it recently (of course, almost all typesetting is done in
proportional fonts now so it isn't obvious). It was certainly that way
for dissertations when I took my degree (University of Kent at
Canterbury, UK, 1978).




In professional typesetting, the post-terminator gap was still greater
than the inter-word one (how much greater depends on the typesetters).
But it was usually proportionally spaced, and so less noticable.

Chris C

"In the nineteenth century, which was a dark and inflationary
age in typography and type design, many compositors were
encouraged to stuff extra space between sentences. Generations
of twentieth-century typists were then taught to do the same,
by hitting the spacebar twice after every period. Your typing
as well as your typesetting will benefit from unlearning this
quaint Victorian habit."
-- Richard Bringhurst, "The Elements of Typographic Style"

It still seems to be a common enough practice, and I was taught
this way. Donald Knuth's typesetting program, TeX, does this by
default (as you [Chris] point out), including a command named
"\frenchspacing" to use only a single space.

Of course, Mr Bringhurst is Canadian, so perhaps this is his
belief merely because he favors French ideals over others. And I
do not claim to accept everything that Mr Bringhurst asserts in
the book quoted above. However, my own eye prefers the single
space, so this is how I set text. Not to mention the extra care I
must otherwise take to notify my typesetting S/W whenever I meant
a period to indicate abbreviation rather than sentence termination.

It is neither wrong nor right, typographically speaking, to use
extra space after a sentence terminator, since you will find
supporters on either side. It thus becomes a matter of style, and
not correctness.

It's interesting to note, though, that certain modern
technologies, such as HTML, make it somewhat difficult to specify
that extra space should be inserted in the matter we are
describing. Of course, HTML is not a particularly friendly
technology to good typography in general, regardless.

Disclaimer: I am an amateur typographer (though most of us are);
moreover, I have not typeset anything of note, and certainly
nothing that has been printed, so this must be taken as the
opinion of a mere hobbyist interested in the art of setting type.

 

[Lawrence Kirby]

I've tried to write a precedence-based parser for C expressions. It's
all fine apart from the ternary operator, as far as I could determine
nothing makes that come out right (I tried all combinations of left and
right precedence, and none gave the right answer for a ? b ? c : d : e).

Odd. There's no ambiguity here, there's only one possible way to parse it
so precedence is not relevant. In that respect it is similar to a[b[c]]

OK, so what (numeric or relational) precedence do you give ? and : on
the left and right?

? and : form part of the syntax of a single operator, just as [ and ] do.
They don't have separate precedence and associativity, only the operator
as a whole does. The ? : operator has the form

<expression1> ? <expression2> : <expression3>.

Precedence and associativity essentially answer the question: if an
operand could be bound to an operator on is left or one on its right which
one should we choose? The Prec/Assoc answer is to choose the one with
higher precedence or if equal choose left or right as specified by the
associativity. The important thing here is that there must be separate
operators on the left and the right for this to be relevant.

In the case of ?: there may be an operator to the left of expression1, e.g.

a + b ? c : d

Here there is the possibility of binding b either left to + forming
(a + b) ? c : d or right to ?: forming a + (b ? c : d). Since + has higher
precedence for first possibility is the one chosen. There may be an
operator to the right of expression3, e.g.

a ? b : c / d

Here / has higher precedence so the parse is as a ? b : (c / d) and not
(a ? b : c) / d. With expression2 such a possibility doesn't exist because
there aren't different operators to the left and to the right. The only
way to create a valid parse is to evaluate expression2 as a unit and use
the result for the ?: operator. So

a ? b , c : d

is parsed as a ? (b , c) : d . Even though , has lower precedence than ?:
there is no way to generate a valid parse with the ?: performed first.

But my example was a ? b ? c : d : e. The problem is that although
visually (or with a top-down parser) it is not ambiguous, with a
bottom-up parser based on numerical precedence it doesn't (as far as I
could tell) produce the right answer in all circumstances. It generates
oddities like (a ? (b ? c) : (d : e)).

Then the parser isn't treating ?: properly as a single operator. It
appears to be treating ? and : as separate binary operators which is
wrong. How does it treat a[b[c]]?

Lawrence