Comment by emidln | Hacker News Reader

Comment by emidln | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com