Stylistic questions on UNIX C coding.

[Nick Keighley]

Since I don't know what tab setting you had when you handed me the code,
I think s/exactly two/a random number of/ applies here.

[George Lucas missed a bet when he chose to make Star Wars instead of
Style Wars.]

too violent to get a 15 certificate

In the context of C source files, the tab character (\t or \x09 or 0x09
or however expressed) should always advance the cursor position to the
next mod 8 column.

yes but even *this* isn't fixed. It's configurable "on most editors
designed within the last twenty years". If there were any concensus on
this I might accept tab characters in my source code.

The tab *key* on the other hand, may be chosen by the user to insert a
tab character, or a fixed number of spaces, or a variable number of
spaces which advance the cursor to a preferred mod n column.

Hard tabs in code that presume other than "every eight" are just evil.

yes. But as I noted earlier I've worked on a project was it was
compulsory to use them.

 

[Ben Pfaff]

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.

I've never seen widespread problems with that. When I do, I see
folks deal with it by telling the coder in question not to screw
stuff up.

Do any open source or free software projects work this way? I am
familiar with many, and I've never seen anything like this.

(Doesn't it take *forever* to reformat a large source tree, by
the way? It took a few minutes here just to run "wc" on the .c
files in a Linux kernel tree, and I imagine that "indent" is
slower than "wc".)

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.

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.

 

[Ben Pfaff]

Really? Why so?

Because I've looked at many, many software projects and worked on
several and I've never seen this approach actually used.

 

[Nick]

On 24 Feb 2010 12:35, Poster Matt wrote: [...]

EG:
Variables: int numFiles = 0;

This is camelCase.

Functions: int CountNumFilesInDir(char* path);

This is PascalCase.

Mixing the two in the same project will drive adherents of _both_ styles
nuts. Pick one and stick to it; that way you'll only drive half of your
readers nuts.

His convention apparently is to use camelCase for variables and
PascalCase for functions. It's not necessarily a style I'd use, but
it's not obviously horrible (and it's more or less the style I use
at work). As with most of these rules, conforming to existing code
is far more important than any benefits of one style over another.
I really dislike the brace placement of the code I work on, but
mixing my own style into it would be far worse (and wouldn't survive
a code review anyway).

(There's also this_type_of_identifier; the same logic applies, i.e.
don't mix that with either of the above. Never, never create some
God-awful hybrid with both underscores and uppercase letters...)

Again, This_Type_Of_Identifier isn't obviously horrible. (I use it
myself, though not in C.)

I confess to using lower_case_like_this for variables, and
Initial_Capitals like that for functions. It does help when you see
run_this() and know you don't have to go looking for the prototype.

 

[Nick]

gettext() is nice if you have it (it's POSIX, isn't it? Not ISO, anyway,
but common), but putting the messages in literally only works if you
don't reuse them. IME, _some_ error messages are used more than once, in
which case a #define is nice.

I create an enum for errors, and a table of messages (by using something
like this):
ERCODE(err_signal,"A Signal was trapped")
ERCODE(err_internal,"Something went wrong internal to the interpreter")
ERCODE(err_failure,"An operating system function failed")
ERCODE(err_memory,"Ran out of memory") // keep this as the last of the prog kil
lers
ERCODE(err_unimp,"This is not yet implemented")
ERCODE(err_syntax,"Syntax error")
ERCODE(err_open,"Error with file")
ERCODE(err_mismatch,"Mismatched types")
ERCODE(err_killed,"Program told to stop")
ERCODE(err_locking,"Database locking failed")
ERCODE(err_cs,"Error reported by ClearSilver templating system")

and a bit of #define magic, you can create the enum and the table
indexed by it in one go.

Oh, and I've just realised that this is non-conforming code. I probably
better start my error code macro with a P or something.

 

[Keith Thompson]

Tim Streater wrote:


A quick way of inserting exactly two spaces into the source.

The One True Tabstop Width is 8.

