How to be a better C programmer?

[istillshine]

I personally like C, and do not like any OO languages. The reference
books for OO languages are too heavy for me. They just made things
complicated. Someone laughed at my opinion, saying Google code bases
are mostly written in C++.

I read somewhere about the best way to learn C (or a programming
language in general). I agree with the points. I quote them below:

"The best way to do it is to read some stuff written by masters of the
form, write some things yourself, read a lot more, write a little
more, read a lot more, write some more ... and repeat until your
writing begins to develop the kind of strength and economy you see in
your models."

For C books, I have carefully read The C Programming Language, The C
Answer Book, and The C Puzzle Book. For real C code, I have carefully
read about 20,000 lines written by UC Berkeley guys. I myself have
written about 15,000 lines, not counting tiny toy programs. It is my
situation.

My question is where I can find "some stuff written by masters of the
form" ? I think BSD source code is written by masters. Am I right?

 

[istillshine]

I personally like C, and do not like any OO languages. The reference
books for OO languages are too heavy for me. They just made things
complicated. Someone laughed at my opinion, saying Google code bases
are mostly written in C++.

I read somewhere about the best way to learn C (or a programming
language in general). I agree with the points. I quote them below:

"The best way to do it is to read some stuff written by masters of the
form, write some things yourself, read a lot more, write a little
more, read a lot more, write some more ... and repeat until your
writing begins to develop the kind of strength and economy you see in
your models."

For C books, I have carefully read The C Programming Language, The C
Answer Book, and The C Puzzle Book. For real C code, I have carefully
read about 20,000 lines written by UC Berkeley guys. I myself have
written about 15,000 lines, not counting tiny toy programs. It is my
situation.

My question is where I can find "some stuff written by masters of the
form" ? I think BSD source code is written by masters. Am I right?

By the way, I think the author of PuTTY is a master. I used PuTTY
everyday and am fond of it. I examined its source code, and became
fond of it too.

 

[istillshine]

By the way, I think the author of PuTTY is a master. I use PuTTY
everyday and am fond of it. I examined its source code, and became
fond of it too.

 

[user923005]

On Apr 10, 5:37 pm, (e-mail address removed) wrote:
[snip]

My question is where I can find "some stuff written by masters of the
form" ?  I think BSD source code is written by masters.  Am I right?

Depends on who wrote it. BSD and relatives are written by a lot of
people.
For instance:
If Chris Torek wrote it, it's good.
If Peter McIlroy wrote it, it's good.
If Keith Bostic wrote it, it's good.
If Jon Bentley wrote it, it's good.

However, you cannot assume that just because code is part of BSD that
it is written by a master.

I think looking at what experts did is a good idea. But it is more
important to understand the fundamental nature of algorithms.
Otherwise, you will write stuff that is as pretty as theirs but it
blows chunks in performance.
IMO-YMMV

 

[istillshine]

Depends on who wrote it. BSD and relatives are written by a lot of
people.
For instance:
If Chris Torek wrote it, it's good.
If Peter McIlroy wrote it, it's good.
If Keith Bostic wrote it, it's good.
If Jon Bentley wrote it, it's good.

How about Terrence R. Lambert?

I think looking at what experts did is a good idea. But it is more
important to understand the fundamental nature of algorithms.
Otherwise, you will write stuff that is as pretty as theirs but it
blows chunks in performance.

I studied Fundamentals of Data Structure (in C) many years ago. I
could not recall the author's name now. Is that a good book? I need
to find time to review it again.

 

[user923005]

How about Terrence R. Lambert?

His stuff is good (I went and looked over some of his work). My list
was not intended to be exhaustive. The authors that I mentioned were
named because I know of their work fairly well because they tend to
work on things that are interesting to me so I read them.

I studied Fundamentals of Data Structure (in C) many years ago.  I
could not recall the author's name now.  Is that a good book?  I need
to find time to review it again.

I have not read that one, so I cannot comment on it.
I like Knuth, Budd, Weiss, Sedgewick
and this is a must-read:
http://www.amazon.com/Introduction-Algorithms-Second-Thomas-Cormen/dp/0262531968
If you don't want to buy it, check it out from a library.

 

[John Bode]

I personally like C, and do not like any OO languages. The reference
books for OO languages are too heavy for me. They just made things
complicated. Someone laughed at my opinion, saying Google code bases
are mostly written in C++.

I read somewhere about the best way to learn C (or a programming
language in general). I agree with the points. I quote them below:

