Stylistic questions on UNIX C coding.

[Ben Bacarisse]

More than 20 years ago, the first unix boxes came in the door where I
was working. As a longtime user of VM/CMS I thought you had to spend
time learning how to use editors. The guys were all debating about
which editor should become the standard for everyone learn and use -
vi, emacs, jove, ...

Since they were arguing and I had work to do, I got hold of Notepad
and started using that (this was on a Sun box). Some six months later
the guys were still arguing about which one would be the "right"
one. I think they considered this important as they expected to have
to give classes/tutorials on the "chosen" editor. I then suddenly
realised that, in fact, *I* was using the right editor.

Everyone comes to the same realisation sooner or later (unless they are
being deliberately masochistic).

It had taken
me 5 mins to get a quick mental image of which commands were on which
menus and get on with my work. No classes needed.

I guess they must still be arguing and that this argument has now
spread into c.l.c.

They were arguing about what editor *other* people should use and that
is widely thought to be an argument that never ends.

<snip>

 

[Rich Webb]

On 02/03/2010 22:27, Joe Wright wrote:

Fortunately I don't deal with Windows. On OS X, I use vi only where I
have to. Hmmm, vi, that has *modes* doesn't it, such as you can't use
the arrow keys while in insert mode.

Take a look at gvim (graphic + vi + improved). It still has the ability
to work over a simple terminal, with the separate command and insert
modes, but nowadays it can also work just like a "regular" text editor
with the expected behavior of the arrow keys, home/end, mouse drag to
select text, and the whole nine yards.

 

[Tim Rentsch]

Typographers, who study this thing with the fervor that programmers
bring to brace styles, would tend to agree. There are always reasonable
exceptions but a line length that's 70-80 characters (monospaced) seems
to be a sweet spot for comprehension.

Granted (well more or less), but notice that there is an
important difference. The reading mode for prose (ordinary
written text) is very different than the reading mode for
program source. Source code is not read as a single linear
text; it chunkifies into very particular units, and these
units are more easily comprehended when grouped in some
spatial patterns than others.

Not to say that I disagree with the conclusion necessarily, the
number 80 may be right for both. But it's a mistake to think
that the same reasoning must apply to both domains, because
the reading modes in those respective domains are so different.

 

[Tim Rentsch]

Anand Hariharan wrote:


Fine in C99, I think, but an issue in C90 if he's using it to define
an array size.

It's a problem in C99 too, if the array is defined at file scope or it
has internal linkage. There are other reasons why it's not a great
idea in C99. They stem from the fact that MaxNumFiles is not
permitted as part of a constant expression. [snip elaboration]

Minor clarification -- MaxNumFiles is _permitted_ as part of a constant
expression, albeit an implementation-specific constant expression;
it just isn't _required_ to be a portable constant expression.

 

[Tim Rentsch]

I have, repeatedly, over the years.

The problem with _not_ doing it is that you tend to get a lot of checkins
where the "diff" is wildly out of sync with what actually got changed,
particularly if the coder's tools do things such as switching tabs to
spaces or re-organizing braces, etc, etc, etc, which many tools do.

By using indent or an equivalent on checkin, you ensure a standard format
going in, such that only "real" changes are recorded, and by using it on
checkout, you deliver to the coder whatever flavour he's happiest with.

Or, you can skip it on checkout and just let him use whatever tools he
likes, but I've found delivering to the developer something which he is
maximally comfortable with, right out of the gate, tends to produce
maximum productivity and minimum frustration.

A problem with that approach is that it will trash any special/careful
formatting that you might use to clarify a complex section of code.
[snip]

Perhaps it will if the tool is poor, but it doesn't have to.
Certainly indent-like tools can be written that don't just
disregard all white space but filter it in or out selectively,
doing just enough to make the indentation and brace placement
right but still preserving column alignments appropriately when
the input warrants it.

The benefits of having such a tool, especially for a large group,
clearly outweigh the cost of providing it.

 

[Tim Rentsch]

My preferred approach is to do like this:

function wiggy ()
{
if (cond)
{
dostuff;
}
else {
dootherstuff;
}
}

This has been my approach ever since I was writing BCPL in the 70s -
it has the braces lining up so that the matching can be seen easily.

Does this mean you've never tried alternate approaches since then?
Did you try any other approaches earlier?

 

[Tim Rentsch]

[snip various comments on brace placement]

Obviously, the major advantage to putting the '{' on the same line as
the conditional is that it reduces paper usage when typesetting

Certainly this could count as an advantage, but it is not "the
major" advantage, or an especially important one.

and hence why you will normally see it in books.

