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?

On Apr 10, 8:37 pm, istillsh...@gmail.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.

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.

On Apr 10, 5:37pm, istillsh...@gmail.com 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

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

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

On Apr 11, 9:55am, istillsh...@gmail.com wrote:
> On Apr 11, 2:38 am, user923005 <dcor...@connx.com> wrote:
>
> > 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-A.../dp/0262531968
If you don't want to buy it, check it out from a library.

On Apr 10, 7:37 pm, istillsh...@gmail.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.

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

CBFalconer <cbfalconer@yahoo.com> writes:
[...]
> 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
catch some errors, but for me it's just not worth it.

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

On Apr 12, 4:38 am, CBFalconer <cbfalco...@yahoo.com> wrote:

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

CBFalconer <cbfalconer@yahoo.com> writes:

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

Richard wrote:

> CBFalconer <cbfalconer@yahoo.com> writes:
>
>> 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.

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

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

CBFalconer <cbfalconer@yahoo.com> wrote:

> 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 wrote:
> 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

--
Ian Collins.

Richard Bos said:

> CBFalconer <cbfalconer@yahoo.com> wrote:
>
>> 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

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:3-OdnSup3P-bvZ7VnZ2dnUVZ8smgnZ2d@bt.com...
> Richard Bos said:
>
>> CBFalconer <cbfalconer@yahoo.com> wrote:
>>
>>> 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?


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

--
Bart

Bartc said:

>
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:3-OdnSup3P-bvZ7VnZ2dnUVZ8smgnZ2d@bt.com...
>> Richard Bos said:
>>
>>> CBFalconer <cbfalconer@yahoo.com> wrote:
>>>
>>>> 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?
>
>
> Even with just the one break? And how else would you stop this fragment
> running forever:
>
> #define endlessloop while(1)

#undef endlessloop

And then I'd re-write the loop in accordance with my aesthetic prejudices.

--
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 Heathfield" <rjh@see.sig.invalid> wrote in message
news:3-OdnSup3P-bvZ7VnZ2dnUVZ8smgnZ2d@bt.com...
> Richard Bos said:
>
>> CBFalconer <cbfalconer@yahoo.com> wrote:
>>
>>> 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?


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

--
Bart

Bartc said:

>
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:3-OdnSup3P-bvZ7VnZ2dnUVZ8smgnZ2d@bt.com...
>> Richard Bos said:
>>
>>> CBFalconer <cbfalconer@yahoo.com> wrote:
>>>
>>>> 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?
>
>
> Even with just the one break? And how else would you stop this fragment
> running forever:

Same way I did last time.

--
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 Heathfield" <rjh@see.sig.invalid> wrote in message
news:3qOdnew-MNiG5J7VnZ2dnUVZ8trinZ2d@bt.com...
> Bartc said:
>
>>
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:3-OdnSup3P-bvZ7VnZ2dnUVZ8smgnZ2d@bt.com...
>>> Richard Bos said:
>>>
>>>> CBFalconer <cbfalconer@yahoo.com> wrote:
>>>>
>>>>> 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?
>>
>>
>> Even with just the one break? And how else would you stop this fragment
>> running forever:
>
> 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.

--
Bart

On Apr 11, 2:32 pm, user923005 <dcor...@connx.com> wrote:

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

On Apr 10, 5:37pm, istillsh...@gmail.com wrote:
> ...
> 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 fix bugs in other people's code, and both
of these 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

On Apr 14, 6:18pm, jxh@yahoo.com wrote:
> On Apr 10, 5:37pm, istillsh...@gmail.com wrote:
>
> > ...
> > 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 fix bugs in other people's code, and both
> of these 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?