Live data from Hacker News

To become a good C programmer (2011)

fabiensanglard.net

41–50 of 106 posts

Re: To become a good C programmer (2011)

#41
post #35
post #7

Earlier quoted context omitted.

I think the style should be avoided; code shouldn't be compact and variable names should be descriptive. Artificial example: for( int i = 0 ; i should be: for( int count = 0 ; count It may be allowed to use i in place of count here, but this is the only place where single name variables should be permitted and only if i is really just a simple array index iterator.

Even "i" can be changed to "index". My rule of thumb is this: If you wouldn't use the abbreviation when speaking, don't use it when coding. I don't understand why 'i' has been given a pass. The argument boils down to saved keystrokes. Typing is not the bottleneck.

I agree, and I have calculated this a while ago this based on average number of lines a programmer writes in 8 hours. I don't have the actual numbers but unless you type slower than ~30 words per minute, speed it isn't a bottleneck.

I have been using index instead of i in while loops lately. It's surprisingly concise.

Re: To become a good C programmer (2011)

#42
post #38

Earlier quoted context omitted.

My guess is that liking/not liking 'C' depends on how interested you are in its representation model. If you're actively disinterested in how things work as bits in memory, then I can't blame you a ... bit.

No the representation model is fine. It's where C tries to be something other than portable assembly where it goes awry. E.g. C has more syntax for arrays than actually exists at runtime, which leads to surprising behavior. The problem with array arguments discussed in the LKML thread posted above is a great example.

I am having trouble identifying "the LKML thread."

Re: To become a good C programmer (2011)

#43
post #7
post #3

K&R is often recommended, and it's certainly fun to read and accessible. But I've also heard it's outdated, and doesn't rally focus much on modern C software design, mostly because the world knew little about it when K&R was written. Thoughts?

I think the style should be avoided; code shouldn't be compact and variable names should be descriptive. Artificial example: for( int i = 0 ; i should be: for( int count = 0 ; count It may be allowed to use i in place of count here, but this is the only place where single name variables should be permitted and only if i is really just a simple array index iterator.

There should always be a balance between brevity and being too verbose.

all single letters = bad, java style thisIsALoopCounter = bad.

and in the c world i is almost universally understood to be used as a loop counter and index. If I came across 'count' in a c code I (briefly) might think it was related to a count of items in an array or similar.

Re: To become a good C programmer (2011)

#44
post #23

I found that, after learning the basics of the language via K&R or a similar book, the best way to get a good understanding of C and its weird corner cases and eccentricities is just to go through the comp.lang.c FAQ page. http://c-faq.com/index.html It's pretty comprehensive, and I found the level was pretty good for a "not total newbie, but still not familiar with the subtilties" level that can be kind of hard to f…

Making a blogging engine in C would be very informative (though difficult).

If you build it on ribs2 (with garbage collection) it wouldn't be too hard.

Re: To become a good C programmer (2011)

#46
post #19

What's a good practical but small enough project you can do with C? Typically if you are learning Ruby or Node, people recommend creating a blog. What's something like that for C?

A virtual machine and assembler. This is actually pretty straightforward and lots of fun.

Along the same lines: an emulator for an old computer or games console.

Re: To become a good C programmer (2011)

#47
post #5
post #3

K&R is often recommended, and it's certainly fun to read and accessible. But I've also heard it's outdated, and doesn't rally focus much on modern C software design, mostly because the world knew little about it when K&R was written. Thoughts?

K&R is still a great book but there are also other great books. Programming in C by Kochan and A Modern Approach by King are two fantastic books and much more suited to a true beginner than K&R is IMHO. Also Head First C and 21st Century C (second edition) are great books to read. The exercises in K&R are superb though and I highly recommend taking the time to do them all while you read K&R which I still feel you sho…

Since we're throwing out books, "The Absolute Beginner's Guide to C" (by Perry) has helped a number of people who felt completely overwhelmed by programming in general...

Re: To become a good C programmer (2011)

#48
post #38

Earlier quoted context omitted.

No the representation model is fine. It's where C tries to be something other than portable assembly where it goes awry. E.g. C has more syntax for arrays than actually exists at runtime, which leads to surprising behavior. The problem with array arguments discussed in the LKML thread posted above is a great example.

I am having trouble identifying "the LKML thread."

I think he meant this:

https://lkml.org/lkml/2015/9/3/428

(It's Torvalds on a bug made harder to spot by using array arguments in C, which you shouldn't do.)

Re: To become a good C programmer (2011)

#49

Earlier quoted context omitted.

I don't really understand what this means. How is that different from how anyone else uses a compiler?

I think he means that he works like this: 1. Write some C 2. Dump the corresponding assembly code 3. Modify the code by hand

4. Assemble

5. Load into assembly debugger

6. Learn

There is "C", the language, which can be relatively simple. Or hopelessly opaque depending on the author.

I think of C the language as just a shorthand for assembly. Only because that's how I use it.

http://www.lysator.liu.se/c/bwk-tutor.html

But then there is "C" in practice: the specifications, the "standard" libraries, preprocessors, Makefiles, autoconf, etc.

Re: To become a good C programmer (2011)

#50
post #40

Earlier quoted context omitted.

I'm not a super genius programmer by any means, but I've had a lot of pleasant surprises learning about the depths of Python.

I disagree: no static typing --> annoying runtime errors, no 'use strict'..

While I like static typing, there's a lot more that goes into making a language good or bad than that. On the whole, python seems pretty good to me. I'd take it over Java 90% of the time.
Post reply on HN