"The best way to do it is to read some stuff written by masters of the
form, write some things yourself, read a lot more, write a little
more, read a lot more, write some more ... and repeat until your
writing begins to develop the kind of strength and economy you see in
your models."

For C books, I have carefully read The C Programming Language, The C
Answer Book, and The C Puzzle Book. For real C code, I have carefully
read about 20,000 lines written by UC Berkeley guys. I myself have
written about 15,000 lines, not counting tiny toy programs. It is my
situation.

My question is where I can find "some stuff written by masters of the
form" ? I think BSD source code is written by masters. Am I right?

A Rumsfeldian koan: there are true masters; there are people who think
they are masters; there are people whom other people think are
masters; and then there's the rest of us.

The trick is figuring out who's who.

Ultimately, practice is the only way to significantly improve your
skills. It's good to look at what other people have done to get a
feel for good style and practice, but until you've pounded out
thousands of lines of code for yourself, you may not understand *why*
the code was written that way. You have to make mistakes, and go
through the effort of fixing those mistakes, to appreciate the lessons
that other people's code provides.

 

[Keith Thompson]

One of the advantages of having been at this for a while is that
you learn what your common mistakes are, and can arrange to
orgamize the code to automatically detect them. A couple of simple
tricks are:

1. Make similary functions have similar parameter lists.
2. Organize statements so that error will show up.

As an example of 2 consider "if (2 = x) ...". Placing the constant
first means that using a single = sign (the fault) is automatically
compiler detected.

Just to offer another perspective, I personally find the "if (2 == x)"
form extremely ugly. I understand that it's logically and
mathematically equivalent to "if (x == 2)" form, and that it can help
catch some errors, but for me it's just not worth it.

 

[istillshine]

As an example of 2 consider "if (2 = x) ...". Placing the constant
first means that using a single = sign (the fault) is automatically
compiler detected.

Although many people recommend the form if (2 == x), I don't like it.
It is contrary to my common sense.

 

[Richard]

One of the advantages of having been at this for a while is that
you learn what your common mistakes are, and can arrange to
orgamize the code to automatically detect them. A couple of simple
tricks are:

1. Make similary functions have similar parameter lists.

Whatever that means. I think it needs explaining.

2. Organize statements so that error will show up.

As an example of 2 consider "if (2 = x) ...". Placing the constant
first means that using a single = sign (the fault) is automatically
compiler detected.

I personally find that form to be ugly and at odds with the great
majority of code out there. "=" and "==" does happen but very rarely
with any half competent C programmer.

 

[santosh]

Whatever that means. I think it needs explaining.


I personally find that form to be ugly and at odds with the great
majority of code out there. "=" and "==" does happen but very rarely
with any half competent C programmer.

Also many compilers and all lints give you warning about such typos.
Frankly I find it surprising that using = when you want == is
apparently a common error, since I have never committed this myself,
though I have of course had my share of typos.

 

[Willem]

santosh wrote:
) Frankly I find it surprising that using = when you want == is
) apparently a common error, since I have never committed this myself,
) though I have of course had my share of typos.

I've had keyboards that were a bit worn out, with the effect that
sometimes in double keystrokes, the second wasn't recognized.
That suddenly makes using = instead of == a common typo.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Richard Bos]

As an example of 2 consider "if (2 = x) ...". Placing the constant
first means that using a single = sign (the fault) is automatically
compiler detected.

Not only is that aesthetically abominable, it leads one into a false
sense of security. Here you are, cleverly having set up all your
equalities so that you _know_ that a typo will lead the compiler to
complain, and then you type "if (table_of_data[1] = temporary_value)"...

Richard

 

[Ian Collins]

Richard Bos said:

and then you type "if (table_of_data[1] = temporary_value)"...

....then presumably you have a bug <shrug>.

Which your unit tests will catch

 

[Bartc]

Richard Bos said:


Beauty is in the eye of the beholder. What about all those aesthetically
abominable breaks out of loops?

Even with just the one break? And how else would you stop this fragment
running forever:

#define endlessloop while(1)

endlessloop {
break;
}

(Apart from using return, goto or exit.)

 

[Bartc]

Richard Bos said:


Beauty is in the eye of the beholder. What about all those aesthetically
abominable breaks out of loops?

Even with just the one break? And how else would you stop this fragment
running forever:

#define endlessloop while(1)

endlessloop {
break;
}

(Apart from using return, goto or exit.)

 

[Bartc]

Bartc said:


Same way I did last time.

Yeah, I have serious machine problems I think. At the moment the entire
motherboard is perched precariously on a road atlas on top of the case. I
think there's a bad connection in there somewhere.

