Hacker News Reader

Having read both I have to respectfully but firmly disagree.

The code examples in The Practice of Programming are atrocious, and I mean it - they are full of really, really bad naming and arcane abbreviations and thus unreadable code.

How is this for readable and maintainable code? (Random code example from The Practice of Programming, copied verbatim letter by letter)

    /* delname: remove first matching nameval from nvtab */
    int delname(char *name)
    {
        int i;
        
        for (i = 0; i < nvtab.nval; i++)
            if (strcmp(nvtab.nameval[i].name, name) == 0) {
                memmove(nvtab.nameval+i, nvtab.nameval+i+1),
                    (nvtab.nval-(i+1)) * sizeof(Nameval);
                nvtab.nval--;
                return 1;
            }
        return 0;
    }

- Confusing function explanation in a custom format. What is nameval? What is nvtab?

- Missing curly braces in the for loop

- Confusing long lines (line starting with memmove())

- Confusing inline transformations: nvtab.nameval+i+1, nvtab.nval-(i+1) directly in function arguments. What do they mean?

- Bad, bad naming (nvtab, nameval)

- Inconsistent case (nameval vs Nameval)

This is just ONE RANDOM EXAMPLE, mind you. The book is atrocious, I don't recommend it to anyone.

Code Complete is much thicker but that's the only disadvantage. It's not bloated, it's simply more comprehensive, it's consistent and teaches to write actual readable code.

I've never read that book, but I've worked with a lot of C. That code seems perfectly maintainable as an experienced C programmer.

- Confusing function explanation in a custom format. What is nameval? What is nvtab?

nvtab is obviously a name/value table. nameval is an array of Nameval structures. nval is the count of Nameval structures in nvtab.nameval.

- Missing curly braces in the for loop

This isn't required by C. It's an often-debated subject in style guides for C.

- Confusing long lines (line starting with memmove())

How is that confusing? Lines end when you see a ; that isn't inside a set of parens.

- Confusing inline transformations: nvtab.nameval+i+1, nvtab.nval-(i+1) directly in function arguments. What do they mean?

What do you mean, "what do they mean"? (int)-((int)+1) seems pretty obvious. Working with memory addresses doesn't seem a foreign concept.

- Bad, bad naming (nvtab, nameval)

nvtab seems like a reasonable name for a name value table. nameval seems like a reasonable name for something that holds a bunch of Nameval structs.

- Inconsistent case (nameval vs Nameval)

nameval and Nameval are different. If you used consistent case, the program wouldn't work. nameval is an array containing Namevals. Nameval is a struct.

This just seems like a case of you not really understanding C rather than a case of experienced C programmers writing C that other C programmers could maintain.

I had a post with most of the same stuff you said saved for after lunch but you beat me to it with a more precise explanation. I haven't touched C in years but it wasn't difficult to understand the code, though a couple of comments would have made it quicker to parse.

Perhaps this is the effect that high level languages are having on developers - anything that DoesntHaveExplicitNames is classed as confusing and syntax flexibility is seen as wrong. In the web development field, I often get weird looks for writing one line if statement bodies. A ternary operator usually yields furrowed eyebrows for a few seconds. An issue of style over substance, IMO.

Then again, I'm sure that ASM developers looked at C developers the same way.

Probably, the key part of what you said, is "couple of comments". Makes a huge difference if the same convention is on,say, 100,000 LOC, and the people who wrote it didnt give proper comments and left the company! :P

Speaking on naming conventions: This is the name of a class in Chromium source code (C++): 'BufferedSpdyFramerVisitorInterface' . The codebase is that meticulous! For a guy who wanted to learn about browser implementation,and downloaded the codebase,this is good.

These meticulous naming conventions- has it anything to do with using a full-blown ide vs vim?

> These meticulous naming conventions- has it anything to do with using a full-blown ide vs vim?

What would you think that?

If it's because of auto-complete, please understand that this is 2012, and vim is not [just] vi. There are several different flavors of auto-complete available in vim; some built in, some as extensions.

Not to mention that there's eclim for full-scale Eclipse completion and ctags which provides almost the same functionality (though not as intelligently).

C programmer are so used to terrible code that it doesn't even stand out to them.

The thing that sticks out for me is that there's a bug in that code - a syntax error no less - and none of the C programmers commenting seem to have spotted it. (hint: read the memmove line a bit more closely)

I don't think you need much more evidence that the syntax is confusing.

> The thing that sticks out for me is that there's a bug in that code - a syntax error no less - and none of the C programmers commenting seem to have spotted it. (hint: read the memmove line a bit more closely)