K&R uses the same bracing style, AFAIAA, that Ken Thompson
and Dennis Ritchie use in their own programming. I expect
most people use in their books the same style that they
use themselves when programming. And there are plenty of
books that put open braces on separate lines rather than
on the same lines as if, etc.

 

[Tim Rentsch]

Doesn't it screw up any careful formatting, e.g. of comments?
And sometimes careful placement of white space can make the code
much easier to read.

Better indent-style tools will preserve such extra formatting
and/or alignments in the reformatted source. Obviously this
can't be done to work in every imaginable situation, but IME
the coverage of different scenarios can be good enough so that
the limitations are felt hardly ever if at all. Not perfect,
but practically speaking good enough (and much better than
some of the more restrictive alternatives).

 

[Ian Collins]

Anand Hariharan wrote:
<snip>

Haven't seen anyone point this out:

Rather than -

#define MAXNUMFILES 1024

- prefer -

const int MaxNumFiles = 1024;


That way your preprocessor won't do as much damage.
Fine in C99, I think, but an issue in C90 if he's using it to define
an array size.

It's a problem in C99 too, if the array is defined at file scope or it
has internal linkage. There are other reasons why it's not a great
idea in C99. They stem from the fact that MaxNumFiles is not
permitted as part of a constant expression. [snip elaboration]

Minor clarification -- MaxNumFiles is _permitted_ as part of a constant
expression, albeit an implementation-specific constant expression;
it just isn't _required_ to be a portable constant expression.

What? You could say just about any nonsense is permitted as part of an
implementation-specific expression.

That doesn't alter that fact that in C90 or C99, MaxNumFiles is not
permitted as part of a constant expression.

 

[Keith Thompson]

Anand Hariharan wrote:
<snip>
Haven't seen anyone point this out:

Rather than -

#define MAXNUMFILES 1024

- prefer -

const int MaxNumFiles = 1024;


That way your preprocessor won't do as much damage.
Fine in C99, I think, but an issue in C90 if he's using it to define
an array size.
It's a problem in C99 too, if the array is defined at file scope or it
has internal linkage. There are other reasons why it's not a great
idea in C99. They stem from the fact that MaxNumFiles is not
permitted as part of a constant expression. [snip elaboration]

Minor clarification -- MaxNumFiles is _permitted_ as part of a constant
expression, albeit an implementation-specific constant expression;
it just isn't _required_ to be a portable constant expression.

What? You could say just about any nonsense is permitted as part of
an implementation-specific expression.

That doesn't alter that fact that in C90 or C99, MaxNumFiles is not
permitted as part of a constant expression.

I think Tim is referring to C99 6.6p10:

An implementation may accept other forms of constant expressions.

(I just noticed that this doesn't use the term
"implementation-defined" implying, I think, that an implementation
can accept other forms of constant expressions but isn't required
to document them.)

My understanding is that code that uses extensions in general (as
permitted by C99 4p6) still require diagnostics if the code violates a
constraint, but code that uses "other forms of constant expressions"
does not.

I'd say Tim's statement is correct, but I'd place the emphasis very
differently: MaxNumFiles is not permitted as part of a constant
expression (unless the implementation permits it under C99 6.6p10).

Are there any real-world C implementations that take advantage of this
permission? Specifically, is there a C compiler that accepts
additional forms of constant expressions in (what it claims to be)
conforming mode?

And why is that permission there in the first place? What benefit
does it really provide beyond the existing permission to provide
extensions?

 

[Nizumzen]

because it does the same thing in one line less with ZERO reduction in
readability.

I find there is zero reduction in readability in that style, ergo
everyone must find that there is zero reduction in readability.

Anyway with that coding style you end up with this abomination:

if(x == 0) {
// blah
} else if(x == 1) {
// blah
} else {
// blah
}

Go, go Java coding standards!

 

[Keith Thompson]

I find there is zero reduction in readability in that style, ergo
everyone must find that there is zero reduction in readability.

Anyway with that coding style you end up with this abomination:

if(x == 0) {
// blah
} else if(x == 1) {
// blah
} else {
// blah
}

Here's how I would write the above:

if (x == 0) {
// blah
}
else if (x == 1) {
// blah
}
else {
// blah
}

In my preferred style, a closing brace appears on a line by itself, or
possibly followed by a comment. Some people like to put "else" on the
same line as the preceding "}"; I don't.

I don't suggest that everyone needs to code this way. Nor do I
suggest that any consistent style is an "abomination".

 

[Vladimir Jovic]

I personally place the condition operator at the front, as William does, but
nested.

if ((pointer1 != NULL)
&& (pointer1->field7 == 0x152)) {
return;
}

if ( ( pointer1 =! NULL )
&& ( pointer1->field7 = 0x152 ) ) {
return;
}

ops && ops

 

