The Go language tutorial and examples look right at home alongside K&R. Likewise jQuery and other Javascript libraries, where terseness is valued due to bandwidth rather than screen size.

The idiomatic C style is so natural to me now I don't see it as a defect to fix or a game I'm playing. It's how I learned to program in C because I learned from K&R, and if they aren't the authorities I don't know who is. When I see wordy and bloated Java-style code it reminds me of the years I spent writing COBOL. Ultimately, though, it's not efficiency or a desire to show off or confuse other programmers that influences my style. To me code that does what it needs to with no extra fluff is beautiful.

When I see

  while (*s++ = *t++) ;

I know what it does -- I don't need any comments or "descriptive" variable name or an explicit test for a null byte to make it clearer. If a programmer comes across a line of code that he or she doesn't understand the fault may be with the author, but it may be with the reader. In my experience there are a lot of unskilled programmers who quickly decide that any code they look at is badly written and should be thrown out. I don't think I should dumb down my code just so programmers less fluent with C can understand it. I have to consult a dictionary sometimes when I read Cormac McCarthy or Nabokov but I don't think they should write with easier words for my sake.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan Not to mention people aren't as smart as you debugging/understanding it. Also that code relies on the order of operations which I wouldn't recommend outside of math because it can be confusing. And it doesn't check that s isn't null.

Java is considered verbose for a number of reasons. It has a number of variable modifiers, it uses long names(which are generally good but can be stupid, especially in some cases of identifying multiple abstraction levels), and because it lacks type inference for generics and collection literals. c frequently makes the opposite mistakes with tiny cryptic or non whole word names. C lacks generic programming, it does do a decent job with initializers but unfortunately those can only be used at initialization.

The point of the example is to explain pointers by starting with a more familiar concept: indexed arrays. It would help if you were referring to the book; the authors note more than once that "the programs are intended to be illustrative, not bullet-proof."

Understanding the precedence and order of evaluation of operators is fundamental to mastery of any programming language (chapter 2.12 in K&R). All C code must "rely on" the order of operations, and if an indirect assignment through a pointer with post-increment is confusing... well that's the point I was making in the first place.

Good quote, but there is nothing particularly clever in the line above. It is in the same league as if (something) or something ||= something_else.

This type of code used to run faster when compilers did less. It makes no difference now. I think that is why it has stuck around. I prefer to write C that uses array references where it makes things clearer.

Don't think so. Kernighan et al. are the first to say code should be clear first and made fast only if it matters. This is clear code. It may (or may not) be faster than an array-based version but that's not the point of the exercise in K&R -- the point is to teach how pointers work.

You'd be surprised what the compiler still doesn't do. For example, when writing a toy high-performance memory allocator for a university class, I was able to gain a significant[1] performance boost by replacing __attribute__((packed)) structs with pointer arithmetic #defines for the allocation block descriptors, with an identical memory layout.

[1] I don't remember the exact gain, but it was at least 10%.