Memorizing the C Standard

Is it necessary to memorize the C standard to become an excellent C programmer?

Article Type: Viewpoint

Author: Robert S. M. Trower

Affiliation: Trantor Standard Systems Inc. Brockville

I learned to program in C in 1985. It was my fifth or six language by then.5y

I am delightfully surprised that my opinion is unanimous here.

No you don’t need to memorize the C standard, or any other standard.

You need to have reasonable familiarity with the language in terms of what you can do, and how you might do it, but I have been programming in C for [counts for a while] Yikes. A long time. I still could not say for sure what the syntax is for some common C library functions without looking them up. My editor fills in half the stuff these days. I know what can be done, and type it in.

Not everybody is the same, and I think I am a bit of an outlier, but you can see that nobody is putting much stock in memorizing the language specification.

The C programming language is my ‘goto’ if I have a choice, but I know a lot of languages and still have to switch back and forth, so getting too invested in particular syntax or idioms is unhelpful for me. I have to make stuff work.

Again, not everybody is the same, but I have a story for you and a lesson people learned before I was even born — a time my youngest child would argue does not exist.

I am a hands-on programmer, but I have managed from time to time. I was the ‘Manager of the Development Environment’ on a $60M project. I was responsible for the Unix, and Database admins, and network people, and others — everyone maintaining the system for software developers upstairs. One day, late in the afternoon, I was called up because all 40 programmers had been idled by a bug they simply could not find. They had narrowed it down to a single page. I took one look at the page and said, “I don’t have any idea what this is doing, but this line breaks one my rules that braces always go on ‘if’ statements because as time goes on people make the mistake of adding another line without adding braces, and you get bugs. There was silence for a couple of heartbeats and the team leader said “that’s the bug”.

They were sufficiently impressed by that lucky find that the next time they ran into trouble they called me up to consult on the programming, and this one was a doozy. They had designed the system in such a way that it had a core reliance on Templates. This was in the mid-90s, and compilers were not great with new constructs. They had gotten to the point where compiling with the templates was taking too long and could not be done during their overnight window. It was leaving programmers idle in the morning and it was threatening to shut them down altogether. What they needed was a tool to do part of the compiler’s work to build the interfaces ‘manually’. Fortunately, they were using a fairly sophisticated system where the interfaces were built from a design in a database. They gave me what their target code had to look like, and I wrote a tool to write code with the interfaces for them. As far as I know, that program precedes the build to this day.

In both cases, they got lucky, and this did not bite them, which is good because we had a $5million dollar performance penalty if we were late.

In both cases, they had made an incorrect assumption about things. Both things they were doing were legit in the language, but at least in this case, they were bad practice. Had I been working on this, I would have followed my rule with the braces, and I would have paid more attention to the characteristics of the build with the Templates. In the latter case, it would at least be partly because I would have to confirm how they work. Also, I can build tools sometimes to recover :)

The long story above is to drive home this point:

It’s not so much what you don’t know that gives you problems. It’s what you know that ain’t so.**

In both of those cases, they ‘knew’ that what they were doing was fine, and they were wrong.

Sorry we had to go to mars and back. Finally, this relates in a couple of ways to the question about the C standard:

-- If you ‘know’ the C standard, and are confident in that knowledge, and you are wrong somehow, you may well find yourself in a situation like in that (true) story.

-- If you ‘know’ the C standard, and it has changed, or this compiler implements it incorrectly, you will find yourself in the situation above as well.

In the second case, you are even ‘correct’ in a sense, but you are still more confident in your knowledge than you should be. You are still ‘operationally’ wrong.

As a parting shot, I would say you only have so much bandwidth and it is better to use it to learn powerful principles, and do hands-on practice programming. It’s not so great to memorize stuff that could lead to trouble.

** This is my wording of an old saying that can’t be reasonably attributed.