tools for manipulating (or pre-processing) data structures tosimplify source

[Ben Bacarisse]

"Real C programmers didn't need more" was my tongue-in-cheek
embellishment, which wasn't necessary, but thought obvious.

Expressing what "Real" programmers would do, or would not do, was
common. A sort of double-entendre used both to support one's own
opinion or deride other's.

Yes I know the trope, and I, too, doubt he would have said it literally.
But we are back to square one -- do you have a citation that shows that
attitude?

I agree that it is doubtful Kernighan would ever have used the
expression formally. However, in his heart of hearts, I firmly believe
he KNEW what REAL programmers would do. <g>

That sounds like you don't have any evidence that he would have taken
such an attitude to this issue. It's hardly a big deal, but if so, I
think you should withdraw it.

 

[BartC]

The six character limits came from BCD on the 36 bit machines,
and later SIXBIT on the DEC 36 bit machines.

And possibly from Radix-50 on 16 and 32-bit ones.

 

[Ben Bacarisse]

LOL. Get over it.

With time, and counselling, I may one day... oh, I'm over it. You did
see "It's hardly a big deal" yes?

Chalk it up to "something I don't believe happened". Ok by me.

I was there. Were you?

Not sure where "there" is, but most likely not. If you are just
reporting what you saw/heard/read, I'll take your word for it ("personal
communication" is a reasonable citation). But the grins made me feel
you were taking the mickey out of someone who's not around to set the
record straight.

 

[Keith Thompson]

LOL. Get over it.

Chalk it up to "something I don't believe happened". Ok by me.

I was there. Were you?

You were there? Can you expand on that?

 

[Jorgen Grahn]

Maybe it's just a Linux thing to make things incomprehensible (and then
try and make out it's good coding practice!).

I should have responded here instead of upthread: the Linux [kernel]
sources I've seen are nothing like this, and quite readable.

Caveat: I've not looked at any of his code (either the kernel or git), but I
have watched a talk he gave once in which he discussed (among other things)
his coding style.

The take-away from that talk was that he does have an, er, shall we say,
"unique" coding style, and the implied statement was that you either love
it or hate it. I get the impression that the world kinda splits about
50/50 into the love/hate camps.[/QUOTE]

Linus can certainly make a statement and imply anyone who disagrees is
an idiot ... but when I look at the code what I see is

- K&R style
- prefix_foo_bar naming
- TAB-indented (so indentation levels are really deep)
- lots of non-portable constructs
- no C99 constructs except heavy use of inlining (he has something
against C99; I forget what)

I find that rather conservative, after all.

/Jorgen

 

[Malcolm McLean]

On Fri, 2013-10-25, Kenny McCormack wrote:


Linus can certainly make a statement and imply anyone who disagrees is
an idiot ... but when I look at the code what I see is

He's a brilliant programmer. He's also been very lucky in that he produced
something which everyone wanted, at the right time. Programmers are notoriously
socially-challenged, partly because computers are too. They insist on having
everything right, they don't understand compromise and fudging the point
to smooth over relationships.

- K&R style

Irritation, but something and nothing.

- prefix_foo_bar naming

All conventions have good points and bad points. Underscores make it easier
for automatic programs to parse identifiers, but humans tend to prefer
compound words without them.

- TAB-indented (so indentation levels are really deep)

TABs should be banned in source code. But it's something and nothing. it
does discourage you from making indention too deep.

- lots of non-portable constructs

That doesn't matter in a kernel. It's disastrous for general C programming,
of course.

- no C99 constructs except heavy use of inlining (he has something
against C99; I forget what)

C99 was essentially a failure. A lot of the new features were dubious. Then
Microsoft didn't support it, so if you wanted your routines to compile on
Windows machines, you had to use the common subset of C89 and C99 anyway.

I find that rather conservative, after all.

I'm also very conservative in coding practices.

 

[Keith Thompson]

Irritation, but something and nothing.

A matter of opinion. Personally, I prefer K&R style brace placement,
but I'm not going to get into yet another debate about it.
Consistency is what's important.

All conventions have good points and bad points. Underscores make it easier
for automatic programs to parse identifiers, but humans tend to prefer
compound words without them.

