How to be a better C programmer?

[istillshine@gmail.com]

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@gmail.com]

Re: How to be a better C programmer?

On Apr 10, 8:37 pm, istillsh...@gma il.com wrote:

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@gmail.com]

Re: How to be a better C programmer?

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.

[istillshine@gmail.com]

Re: How to be a better C programmer?

On Apr 11, 2:38 am, user923005 <dcor...@connx. comwrote:

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]

Re: How to be a better C programmer?

On Apr 11, 9:55 am, istillsh...@gma il.com wrote:

On Apr 11, 2:38 am, user923005 <dcor...@connx. comwrote:
>

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?

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 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.

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]

Re: How to be a better C programmer?

On Apr 10, 7:37 pm, istillsh...@gma il.com wrote:

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.

[CBFalconer]

Re: How to be a better C programmer?

John Bode wrote:

>

.... snip ...

>
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.

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.


** Posted from http://www.teranews.com **

[Keith Thompson]

Re: How to be a better C programmer?

CBFalconer <cbfalconer@yah oo.comwrites:
[...]

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.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[istillshine@gmail.com]

Re: How to be a better C programmer?

On Apr 12, 4:38 am, CBFalconer <cbfalco...@yah oo.comwrote:

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]

Re: How to be a better C programmer?

CBFalconer <cbfalconer@yah oo.comwrites:

John Bode wrote:

>>

... snip ...

>>
>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.

>
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]

Re: How to be a better C programmer?

Richard wrote:

CBFalconer <cbfalconer@yah oo.comwrites:
>

>John Bode wrote:

>>>

>... snip ...

>>>
>>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.

>>
>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.

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]

Re: How to be a better C programmer?

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 Heathfield]

Re: How to be a better C programmer?

santosh said:

<snip>

Frankly I find it surprising that using = when you want == is
apparently a common error, since I have never committed this myself,

How do you know?

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Bos]

Re: How to be a better C programmer?

CBFalconer <cbfalconer@yah oo.comwrote:

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

[Richard Heathfield]

Re: How to be a better C programmer?

Richard Bos said:

CBFalconer <cbfalconer@yah oo.comwrote:
>

>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,

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

it leads one into a false sense of security.

One, maybe, but not all.

Here you are, cleverly having set up all your
equalities so that you _know_ that a typo will lead the compiler to
complain,

For certain values of "you", possibly. Here *I* am, wisely having set up my
equalities-that-have-constants with the constants on the left so that I
know the compiler will complain if I've typed an = operator instead of an
== operator *when comparing against a constant*.

There is no silver bullet. Putting constants on the left of comparisons
will not cause the compiler to cause about *all* typographical errors.
Neither will it cure whooping cough or boils. That doesn't mean it isn't
worth doing.

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

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

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999