[James Harris]

Ben Bacarisse wrote:



s/widely/widely but wrongly/

Everybody should use vim, obviously. End of argument.

For cleaning, you mean.

I use vi a lot but IMHO editors with multiple input modes should be
consigned to museums.

Perhaps a better editor interface would work something like the early
versions of Wordstar. (Anyone remember Wordstar?) While cursor and
other keys can be recognised on keyboards that have them the only
*necessary* keys should be those that exist on all keyboards -
letters, digits, symbols and the shift and control keys. The user
would be always in input mode. Any non-input such as commands could be
entered by control-key combinations that either carry out actions
immediately or pop-up subcommand windows as needed.

James

 

[Curtis Dyer]

well they can if you use them to alias an l-value

int max_foo;
#define MAXFOO max_foo

MAXFOO++

not a good idea but...

Right, that's why I said, "...macros *may* not expand to
lvalues." Although, I could have stated more clearly, it depends
on the macro's definition.

why not? I just don't follow you.

I don't follow me, either. Unfortunately, I must have written
that qsort() example too long after I wrote the paragraph above
it, and missed making my own point in the process. Sorry about
that.

Here's a better example illustrating what I meant:

/* potentially misleading macro */
#define foobar(x) \
do { \
/* ... */ \
} while (0)

/* ... */

foobitize(someobject, foobar);

I realize this is very contrived, but something to this effect is
what I originally intended to demonstrate.

<snip>

 

[Curtis Dyer]

I fail to see how char* x; is any more misleading than char *x;.
Either way the gotcha of char *x, y; still exists.

Right, but visually, "char *x, y" more clearly demonstrates what
the declaration actually means. Realistically though, I doubt it
would be an issue for anyone, say, past their first week of
learning C.

Alternatively you could sidestep the issue with typedef:

typedef char* pchar;

pchar x, y;

Personally I'm not a fan of hiding levels of indirection behind
a typedef, but whatever floats your boat.

Nor am I, but Microsoft sure seems to be found of that style.

Ah, much ado about a trivial matter. Such is the way of clc. ^_^

But discussions about good style is Serious Business.

 

[Julienne Walker]

Right, but visually, "char *x, y" more clearly demonstrates what
the declaration actually means.  Realistically though, I doubt it
would be an issue for anyone, say, past their first week of
learning C.

That's my opinion as well. I've helped a *lot* of beginners over the
years, and at the moment I can't recall a single instance where there
was a problem due to the "misleading" placement of an asterisk. Common
problems tend to be independently discovered by virtually every
beginner, so I'm inclined to say that it's not really the big problem
that some paint it out to be.

But discussions about good style is Serious Business.

Not serious enough to warrant endless debate. Bracing styles, tabs vs.
spaces, indentation amount, it's all subjective. As long as a
reasonable style is used, it's not going to seriously impede one's
ability to read code using that style.

 

[Ersek, Laszlo]

I have to ask: what's the point nowadays of using a text mode only
editor, apart from hardware restrictions and years of use? I guess
that's "Masochistic answers to Stylistic questions on UNIX C coding"...

One point might be "screen real estate"

http://www.usabilityfirst.com/glossary/term_573.txl

aka "no clutter".

I use NEdit and joe. Both are very frugal. NEdit for higher-profile
editing sessions, joe for the smaller stuff (commit messages, quick
script edits when I'm anyway in the command line, or when editing
remotely and forwarding X over ssh would be inconvenient for some
reason).

pico (pine's editor) for e-mails (I use pine) with occasional forks to
joe (for pasting / editing code in e-mails). I used Icedove
(Thunderbird), but it choked on my IMAP account. webmail is
catastrophic.

LSEDIT on OpenVMS -- I'm writing this message in it. ^Z enters command
mode, "fill" reformats the paragraph, "exit" saves and exits.

Cheers,
lacos

 

[Malcolm McLean]

I have to ask: what's the point nowadays of using a text mode only
editor, apart from hardware restrictions and years of use? I guess
that's "Masochistic answers to Stylistic questions on UNIX C coding"...

A lot of big computers still don't have windowing systems. Their
cycles are too expensive to be used on updating GUIs.
Someone somewhere will one day produce a client that lets you edit a
text file, stored on a mainframe, on a PC or workstation GUI. However
I haven't yet seen such a system. Uploading files by ftp manually is
too much of a nuisance.

 

[Casper H.S. Dik]

io_x wrote:

Real programmers typically write programs that can't
all fit on a screen display.
With that in mind, they write in such a way so that
whatever can be displayed on a screen, is easiest to read.

You personally io_x,
will never write a program that can't all fit on one screen.

His style is best known for the "Obfuscated C Code Contest"

Casper