I have to deal with code that was modified by multiple different
people. Most of them use a tabstop width of 4, but some apparently
use 2, 8, or something else, resulting in code that's not properly
formatted regardless of my own tabstop setting.

Everything I check in has its tabs expanded to spaces. (I use
"expand -t 4" with manual cleanup where necessary.)

 

[Richard Tobin]

The One True Tabstop Width is 8.

I have to deal with code that was modified by multiple different
people. Most of them use a tabstop width of 4, but some apparently
use 2, 8, or something else, resulting in code that's not properly
formatted regardless of my own tabstop setting.

I think Richard H was referring to the effect of the tab key in an
editor, rather than the display of a tab character.

For example, I have the tab key set to indent 4 spaces; if I do
that twice I get a tab character which then displays as 8 spaces.

Everything I check in has its tabs expanded to spaces.

Now that the overhead is (and has long been) unimportant, that's
probably a good idea.

-- Richard

 

[Jonathan de Boyne Pollard]

[...] when cursoring down the code [...]

The next step in this merry little dance, danced so many times before,
is to point out the existence of folding text editors. Well done for
bringing the editor wars into the thread, though. That will make it
even larger. Now all you need is some way to bring the operating system
and browser wars in, as well. Obviously the earlier mentions of NetBSD
didn't take.

How about this

"Well we all know what coding styles were used to write ReactOS and
Google Chrome. And just look at the results!"