You're over-generalizing about what "humans" prefer. By all means
state your own opinion, but please don't assume it's universal.
(Case in point: I'm human, and I like underscores in identifiers.)

TABs should be banned in source code. But it's something and nothing. it
does discourage you from making indention too deep.

There are counterarguments to this as well. And most editors can easily
be configured to adjust how tabs are displayed. At my job, the coding
standard specifies tabs for indentation and 4-column tabstops. Not my
preference, but again, consistency is more important.

That doesn't matter in a kernel. It's disastrous for general C programming,
of course.
C99 was essentially a failure. A lot of the new features were dubious. Then
Microsoft didn't support it, so if you wanted your routines to compile on
Windows machines, you had to use the common subset of C89 and C99 anyway.

Microsoft's lack of support for C99 has close to exactly zero
relevance for Linux kernel programming.

[...]

 

[Keith Thompson]

/Mixing/ spaces and tabs for indentation in the same file is always
wrong - but I don't see anything wrong with tabs as long as you are
consistent.
http://www.emacswiki.org/emacs/TabsSpacesBoth

[...]
Torvalds dislikes C99 bool's, but I don't know of anything else about
C99 that he has ranted about.

Linus Torvalds writes about C99 bool here
<https://lkml.org/lkml/2013/8/31/138>:
LT> I don't use "bool" in code I write. I don't think it adds any actual
LT> value, and I think the data type is badly designed and of dubious
LT> value in C. It has very few actual advantages.
LT>
LT> That said, it's not like I *hate* the type, and I won't remove bool
LT> from code other people write. I just think it's superfluous and
LT> stupid, and another case of C++ people thinking too much "this is a
LT> cool feature" without then actually doing it well. The C people then
LT> picked it up because it was less onerous than some other C++ features,
LT> and all the compilers had the logic anyway.

He makes a good point about the subtle difference in behavior between
C99's bool (_Bool) and common pre-C99 replacements like:

typedef int bool;
#define false 0
#define true 1

(personally I prefer `typedef enum { false, true } bool;`). But IMHO
it's easy enough to write code that doesn't run into those subtleties,
particularly if you avoid comparing values for equality to `true` or
`false`.

I vaguely recall that he dislikes mixing declarations and statements,
but I don't have a reference for that.

[...]

 

[Keith Thompson]

Actually, Tabs are the technological superior solution, as long as you
can be reasonably sure that everyone has editors that deal with this
properly. It allows each person to set the indent to match THEIR
preference, and reduces (slightly) the size of files.

That's the argument in favor of using tabs for indentation, and
it's a valid one.

An argument for using spaces for indentation is that nobody has
to reconfigure their tools to view source code as it's intended to
be seen. A chunk of code will look the same whether I view it in
a text editor, cat it to my terminal, print it, or copy-and-paste
it into a web form.

There are advantages to tabs if they're used correctly and
consistently. I've never seen a software project maintained by
more than one person that uses tabs with complete consistency.

 

[BartC]

If one uses tabs for indentation and spaces for alignment, then it doesn't
matter what the tab stop is, except for perhaps line wrapping. The logic
is
unassailable, and frankly I have no idea why people are reticent to adopt
that form. From the perspective of semantics or style it's the best
rule...
period.

What do you mean by using spaces for alignment? Both tabs and spaces are
used for horizontal alignment.

The trouble with mixing tabs and spaces, is that one line might use a
4-space tab, and the next might just 4 spaces; the two lines will appear to
be aligned.

But on a different editor with an 8-space tab, they will be all over the
place.

 

[Kenny McCormack]

When people tell me they uses soft tabs because it makes presentation more
consistent, I want to punch them in their face.

You need to deal with your anger management issues. Or get back your meds.

Your whole posts seeths with anger (i.e., not just the above quoted line).

 

[Ben Bacarisse]

What do you mean by using spaces for alignment? Both tabs and spaces
are used for horizontal alignment.

He means:

int my_function(const char *str, /* the string to frobnicate */
long int how_much, /* how much frobnication */ )
{
.....if (!str) {
.........my_other_function(str);
.........return str;
.....}
.....frobnicate(str, how_much);
}

The leading .... show tabs (at four spaces in the case) and spaces are
spaces. The function header shows spaces used for alignment (both
leading and embedded), and these should not be replaced by tabs, ever.

The trouble with mixing tabs and spaces, is that one line might use a
4-space tab, and the next might just 4 spaces; the two lines will
appear to be aligned.

Not what he meant. Indentation is a special form of alignment for which
tabs are, technically, superior. (I say "technically" because they
don't stand up well to the social aspects of team work.) Other forms of
alignment should use spaces, as above.

<snip>

 

[Keith Thompson]

If one uses tabs for indentation and spaces for alignment, then it doesn't
matter what the tab stop is, except for perhaps line wrapping. The logic is
unassailable, and frankly I have no idea why people are reticent to adopt
that form. From the perspective of semantics or style it's the best rule...
period.

Try working on code that's been maintained by multiple programmers.
Your suggested convention, though it does have real advantages,
is unenforceable. I work on code written under a coding standard
that requires tabs for indentation; I see inconsistent use of tabs
and spaces all over it.

In my own code, I happen to prefer using only spaces, usually with
4-column indenntation. It works for me.

When people tell me they uses soft tabs because it makes presentation more
consistent, I want to punch them in their face.

[...]

I presume you're exaggerating your reaction, but it's hard to tell;
humor, if that's what it it's meant to be, doesn't always come across
well in plain text. Nothing we're discussing is that important.
Drop the violent rhetoric or be ignored.

 

[Kenny McCormack]

I would have thought that somebody who has racked up your number of usenet
screeds could appreciate the scorn and passion.

Good one. Full marks to you.

I like what you said about "social capital" in your other response.

Unfortunately, nobody escapes the wrath of Kiki. If he decides to talk to
you like you were 5 years old, there's nothing you or anyone else can do
about it.

 

[Malcolm McLean]

On 10/29/13, 11:37 AM, Keith Thompson wrote:

My own experience is that using spaces doesn't make things much more
consistent, as some will indent 2 spaces, some 3, and some 4, so if you
pick up code from someone else code, you likely have to change your
editor anyway to make your code fit in. The only exception is if you
have a strong formatting rule with a tool to check/enforce the rule.
(and it can check for tab consistency too)

I indent two spaces per indent, which to my mind gives the right balance
between making the indent clear and not pushing highly indented code too
fr to the right. But that preference isn't so strong that I can't read code
indented with three or four spaces, or indent four spaces if adding to code
written like that.
Tabs are a problem, however. Often, if not set correctly, the code isn't
just indented with a different setting to the one intended, it's all over
the place. Because spaces have been mixed with tabs.
Then I don't necessarily know how to set the tab stops on the editor I'm
using, and a few minutes later I might be using a different editor, because
you often don't want to set up a whole IDE just to browse come code, or
the code might shuttle between a desktop and a remote machine with console
access. Then the stops need to be set again when loading another piece of
code written with different conventions.
So I always leave editors in default mode and just cope with the inconveniences.
Tabs are nuisance, though. They're typewriter technology, they don't adapt
well to computers.

 

[Seebs]

Thus I'm somewhat surprised that no one has mentioned the project
manager's single best tool in the battle for consistency -
beautifiers. A good example is "Artistic Style". There are others.

http://astyle.sourceforge.net/

One configures the utility to enforce the style.

Developers, CASE tools, utilites, etc. can do pretty much whatever
they want, even run their own versions to set things 'back' to what
they prefer - just as long as they run the enterprise tool before
check-in.

The difficulty of using such tools on Python code is one of the reasons
I don't get along with the language.

-s

 

[Seebs]

The big problem with a "beautifier" is that it plays havoc with revision
control and looking at change history, as it can make so many "changes"
that you lose track of what is really different.

That depends! If you *always* use it, it reduces and/or eliminates
whitespace changes.

-s

 

[James Kuyper]

Ralph,
The big problem with a "beautifier" is that it plays havoc with revision
control and looking at change history, as it can make so many "changes"
that you lose track of what is really different.

That is a serious issue to be considered when deciding to "beautify"
code for the first time. However, a policy that requires, from the
beginning, that all updates be processed by the beautifier before
check-in shouldn't have the same problems.

Exception:
Consider a file that has been beautified in accordance with the
enterprise standard rules. If it is checked out, beautified according to
developer-specific rules, and converted back according to the enterprise
standard rules, without any other modifications, does it match the file
as checked out? If there are numerous mismatches, then it will cause the
kind of problem you describe - but the solution might be to prohibit
whatever feature of the developer-specific rules was responsible for
that fact.

 

[James Kuyper]

On 11/2/13, 3:08 PM, Seebs wrote: ....

Just imagine what it would do to a program written in WhiteSpace.

Beautifiers targeting WhiteSpace would have to work VERY differently
than ones targeting C. However, there shouldn't be any additional with a
beautifier correctly targeted for WhiteSpace.

 

[Ian Collins]

Thus I'm somewhat surprised that no one has mentioned the project
manager's single best tool in the battle for consistency -
beautifiers. A good example is "Artistic Style". There are others.

Any team that lets a project manager anywhere near their code is in
serious trouble!