Hacker News new | past | comments | ask | show | jobs | submit login

Great applauses for not recommending the "indisputable classic" from K&R. The latter is really an introductory text that presents the features of the language in a chaotic manner and introduces some very nasty 1970s styles of coding.

Having just picked up this very book I appreciate the caution, however I will point out that K&R's tome - while perhaps not the definitive guide to style, is an approachable, brief overview of the C language for those of us who took it in high-school prior to C99 and have since been re-exposed to C through Arduino IDE and OpenSCAD.

The O'reily cow book covers C99 and is a good companion.

K&R gets so much hell, but it's a good, raw back to basics text. It deserves a place on the shelf beside the ARRL Ham Radio License Manual, or Wheelock's Latin, or Lyman's Guide to Reloading, or The Joy of Cooking, or the Elements of Style. It's the programming book for Boy Scouts, a crude, but essential Swiss Army Knife --the great programming book for the post-Apocalypse.

Also all of these are open source submissions.

Is there a list of this very nasty 1970s styles of coding somewhere? Is it mainly that it is outdated and doesn't describe the lastest C standards?

It is bad not only because it predates C99, but also because virtually any example consists of a couple of global variables/fixed-size arrays, a couple of badly named functions which operate on the globals and use some very "descriptive" names of the local variables. This book was born in an era when the modern understanding of "good code" was barely honored at all.

"Relying too heavily on external variables is fraught with peril since it leads to programs whose data connections are not at all obvious" - k&r, ch. 1

Who are these Kernighan and Ritchie guys? They obviously just don't understand "good code", terrible book!

People pick up on what you do, including supplied examples, not what you say.

(And I say this as someone who likes K&R.)

Take, for example, the declaration parsing example and honestly tell me that this isn't crappy code by any modern standard:

    enum { NAME, PARENS, BRACKETS };
    void dcl(void);
    void dirdcl(void);
    int gettoken(void);
    int tokentype;
    char token[MAXTOKEN];
    char name[MAXTOKEN];
    char datatype[MAXTOKEN]; /* data type = char, int, etc. */
    char out[1000];

    main()  /* convert declaration to words */
        while (gettoken() != EOF) {   /* 1st token on line */
            strcpy(datatype, token);  /* is the datatype */
            out[0] = '\0';
            dcl();       /* parse rest of line */
            if (tokentype != '\n')
                printf("syntax error\n");
            printf("%s: %s %s\n", name, out, datatype);
        return 0; 

Pg 124 from 2nd edition where this code is pulled (emphasis mine):

"[T]he programs are intended to be illustrative, not bullet-proof, there are significant restrictions on dcl."

In context this code illustrates the points they're trying to convey about complicated declarations quite well and is a precursor to understanding typedef later in the book.

Also, you left the nice inline comments off the variable declaration block.

I would like to see where typedef could have been used?

"Modern standard" or not, I find this piece of code highly readable, and, in general, very good for what it does, at the level (of simplicity, perhaps even "primitivism") at which it was intended to do that.

This piece of code is crap - it's not functional, keeps implicit state.

Not all quality code is functional.

Could someone point out the craps in the code ? I only noticed excess use of global variables , and out array(can't figure out why it was index only at zero)

would you also criticize newton's principia mathematica because he expressed the concept of infinitesimals using geometry instead of using liebniz's or lagrange's arguably clearer notations?

K&R was written in a different time, where computing had stricter (but not really different) constraints, but it's still arguably the clearest expositions of the language around.

considering computing hasn't changed that much since K&R was written, it's unlikely your idea of good code differs much from what was done 40 years ago. for example, functional programming, which is the popular dogma today, was invented around that time.

take the good (it's not hard to find in a book like K&R), discard the (perceived) bad, and move on with your life.

Actually - it does mention it, but at the very bottom with a short explanation and a link. I have a first edition of the book, so I agree with your statement - but do the later editions (or the latest for that matter) still carry the ugliness? Perhaps they do...?

There are no later editions other than the 2nd, from 1988. Draw your own conclusions...

(I'm very fond of the book as a historical artifact, btw)

As this list is of open source books, no...K&R C shouldn't be on there.

Is there a former ;-)

Non-native speaker here :-)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact