Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let's see.

I've seen in several places, including Advice for Computer Science College Students, by Joel Spolsky, that a graduated Computer Science student must know C.

How do I know if I know C or not?

I have developed a few projects in C (an implementation of the ext2 filesystem with FUSE, and a few others), but I suppose it means more than just knowing pointers, free, etc.


migration rejected from Mar 24 '14 at 9:22

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by Yannis Mar 24 '14 at 9:22

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

You implemented ext2? – user1249 Apr 20 '11 at 20:27
@Thorbjørn Yes. A driver of ext2 using [FUSE](, although I didn't implement all the features, only basics. – Oscar Mederos Apr 20 '11 at 20:33
Have you tried that normally accepted route?. – Josh K Apr 20 '11 at 20:52
When you don't have ask when you can say you know C. – Pemdas Apr 20 '11 at 21:22
A gentleman is someone who knows how to program in C, but doesn't. – Andrew Grimm Apr 21 '11 at 3:16

10 Answers 10

up vote 16 down vote accepted

The Problem

The problem is the phrase knowing C is subjective. Some people think you can learn to read the syntax of a programming language and know it. Others think you need to know every little dark corner and gotcha to know a programming language.

I mean if you can read a menu in Spanish and figure out what to order at a Mexican restaurant, do you know Spanish? Or should you be able to translate any English document to Spanish and all the regional dialects with all the subtlety of each region's specific customs to know Spanish.

I know more than a few people that spent 4 years in high school learning Spanish, and can read it and pronounce the words correctly even with very convincing accents from different countries, but can't form anything more than rudimentary "where is the bathroom" type constructs on their own? The definitely do not know the language.

Subjective Opinion

My opinion is to know a programming language, means you have advanced knowledge of the language, you need to be able to sit down and write good idiomatic code that doesn't look like another language you learned previously.

It means you use modern best practices, it means you know how to apply common programming algorithms in the most pragmatic idioms available in the language.

I means you know when and where to look for the right answer for things you don't know for things like standard libraries and frameworks rather than re-inventing something yourself. You don't need to know everything, but you do need to know how to find out what you don't know.

To me know means you can write high quality code in the language, not just make something work.

For Example: Python that looks like procedural C code, just with Python syntax and doesn't use any Pythonic idioms is not written by someone that knows Python. You don't need to use lambda:, list comprehensions or crazy meta-programming constructs everywhere you possibly can, but know when to apply these idioms with restraint does point to that you know the language.

Knowing C means you should be able to write idiomatic C, that follows empirical best practices, no common newbie errors with = vs ==, no memory leaks, write includes that don't include everything over and over again, etc.

NOTE: Spanish is the straw man here, just like C is in the question. Replace Spanish with any other language, replace C with any other programming language, same subjective argument.


When the meaning of this is obvious:

while(*src++ = *dest++);

Then you know C. When you can tell that its wrong, then you really know C.

intent is more important than meaning with errors like this. – Jarrod Roberson Apr 20 '11 at 20:32
@fuzzy lollipop, what? – Winston Ewert Apr 20 '11 at 21:43
is it just that you're copying the destination into the source? – Carson Myers Apr 21 '11 at 4:07
@Winston No, it works, I had tried it when I was trying to figure out what was wrong with it. I thought there'd be something subtle – Carson Myers Apr 22 '11 at 20:10
@PrimožKralj, it stops when it finds the null-terminator in the string. – Winston Ewert Aug 25 '13 at 14:19

C isn't a big language and there are only a few 'design patterns' (horrible term but I'm not using paradigm in public)

If you have read K&R and understand pointers then you know C.

If you are comfortable with function pointer declarations and can write the quicksort compare function without looking up the arguments you are an expert


As with many programming languages, C is syntactically small, so you can learn the syntax in a day, and many of the idioms in a few days. But what makes a developer productive in a programming language is thorough knowledge of the standard library and of other libraries commonly used with the language; functionality, strengths, and weaknesses.

For example, I used to really know C++, but after years of not using it, and the changes to the standard and quasi-standard libraries done since, all I can say is that I'm well acquainted with the language.

The best way to get to really know a programming language is through study while working on a significant project that uses it. Participating on an open source project may be good because contributed code is very scrutinized in those; if your contributions are accepted, you know, and if they're accepted without amendments, you really know.


Actually, I think that Spolsky's advice on learning C had to do with the fact that knowing C means that you understand low-level concepts that are common in all the operating systems, runtime environments, libraries, etc. that we use everyday (caused by the fact that they are practically all implemented in C).

Some of these concepts are related to how computers are physically implemented and programmed at the lowest level (microcode). This refers to things such as the amount of bits in an integer being related to the register size of a processor, why you can run into weird errors if you use floats to calculate integers, when and how to deal with endianness, etc.

Some things however are actually related to C itself, in the sense that the way K&R encapsulated some of these things causes some bugs or program behaviours to be more common than others. For example, code like if (x = y) {...} can linger in systems for years. This refers to recognizing when a problem or behaviour is caused by such a bug.

Doing lots of C programming and causing, encountering, dealing with and solving these issues in practice eventually adds up to knowing C.


Knowing how to program C(or anylangue) isnt the big deal. Anyone can learn the syntax. How good are you at applying it , thats what matters. And that takes time. There is no quanitifiable leven for "good". You can always get better if you keep learning.


You know C when you understand Duff's Device.

Slightly adapted (to match modern C) from Wikipedia:

void send(short* to, short* from, int count)
        int n=(count+7)/8;
        case 0:       do{      *to = *from++;
        case 7:               *to = *from++;
        case 6:               *to = *from++;
        case 5:               *to = *from++;
        case 4:               *to = *from++;
        case 3:               *to = *from++;
        case 2:               *to = *from++;
        case 1:               *to = *from++;
If you call this code 3 times in a row, Michael Keaton will appear. It is more hideous than Nathan Fillion in a bonnet. But you can do some pretty weird stuff in C for sure. – Bent May 9 at 10:55

When not only you can produce working non-trivial code, but also when you become familiar with implementation-defined behavior, undefined behavior, details of each compilation phase (preprocessing, compiling, linking), reserved names, and sequence points.


You know a language when you know why a language does certain things the way it does. For example, you know why declaring a function parameter as T a[] is equivalent to declaring it as T *a, or why you can subscript a pointer, or why statements like i = i++ are bad juju.

Arrays and pointers are not equivalent… – kai May 18 at 10:50
@kai - never said they were; I said that, in a function parameter declaration, T a[] and T *a are the same; both declare a as a pointer. See the C language standard, para 7. – John Bode May 18 at 11:50
Interesting. Why is this? And is it really common knowledge? Like not "is it common knowledge that in function parameter lists, they are equivalent", but "is it common knowledge WHY they are equivalent in function parameter lists (other than 'the spec says so')"? – kai May 18 at 12:25
@kai: It falls out of how C treats array expressions. Unless it is the operand of the sizeof or unary & operators, an array expression will be converted or "decay" to a pointer expression, and the value of the pointer will be the address of the first element. When you pass an array expression as a function argument, the function will only ever receive a pointer value. Thus, any array parameter declaration is "adjusted" to a pointer type. It should be common knowledge, but isn't, because most intro C materials suck. – John Bode May 18 at 14:08

You know C if you can tell K&R something new about it. ;-)

When it comes to languages, knowledge is not about pointer-to-function-returning-pointer-to-array-of-functions-returning-this-very-pointer, it's about techniques, elegance and beauty.

I often compare programming to writing poems. There are some concise rules (that you may break) and there's something you want to express. It doesn't make you a good poet if you know the words in the language. Knowledge about grammar will also not be very helpful. Striving for beauty will.

That being said, here's an adapted version from a famous quote:

If one asks "How do I know if I know C or not?", and somebody answers, they both don't know.

"To make a prairie it takes a clover and a bee,
one clover, and a bee,
And revery.
The revery alone will do,
If bees are few."
(Emily Dickinson)

This is just pointless rhetoric -1 – Matt Ellen Apr 21 '11 at 12:09
Yep, but I like it. – Philip Apr 21 '11 at 12:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.