That typo was introduced in Revisor's transcription; it doesn't appear in the original. I checked when I first read his comment, 8 or 9 hours ago. It hardly seemed worth mentioning; typos happen and it had nothing to do with his argument.

> I don't think you need much more evidence that the syntax is confusing.

Someone unfamiliar with the language introducing a one character typo during a character-by-character transcription from a book is evidence that "the syntax is confusing"?

What an odd yardstick to use.

The point is that the code is hard to understand. In this case it's a bracket misplaced, so the compiler will pick it up immediately, but if it's a misplaced +1 or index then you won't notice until you get hacked with a buffer overflow.

Now if you put each argument on it's own line, or use reasonable variable names - something that C programmers seem to fight against - neither of those bugs happen, because you can just look at the code and see the problem straight away.

Not only do I understand that code, and agree it's reasonable C code, I suspect you made a mistake when copying the memmove line. I think it should be:

  memmove(nvtab.nameval+i, nvtab.nameval+i+1,
          (nvtab.nval-(i+1)) * sizeof(Nameval));

Experience C programmers will know memmove - it's been a long time since I even saw the signature, but I thought it was going to be source, destination and size. (Looked it up just now to be sure.) These "inline transformations" are common on addresses in C.

I personally like braces around for loops, but things like Nameval being the struct type for a nameval variable is common C practice.

As emidln points out, your complaints seem to suggest unfamiliarity with C on your part rather than any flaws with that code, which looks perfectly fine to me. To his responses I'll only add:

> Confusing function explanation in a custom format.

It's a straightforward explanation in 6 words of English of what the function does. That's not a "custom format", that's a simple and concise introduction to the function. Far preferable to some mess of nonsense boilerplate XML.

Also worth mentioning is that in the context of the book that function sits in part of a larger discussion which, IIRC, gives the definition Nameval struct (that's definitely not some kind of accidental case flub), talks about the structure of nvtab, etc.

I'm absolutely shocked that someone can defend this code example. OK, you say it's readable for an experienced C programmer which I'm not. But is that really the best practice you want to teach other programmers? Fourfold inline computation? Cryptic variable names like nvtab.nval? No curly braces around a block where they are optional but prone to error if missing? Comments that use deep local jargon (what is nameval, what is nvtab)?

Defend it all you will (and also downvote just because you disagree, why thank you), I stand by what I said: The Practice of Programming is a harmful book and cannot be compared to Code Complete which is much more thoughtful and has unspeakably more attention to detail in naming, syntax, logic, programmer's psychology, project scope, everything.

> But is that really the best practice you want to teach other programmers?

Apart from using braces for `for` loops, yes.

> Fourfold inline computation?

This snippet

    void *dest = blah blah;
    void *src = blah blah;    
    size_t cnt = blah blah;
    memmove(dest, src, cnt);

isn't any different from memmove(blah blah, blah blah, blah blah) if you program in C. Introducing unnecessary noise doesn't contribute to code clarity.

> Cryptic variable names like nvtab.nval?

Suggest a better name. name_value_table.number_values? And give me one good reason how is this better?

There is a whole camp up in arms against abbreviating `count` as `cnt`. Though they never told me what issue they have understanding that `cnt` means `count`.

The only issues I have with abbreviations is they might introduce typos if you choose confusing ones. nval, nvtab etc aren't confusing, not by a mile. If you are confused by them, expanding them isn't going to help you either.

> Comments that use deep local jargon (what is nameval, what is nvtab)?

A localized code snippet uses local jargon. If you disagree, I would love to see your suggestions on improving them.

> Defend it all you will (and also downvote just because you disagree, why thank you), I stand by what I said:

Apart from standing by, show us how do you make it more readable. Your complains so far are fluffs.

> The Practice of Programming is a harmful book and cannot be compared to Code Complete which is much more thoughtful and has unspeakably more attention to detail in naming, syntax, logic, programmer's psychology, project scope, everything.

Sounds like Code Complete is programming for people who can't program.

No, there are new, concise book, though I agree they're rare:

The Art of Readable Code (by Googlers)

http://www.amazon.com/Art-Readable-Code-Dustin-Boswell/dp/05...

I think that's an unnecessarily harsh review. From looking at the table of contents, it looks to me like Code Complete covers a lot more territory, eg. there doesn't appear to be anything on code reviews in The Practice of Programming.

That said, I'm going to have to find a copy of it now and compare them :)

I loved the size of code complete but the brevity of the content itself. I didn't read from cover to cover, but always had the copy on the table and read a chapter each morning.