? (-:

 

[James Harris]

The One True Tabstop Width is 8.

I have to deal with code that was modified by multiple different
people.  Most of them use a tabstop width of 4, but some apparently
use 2, 8, or something else, resulting in code that's not properly
formatted regardless of my own tabstop setting.

Everything I check in has its tabs expanded to spaces.  (I use
"expand -t 4" with manual cleanup where necessary.)

For anything outside Unix or Linux others may find the following tabs
expander and compressor useful

http://codewiki.wikispaces.com/tabs.py

It allows arbitrary and/or repeating tab stop positions and obeys they
usual Unix pipe arrangements. Examples of use are included on the
page.

Although it doesn't require Unix be aware that it does need Python.
I've not tested it under Python 3.x but it works ok under Python 2.x.

James

 

[Eric Sosman]

Tim Streater wrote:


A quick way of inserting exactly two spaces into the source.

The only actual study I ever read of (that's "read of," as
in "I didn't read it myself and can't cite it") found that the
best tab spacing was greater than two and less than four. Even
without further experiment, it's blatantly obvious that these
lower and upper bounds bracket the Best Possible Tab Width, to
wit, pi spaces. This is easily approximated by making the tab
key operate probabilistically, advancing to a three- or four-
space position with probabilities 0.142 and 0.858, respectively.
(If you need a more accurate approximation to the fractional
part of pi, your lines are too long.)

 

[Eric Sosman]

[...] pi spaces. This is easily approximated by making the tab
key operate probabilistically, advancing to a three- or four-
space position with probabilities 0.142 and 0.858, respectively.
[...]

You've heard of "fencepost errors?" This is a "newspost error."

 

[Stephen Sprunk]

(Doesn't it take *forever* to reformat a large source tree, by
the way? It took a few minutes here just to run "wc" on the .c
files in a Linux kernel tree, and I imagine that "indent" is
slower than "wc".)

Last time I checked, the vast majority of wc's runtime was opening,
reading, and closing files, i.e. the parts that make the disk's head
skip all over the place, not actually counting lines. indent does a
little bit more with the data than wc does, but on a tolerably fast
machine I suspect that the extra work would just fill in (a few of) the
CPU cycles wc wastes while waiting for the disk...

S

 

[Stephen Sprunk]

Since I don't know what tab setting you had when you handed me the code,
I think s/exactly two/a random number of/ applies here.

That's a problem with _mixing tabs and spaces_, which is Evil(tm).

If you use a tab character (inserted by pressing the tab key) for each
level of indentation, each programmer can set the tab stops in his
editor however he wants and it will look correct for everyone.

(That introduces a new problem if you want to limit to 80 columns, but
that can be remedied by saying "80 columns with X-character tabs".)

S

 

[Phil Carmody]

Just make sure you're consistent and nobody will care.

Horrifically wrong. Just make sure you're consistent with everyone
else, and nobody will care.

Phil

 

[Anand Hariharan]

Last time I checked, the vast majority of wc's runtime was opening,
reading, and closing files, i.e. the parts that make the disk's head
skip all over the place, not actually counting lines.  indent does a
little bit more with the data than wc does, but on a tolerably fast
machine I suspect that the extra work would just fill in (a few of) the
CPU cycles wc wastes while waiting for the disk...

S

indent would have to /write/ the files to the disk, but wc does not.

 

[Ersek, Laszlo]

[...] pi spaces. This is easily approximated by making the tab
key operate probabilistically, advancing to a three- or four-
space position with probabilities 0.142 and 0.858, respectively.
[...]

You've heard of "fencepost errors?" This is a "newspost error."

(I'm going out on a limb here.)

Do you mean you reversed the order of probabilities (relative
frequencies)?

E(spc_per_tab) = E(3 + X) = 3 + E(X) = 3 + (0 * 0.858 + 1 * 0.142)

(If you need a more accurate approximation to the fractional
part of pi, your lines are too long.)

Having a large number of tabs is also possible by having many lines in a
file, or many files in a project

Cheers,
lacos

 

[Ian Collins]

And K&R

And for a damn good reason.

Yes, to save space in a book.

But good to see you continuing to insult your betters.


It is ludocrous to recommend the second form. ALL it does is waste a
line. Indentation is there for a reason. We dont need to see the opening
bracket on its own wasted line.

What's the going rate for a line these days?

 

[William Hughes]

indent would have to /write/ the files to the disk, but wc does not.

Which might not take any appreciable extra time, depending on
(among other things) seek vs read vs write time,
disk fragementation and buffering strategies.

- William Hughes

 

[Ike Naar]

It is ludocrous to recommend the second form. ALL it does is waste a
line. Indentation is there for a reason. We dont need to see the opening
bracket on its own wasted line.

Are you not also "wasting a line" for the closing brace?
Is that ludicrous too?
Why do you need to see the closing brace on its own line, but not the
opening brace? Doesn't that destroy the symmetry?

Then, it's not always black and white.
Consider the case where a condition does not fit on a single line:

if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 &&
sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 &&
needs_processing(color)) {
compute_volume(length, width, height);
compute_something_else(price, weight);
}

vs.

if (sscanf(input_buffer, "%d %d %d", &length, &width, &height) == 3 &&
sscanf(other_buffer, "%d %d %d", &color, &price, &weight) == 3 &&
needs_processing(color))
{
compute_volume(length, width, height);
compute_something_else(price, weight);
}

In the first case, it is hard to see where the condition ends
and where the body starts. In the second case it's obvious.
Don't you think that the opening brace on its own line here improves
the readability?

 

[James Harris]

Three, actually.  Okay, 8, if you're stuck using output devices from the
1960's which didn't allow user-defined tab spaces, but for how many
people is this true anymore?

Windows Notepad users are stuck with 8. Windows Wordpad users seem to
be stuck with 6. These are not earlier than the 1980s.

Come to think of it, apart from those two programs what do Windows
users use to enter and edit source code?

I don't think I ever use tabs when typing a high level language. I
always use spaces - just two per indent. Then there are no portability
problems, except for the line ends, of course, and they can be ignored
or dealt with.

IMHO embedded tabs in source code should be consigned to the wastebin
of history as just one of those non-printable characters we used to
hate. Why? Well, they generate a different result depending on where
they are placed and *look like* something else - i.e. one or more
spaces. They are, to an extent, hidden.

Older ones among us may remember dealing with invisible control
characters. For example, moving the cursor across a line one character
at a time looking for where it didn't move. That showed where the
invisible character was embedded. Not fun.

James