Re: c.l.c wiki update

On Mon, 23 Jan 2006 16:16:11 +0000, Michael Wojcik wrote:
> In article <pan.2006.01.21.06.00.50.382144@xxxxxxxxxxx>, Netocrat
> <netocrat@xxxxxxxxxxx> writes:
>>
>> Disclosure: K&R is the style I first (implicitly - not necessarily
>> completely or accurately) learnt and it's still my preferred style. The
>> suggestion came from two other people though.
>>
>> The reason I think it's likely to be most acceptable is that it was
>> developed by the founders of the language. Someone with a mind to
>> architect a programming language as successful as C is likely to make a
>> good job of an accompanying style.
>
> I'm not going to advocate for or against a particular style here, but
> this argument seems very weak to me. I don't see any evidence to
> support the thesis that a language designer is necessarily interested in
> style in general.

I was considering C more specifically than that. I've encountered many
comments on the white book, none of them negative much beyond "it's
probably not so appropriate for total beginners" or "it's very condensed
and requires much consideration". In particular, I've never encountered a
contradiction of the claim that - and have fairly often encountered the
claim itself - the book is elegant in its concise expression of C idiom.
"Elegant" and "idiom" are close relatives of "style", so a thesis that the
designer of C at least had a powerful sense for style, whether expressly
interested in it or not, seems reasonable to me.

Also the reasons behind C's success are as relevant as its success - in
particular the appropriateness of the choices made when developing the
language's model, which I'll take up below.

> Further, I don't see any basis for arguing that a language designer's
> style preference has any objective weight. What makes a language's
> developer any more of an authority on what constitutes a good style? The
> only warrant for that claim seems to be one of authority by association:
> the designer is an authority on the language, and hence one on its
> proper use. There's no logical justification.

Developing a style involves some of the same type of choices as developing
the language does, and someone with a particular talent for the latter -
as I'm arguing C's founders had - is likely to be skilled at the former,
and is also likely to have exercised that skill in the process of writing
a comprehensive tutorial on the language (the type of choices aren't
identical, but they're similar enough to presume a relationship).

>> Given that style is so subjective, the property "given birth to
>> alongside the language and endorsed by its parents" is a pretty
>> objective basis for preference (unless there's another style I don't
>> know of with that property).
>
> I don't think it's objective at all. The fact of its origin is, but
> attachment to preference is not.

I'm not claiming it's wholly objective, only that it's the most objective
basis I can find for choosing a shared style for a public repository - for
C in particular given the general respect for the discriminatory abilities
of its designers. If someone were to present a set of well-conducted
studies and metrics to show that another style was in general better, for
some reasonable definition of "better", then I'd reconsider.

>> Would you suggest leaving the style guidelines at "consistent"?
>
> I would, perhaps with suggestions such as moderate line length, avoiding
> //-style comments, and avoiding tabs (or at least the mixing of tabs and
> spaces for indentation). I'd be happier, personally, to see no
> guidelines than to see too many. As with prose style, I believe style
> guidelines are often counterproductive, leading to a tiresome and
> sometimes awkward consistency for no sake but its own.

I appreciate that feedback. Steve Summit's comments - that there's more
to style than "where the curly braces go" - in his follow-up post suggest
a few other general style review guidelines such as "variable names should
be descriptive", "expressions should not be unnecessarily complex",
"control structures should be used with clarity as a goal and should not
obscure flow", etc.

The advantages of that choice are that it would avoid the need to
restructure most new and existing code, and it would be a style that far
more of us can agree on without compromising our personal styles.

The disadvantage is that C code across the Wiki would be - and already is
- quite inconsistent.

> But in the end, it's the editors of the Wiki who are doing the work, and
> the decision should be yours.

Any c.l.c reader is a potential editor, so some newsgroup discussion prior
to making a decision helps us make sure it's an appropriate one.

--
http://members.dodo.com.au/~netocrat
.

Relevant Pages

  • Re: relative complement?
    ... If the designer fails to capture information in database design, if information is hidden from the user, or if the user incompetently fails to express their intent [Ed. ... Or if the data language is not sufficiently expressive], it will certainly produce seemingly anomalous or "surprising" results when faced with these problems. ... My reason is the assumption that at any all times, all the relations recorded by an rdbms must have predicates and implications of those predicates that aren't contradictory. ... Personally, if I were designing a language, I think I would have to state that B's predicate is indeterminate. ...
    (comp.databases.theory)
  • Re: Embedding assembler in a language
    ... be used to improve the performance of the main language instead. ... This is also the reason why I see ... for handcoded assembler, although there are a few rare exceptions. ... I decided to provide a solution in the Seed7 runtime library. ...
    (comp.lang.misc)
  • Re: Controlling Javascript from server side
    ... but five different language implementations here. ... 'true' means that the request must be handled asynchronously. ... There is exactly *no* reason for such a thing here. ... | percent-endoded string). ...
    (comp.lang.javascript)
  • Re: subroutine stack and C machine model
    ... Don't you know that all C programs that are run from the command line ... good reason, I disagree. ... Using an older form of language it was to allow free men to act freely ... his continued publication suggests that his reputation hasn't ...
    (comp.lang.c)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... overall familiarity with the tested platform, language or topic. ... The decrement happens BEFORE the assignment (simple ... Question 16 is trivial if you discount the possibility that the break ... Nor is there any reason why you couldn't use structs to implement a ...
    (comp.programming)