Makes a mere software bug seem so trivial.

 

[istillshine]

I have not read that one, so I cannot comment on it.
I like Knuth, Budd, Weiss, Sedgewick
and this is a must-read:http://www.amazon.com/Introduction-Algorithms-Second-Thomas-Cormen/dp...
If you don't want to buy it, check it out from a library.

It was not Fundamentals of Data Structure (in C). I was Data
Structure and Algorithm Analysis (in C) that I studied. Seven years
have passed; I almost forgot the book's name.
I think I would not bother Knuth's book. Data Structure and Algorithm
Analysis (in C) was good enough for me. I felt the subject quite
difficult 7 years ago, when I was a 2nd
year undergrad.

 

[jxh]

...
I read somewhere about the best way to learn C (or a
programming language in general). I agree with the points. I
quote them below:

"The best way to do it is to read some stuff written by masters
of the form, write some things yourself, read a lot more, write
a little more, read a lot more, write some more ... and repeat
until your writing begins to develop the kind of strength and
economy you see in your models."
...

Note that in what you quote there is no mention of C. This is
because becomming a better C programmer is a specialization of
becoming a better programmer, which can also be taken to be a
specialization of becoming a better problem solver.

In this vein, I would encourage regularly taking part of any
activity that exercises the problem solving muscle of your
brain. The focus is on fundamentals:
- understanding the problem
- identifying the knowns
- identifying the relevant unknowns
- breaking the problem down into smaller problems if required
- determining if the problem (or sub-problems) resembles a
previously solved problem
- etc.

Problem solving, and programming in particular, is a detail
oriented activity. So, if you are not already, you should
train yourself to become a detail oriented person.
- pay attention to the "small" stuff, including (but not
limited to)
- commenting code
- matching your resource allocations with deallocations
- checking all return values for errors
- sanity checking passed in parameter values
- adding error logs for situations that are checked but
are considered to be exceptional
- following the coding guidelines
- double check your work
- incrementally unit test the code as the project progresses

The benefit of being a detail oriented person (one that
cares about dotting i's and crossing t's) is that you should
find yourself spending less time fixing bugs in your code.
Either you are coding fewer bugs, or that the bugs that do
occur have sufficient instrumentation that allows you to
identify the source of the problem quickly. Spending less
time fixing bugs in your code gives you more time to write
new code, or help fix bugs in other people's code, and both
of these help increase your standing among your peers.

For C programming specifically, if you are already comfortable
with the basics of the language itself (which I gather from
the C books you listed) I would add that the C-faq itself
should be read carefully. It provides good answers on how to
deal with the most common C programming issues (at least as
presented to the comp.lang.c forum).

-- James

 

[user923005]

Note that in what you quote there is no mention of C.  This is
because becomming a better C programmer is a specialization of
becoming a better programmer, which can also be taken to be a
specialization of becoming a better problem solver.

In this vein, I would encourage regularly taking part of any
activity that exercises the problem solving muscle of your
brain.  The focus is on fundamentals:
 - understanding the problem
 - identifying the knowns
 - identifying the relevant unknowns
 - breaking the problem down into smaller problems if required
 - determining if the problem (or sub-problems) resembles a
   previously solved problem
 - etc.

Problem solving, and programming in particular, is a detail
oriented activity. So, if you are not already, you should
train yourself to become a detail oriented person.
 - pay attention to the "small" stuff, including (but not
   limited to)
   - commenting code
   - matching your resource allocations with deallocations
   - checking all return values for errors
   - sanity checking passed in parameter values
   - adding error logs for situations that are checked but
     are considered to be exceptional
   - following the coding guidelines
 - double check your work
 - incrementally unit test the code as the project progresses

The benefit of being a detail oriented person (one that
cares about dotting i's and crossing t's) is that you should
find yourself spending less time fixing bugs in your code.
Either you are coding fewer bugs, or that the bugs that do
occur have sufficient instrumentation that allows you to
identify the source of the problem quickly.  Spending less
time fixing bugs in your code gives you more time to write
new code, or help fix bugs in other people's code, and both
of these help increase your standing among your peers.

For C programming specifically, if you are already comfortable
with the basics of the language itself (which I gather from
the C books you listed) I would add that the C-faq itself
should be read carefully.  It provides good answers on how to
deal with the most common C programming issues (at least as
presented to the comp.lang.c forum).

-- James

This is really well written.
I guess that James is "James C. Hu"
Is that right?