The way to read STL source code

Discussion in 'C++' started by Stanley Rice, Feb 17, 2012.

  1. Stanley Rice

    Stanley Rice Guest

    I am familiar with using STL, including the algorithm and the
    containers,
    however, how they are implemented. Some of my friends recommend me to
    read
    the source code of STL directly.

    I download the SGI STL source code, which contains nearly 40 thousand
    lines. As far as I am concerned, it is a big project. And like other
    big
    projects, I have no ideas where to begin to start with, and what to do
    with
    it during the learning process.

    I am a ungraduate student, hoping some of you could give me some
    advice,
    and I will keep it up.

    Thanks in advance.
    Stanley Rice, Feb 17, 2012
    #1
    1. Advertising

  2. Stanley Rice <> wrote:
    > Some of my friends recommend me to read
    > the source code of STL directly.


    Really bad advice. You should read a good book about the standard
    library instead.

    (It's bad advice because reading someone else's uncommented and
    obfuscated code (the standard library is full of variables and names
    starting with __ which makes it hard to read) is one of the hardest
    ways of learning anything. You *could* potentially learn something,
    but if you value your time and sanity, there are much easier and
    efficient ways of doing that.)
    Juha Nieminen, Feb 17, 2012
    #2
    1. Advertising

  3. Stanley Rice

    Goran Guest

    On Feb 17, 8:18 am, Stanley Rice <> wrote:
    > I am familiar with using STL, including the algorithm and the
    > containers,
    > however, how they are implemented. Some of my friends recommend me to
    > read
    > the source code of STL directly.


    Reading is too dry. Try debugging through it. Start with the simplest
    of things, like for_each, vector::push_back, list::push_front. Just
    make simplest of programs, e.g.

    int main()
    {
    std::vector<char> v;
    v.push_back('a');
    }

    and go through with the debugger.

    In the beginning, it will be difficult, because you will need to learn
    to see through the cruft that's inside. Typically, you'll see a lot of
    code whose sole purpose is to aid debugging. You'll need to learn to
    ignore that. You will also see bizarre variable naming. Live with it.
    Variable naming in STL is subject to different considerations than
    your or mine code ;-).

    Goran.
    Goran, Feb 17, 2012
    #3
  4. Stanley Rice

    Stanley Rice Guest

    On Feb 17, 3:29 pm, Juha Nieminen <> wrote:
    > Stanley Rice <> wrote:
    > > Some of my friends recommend me to read
    > > the source code of STL directly.

    >
    >   Really bad advice. You should read a good book about the standard
    > library instead.


    There is a book name Standard C Library written by plaug, which is
    similar
    to the souce code of C library. But It seems that no book related with
    the
    source code of standary C++ libary is published as I know. By the
    way,
    can you recommend me some books that you consider is good.?

    >
    >   (It's bad advice because reading someone else's uncommented and
    > obfuscated code (the standard library is full of variables and names
    > starting with __ which makes it hard to read) is one of the hardest
    > ways of learning anything. You *could* potentially learn something,
    > but if you value your time and sanity, there are much easier and
    > efficient ways of doing that.)

    Maybe you are right though someone told me that it is a *good* way
    to learn some language by reading others' code. I am eager to know
    the easier and more efficient way to do that. Please.
    Stanley Rice, Feb 17, 2012
    #4
  5. On Feb 17, 7:29 am, Juha Nieminen <> wrote:
    > Stanley Rice <> wrote:


    > > Some of my friends recommend me to read
    > > the source code of STL directly.


    I don't think they are really your friends...

    >   Really bad advice. You should read a good book about the standard
    > library instead.


    Jossutis for instance. I'm not sure if there anything covering the
    latest standard.

    >   (It's bad advice because reading someone else's uncommented and
    > obfuscated code (the standard library is full of variables and names
    > starting with __ which makes it hard to read) is one of the hardest
    > ways of learning anything. You *could* potentially learn something,
    > but if you value your time and sanity, there are much easier and
    > efficient ways of doing that.)
    Nick Keighley, Feb 17, 2012
    #5
  6. On Feb 17, 8:56 am, Stanley Rice <> wrote:
    > On Feb 17, 3:29 pm, Juha Nieminen <> wrote:
    > > Stanley Rice <> wrote:


    > > > Some of my friends recommend me to read
    > > > the source code of STL directly.

    >
    > >   Really bad advice. You should read a good book about the standard
    > > library instead.

    >
    > There is a book name Standard C Library written by plaug[er], which is
    > similar to the souce code of C library.


    ITYM "similar to /a/ source code of C library"

    The point is neither C nor C++ have a model implementaion of the
    standard library. Tell your friends as they don't seem to be aware of
    this either.

    > But It seems that no book related with
    > the source code of standary C++ libary is published as I know.


    actually Plauger wrote one. But unfortunatly he anticipated the
    standard and they redesigned the library so obsoleting his book.

    > By the
    > way, can you recommend me some books that you consider is good.?


    Jossutis and "More Effective STL" (or something like that)

    > >   (It's bad advice because reading someone else's uncommented and
    > > obfuscated code (the standard library is full of variables and names
    > > starting with __ which makes it hard to read) is one of the hardest
    > > ways of learning anything. You *could* potentially learn something,
    > > but if you value your time and sanity, there are much easier and
    > > efficient ways of doing that.)

    >
    > Maybe you are right though someone told me that it is a *good* way
    > to learn some language by reading others' code. I am eager to know
    > the easier and more efficient way to do that. Please.


    but not the standard library. If you want to know what the library
    does read the documentation. There are some web sites around that
    aren't bad.
    Nick Keighley, Feb 17, 2012
    #6
  7. On Feb 17, 7:36 am, Goran <> wrote:
    > On Feb 17, 8:18 am, Stanley Rice <> wrote:
    >
    > > I am familiar with using STL, including the algorithm and the
    > > containers,
    > > however, how they are implemented. Some of my friends recommend me to
    > > read
    > > the source code of STL directly.

    >
    > Reading is too dry.


    nonsense!

    > Try debugging through it.


    yuck!

    > Start with the simplest
    > of things, like for_each, vector::push_back, list::push_front. Just
    > make simplest of programs, e.g.
    >
    > int main()
    > {
    >   std::vector<char> v;
    >   v.push_back('a');
    >
    > }
    >
    > and go through with the debugger.
    >
    > In the beginning, it will be difficult, because you will need to learn
    > to see through the cruft that's inside. Typically, you'll see a lot of
    > code whose sole purpose is to aid debugging. You'll need to learn to
    > ignore that. You will also see bizarre variable naming. Live with it.
    > Variable naming in STL is subject to different considerations than
    > your or mine code ;-).


    or you could try poking your own eyes out
    Nick Keighley, Feb 17, 2012
    #7
  8. Stanley Rice

    Goran Guest

    On Feb 17, 10:12 am, Nick Keighley <>
    wrote:
    > On Feb 17, 7:36 am, Goran <> wrote:
    >
    > > On Feb 17, 8:18 am, Stanley Rice <> wrote:

    >
    > > > I am familiar with using STL, including the algorithm and the
    > > > containers,
    > > > however, how they are implemented. Some of my friends recommend me to
    > > > read
    > > > the source code of STL directly.

    >
    > > Reading is too dry.

    >
    > nonsense!
    >
    > > Try debugging through it.

    >
    > yuck!
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > Start with the simplest
    > > of things, like for_each, vector::push_back, list::push_front. Just
    > > make simplest of programs, e.g.

    >
    > > int main()
    > > {
    > >   std::vector<char> v;
    > >   v.push_back('a');

    >
    > > }

    >
    > > and go through with the debugger.

    >
    > > In the beginning, it will be difficult, because you will need to learn
    > > to see through the cruft that's inside. Typically, you'll see a lot of
    > > code whose sole purpose is to aid debugging. You'll need to learn to
    > > ignore that. You will also see bizarre variable naming. Live with it.
    > > Variable naming in STL is subject to different considerations than
    > > your or mine code ;-).

    >
    > or you could try poking your own eyes out


    I find that watching code unroll in the debugger is a great way of
    learning what code does. Even more so when it's about usual STL
    implementations code.

    I don't get your excitement. It's not very elaborate either ;-).

    Goran.
    Goran, Feb 17, 2012
    #8
  9. Stanley Rice <> wrote:
    > someone told me that it is a *good* way
    > to learn some language by reading others' code.


    I don't understand where that misconception comes from. It's an extremely
    naive concept that is probably spouted mostly by people without actual
    expertise in programming.

    A program is the implementation of the solution to a problem. Seeing
    only the program, without any explanation of it, it's usually very hard
    to understand what exactly is the solution it's implementing, or even to
    which problem. If the program is well commented (which is an utter rarity)
    it might help some, but it's still hard.

    Even more importantly, a program is a *particular solution* to a more
    generic problem. You would be learning *that particular solution* rather
    than the generic principle behind it. This could, at worse, lead to
    cargo cult programming, where you blindly use a programming technique
    in situations where it's not at all well suited, without understanding
    the theory behind that particular solution.

    And this is all assuming that the program is good and competently made.
    That, in itself, is also a rare happenstance. If the program you are reading
    happens to be pure crap, you might be learning bad habits and the wrong ways
    of doing things. (Granted, the standard library is probably significantly
    more competently implemented than your average C++ program, but still.)
    Juha Nieminen, Feb 17, 2012
    #9
  10. On Feb 17, 11:57 am, Goran <> wrote:
    > On Feb 17, 10:12 am, Nick Keighley <>
    > > On Feb 17, 7:36 am, Goran <> wrote:
    > > > On Feb 17, 8:18 am, Stanley Rice <> wrote:



    > > > > I am familiar with using STL, including the algorithm and the
    > > > > containers, however, how they are implemented. Some of my friends
    > > > > recommend me to read the source code of STL directly.

    >
    > > > Reading is too dry.

    >
    > > nonsense!


    I misunderstood here. Since I think reading the STL code is so
    obviously mad I assumed you were saying "reading a book was too dry".
    But I see not. If I want to know what the STL does I read Jossutis. or
    use an online source.

    > > > Try debugging through it.

    >
    > > yuck!

    >
    > > > Start with the simplest
    > > > of things, like for_each, vector::push_back, list::push_front. Just
    > > > make simplest of programs, e.g.

    >
    > > > int main()
    > > > {
    > > >   std::vector<char> v;
    > > >   v.push_back('a');

    >
    > > > }

    >
    > > > and go through with the debugger.

    >
    > > > In the beginning, it will be difficult, because you will need to learn
    > > > to see through the cruft that's inside. Typically, you'll see a lot of
    > > > code whose sole purpose is to aid debugging. You'll need to learn to
    > > > ignore that. You will also see bizarre variable naming. Live with it.
    > > > Variable naming in STL is subject to different considerations than
    > > > your or mine code ;-).

    >
    > > or you could try poking your own eyes out


    it just seems a lot of pain ...cruft...bizzare variable naming... for
    very little gain.

    > I find that watching code unroll in the debugger is a great way of
    > learning what code does.


    I'm less enthusiastic. Very unenthusiastic in fact. And it doesn't
    help you learn what the STL /should/ be doing. Without reading some
    sort of documentation I don't see how you'd even know certain features
    existed.

    > Even more so when it's about usual STL
    > implementations code.


    even less is my thought. The STL is particularly ugly lookign code.
    Why do you care how it's implemented? Do you single shot through the C
    libraries? You probably do I suppose...

    > I don't get your excitement.


    what excitement?

    > It's not very elaborate either ;-).


    the STL? It's pretty subtle.
    Nick Keighley, Feb 17, 2012
    #10
  11. Stanley Rice

    Goran Guest

    On Feb 17, 2:15 pm, Nick Keighley <>
    wrote:
    > On Feb 17, 11:57 am, Goran <> wrote:
    >
    > > On Feb 17, 10:12 am, Nick Keighley <>
    > > > On Feb 17, 7:36 am, Goran <> wrote:
    > > > > On Feb 17, 8:18 am, Stanley Rice <> wrote:
    > > > > > I am familiar with using STL, including the algorithm and the
    > > > > > containers, however, how they are implemented. Some of my friends
    > > > > > recommend me to read the source code of STL directly.

    >
    > > > > Reading is too dry.

    >
    > > > nonsense!

    >
    > I misunderstood here. Since I think reading the STL code is so
    > obviously mad I assumed you were saying "reading a book was too dry".
    > But I see not. If I want to know what the STL does I read Jossutis. or
    > use an online source.
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > > > Try debugging through it.

    >
    > > > yuck!

    >
    > > > > Start with the simplest
    > > > > of things, like for_each, vector::push_back, list::push_front. Just
    > > > > make simplest of programs, e.g.

    >
    > > > > int main()
    > > > > {
    > > > >   std::vector<char> v;
    > > > >   v.push_back('a');

    >
    > > > > }

    >
    > > > > and go through with the debugger.

    >
    > > > > In the beginning, it will be difficult, because you will need to learn
    > > > > to see through the cruft that's inside. Typically, you'll see a lotof
    > > > > code whose sole purpose is to aid debugging. You'll need to learn to
    > > > > ignore that. You will also see bizarre variable naming. Live with it.
    > > > > Variable naming in STL is subject to different considerations than
    > > > > your or mine code ;-).

    >
    > > > or you could try poking your own eyes out

    >
    > it just seems a lot of pain ...cruft...bizzare variable naming... for
    > very little gain.
    >
    > > I find that watching code unroll in the debugger is a great way of
    > > learning what code does.

    >
    > I'm less enthusiastic. Very unenthusiastic in fact. And it doesn't
    > help you learn what the STL /should/ be doing. Without reading some
    > sort of documentation I don't see how you'd even know certain features
    > existed.


    From "how they are implemented" words of the OP, I took he wants to
    see how STL is implemented. Doc normally says nothing about that.

    >
    > > Even more so when it's about usual STL
    > > implementations code.

    >
    > even less is my thought. The STL is particularly ugly lookign code.
    > Why do you care how it's implemented? Do you single shot through the C
    > libraries? You probably do I suppose...


    Occasionally, yes. E.g. when I hit the problem I don't understand.

    >
    > > I don't get your excitement.

    >
    > what excitement?


    I interpreted e.g. "or you could try poking your own eyes out" as you
    being agitated about my post. "Excitement" was the wrong word.

    Goran.
    Goran, Feb 17, 2012
    #11
  12. Stanley Rice

    Jorgen Grahn Guest

    On Fri, 2012-02-17, Juha Nieminen wrote:
    > Stanley Rice <> wrote:
    >> someone told me that it is a *good* way
    >> to learn some language by reading others' code.

    >
    > I don't understand where that misconception comes from. It's an extremely
    > naive concept that is probably spouted mostly by people without actual
    > expertise in programming.


    To learn the language from scratch: yes. But do you also mean it's not
    useful to read others' code after a while, when you can write some
    small programs yourself? I can't agree with that.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Feb 17, 2012
    #12
  13. Jorgen Grahn <> wrote:
    > To learn the language from scratch: yes. But do you also mean it's not
    > useful to read others' code after a while, when you can write some
    > small programs yourself? I can't agree with that.


    Actually the more you know the language, the less you would even want
    to look at other people's code. Instead, what one ends up doing is reading
    tutorials, reference manuals and books on things like algorithms, data
    containers and design patterns. The only place you would look at someone
    else's code is in those tutorials (but usually in those the code is not
    a whole program, but just the relevant lines that demonstrate the thing
    being explained).

    If you ever need to look at someone else's code it usually means that
    you are tasked to maintaining/fixing/refactoring said code. That's like
    cleaning someone else's underwear by hand. Yuk.
    Juha Nieminen, Feb 17, 2012
    #13
  14. Stanley Rice

    Stanley Rice Guest

    On Friday, February 17, 2012 8:31:54 PM UTC+8, Juha Nieminen wrote:
    > Stanley Rice <> wrote:
    > > someone told me that it is a *good* way
    > > to learn some language by reading others' code.

    >
    > I don't understand where that misconception comes from. It's an extremely
    > naive concept that is probably spouted mostly by people without actual
    > expertise in programming.
    >

    But why there are so many people reading the Linux source code? Because
    there are lots of annotation about it? Lots of books explain it?

    I am not a native English speaker. Maybe the culture and the way teachers
    teaches make the difference. In the past, I learn to program by reading
    the books and others' demon, and then refer to the document. Yes, those
    programs are not big at all, and easy to understand, and the document can
    also explain it to me.

    But if you said that reading others' code is not the way to improve your
    programming skills, I have no ideas how to improve it. Reading the
    reference and manual just too boring to me, at least now. For example, some
    online resources explain every function of STL, I read it through but I
    don't konw when to use it. Even in my daily practice, the function can't
    jump into my mind. It seems that I learn nothing.

    While reading others' code, I will think why he use it some times, though
    he might use it in a not very good way.

    > A program is the implementation of the solution to a problem. Seeing
    > only the program, without any explanation of it, it's usually very hard
    > to understand what exactly is the solution it's implementing, or even to
    > which problem. If the program is well commented (which is an utter rarity)
    > it might help some, but it's still hard.
    >
    > Even more importantly, a program is a *particular solution* to a more
    > generic problem. You would be learning *that particular solution* rather
    > than the generic principle behind it. This could, at worse, lead to
    > cargo cult programming, where you blindly use a programming technique
    > in situations where it's not at all well suited, without understanding
    > the theory behind that particular solution.
    >
    > And this is all assuming that the program is good and competently made.
    > That, in itself, is also a rare happenstance. If the program you are reading
    > happens to be pure crap, you might be learning bad habits and the wrong ways
    > of doing things. (Granted, the standard library is probably significantly
    > more competently implemented than your average C++ program, but still.)
    Stanley Rice, Feb 18, 2012
    #14
  15. Stanley Rice

    Stanley Rice Guest

    On Friday, February 17, 2012 9:15:55 PM UTC+8, Nick Keighley wrote:
    > On Feb 17, 11:57 am, Goran <> wrote:
    > > On Feb 17, 10:12 am, Nick Keighley <>
    > > > On Feb 17, 7:36 am, Goran <> wrote:
    > > > > On Feb 17, 8:18 am, Stanley Rice <> wrote:

    >
    >
    > > > > > I am familiar with using STL, including the algorithm and the
    > > > > > containers, however, how they are implemented. Some of my friends
    > > > > > recommend me to read the source code of STL directly.

    > >
    > > > > Reading is too dry.

    > >
    > > > nonsense!

    >
    > I misunderstood here. Since I think reading the STL code is so
    > obviously mad I assumed you were saying "reading a book was too dry".
    > But I see not. If I want to know what the STL does I read Jossutis. or
    > use an online source.
    >
    > > > > Try debugging through it.

    > >
    > > > yuck!

    > >
    > > > > Start with the simplest
    > > > > of things, like for_each, vector::push_back, list::push_front. Just
    > > > > make simplest of programs, e.g.

    > >
    > > > > int main()
    > > > > {
    > > > >   std::vector<char> v;
    > > > >   v.push_back('a');

    > >
    > > > > }

    > >
    > > > > and go through with the debugger.

    > >
    > > > > In the beginning, it will be difficult, because you will need to learn
    > > > > to see through the cruft that's inside. Typically, you'll see a lotof
    > > > > code whose sole purpose is to aid debugging. You'll need to learn to
    > > > > ignore that. You will also see bizarre variable naming. Live with it.
    > > > > Variable naming in STL is subject to different considerations than
    > > > > your or mine code ;-).

    > >
    > > > or you could try poking your own eyes out

    >
    > it just seems a lot of pain ...cruft...bizzare variable naming... for
    > very little gain.
    >
    > > I find that watching code unroll in the debugger is a great way of
    > > learning what code does.

    >
    > I'm less enthusiastic. Very unenthusiastic in fact. And it doesn't
    > help you learn what the STL /should/ be doing. Without reading some
    > sort of documentation I don't see how you'd even know certain features
    > existed.
    >
    > > Even more so when it's about usual STL
    > > implementations code.

    >
    > even less is my thought. The STL is particularly ugly lookign code.
    > Why do you care how it's implemented? Do you single shot through the C
    > libraries? You probably do I suppose...

    Another reason that I want to read the source code is that I want to improve my understanding of data structure and algorithm in the same time. STL covers nearly all the basic data structure and algorithms.
    >
    > > I don't get your excitement.

    >
    > what excitement?
    >
    > > It's not very elaborate either ;-).

    >
    > the STL? It's pretty subtle.
    Stanley Rice, Feb 18, 2012
    #15
  16. Stanley Rice

    Ian Collins Guest

    On 02/18/12 01:55 PM, Stanley Rice wrote:
    > On Friday, February 17, 2012 8:31:54 PM UTC+8, Juha Nieminen wrote:
    >> Stanley Rice<> wrote:
    >>> someone told me that it is a *good* way
    >>> to learn some language by reading others' code.

    >>
    >> I don't understand where that misconception comes from. It's an extremely
    >> naive concept that is probably spouted mostly by people without actual
    >> expertise in programming.
    >>

    > But why there are so many people reading the Linux source code? Because
    > there are lots of annotation about it? Lots of books explain it?


    In the case of my last team, because there were lots of bugs to fix!

    mainly because of the need to be portable, library code is notoriously
    difficult to read.

    Your time would be better spent reading a decent book such as "The C++
    Standard Library: A Tutorial and Reference" by Nicolai M. Josuttis

    http://www.amazon.com/Standard-Library-Tutorial-Reference/dp/0201379260

    > I am not a native English speaker. Maybe the culture and the way teachers
    > teaches make the difference. In the past, I learn to program by reading
    > the books and others' demon, and then refer to the document. Yes, those
    > programs are not big at all, and easy to understand, and the document can
    > also explain it to me.


    But what you probably won't find is documentation for a standard
    library's source.

    > But if you said that reading others' code is not the way to improve your
    > programming skills, I have no ideas how to improve it. Reading the
    > reference and manual just too boring to me, at least now. For example, some
    > online resources explain every function of STL, I read it through but I
    > don't konw when to use it. Even in my daily practice, the function can't
    > jump into my mind. It seems that I learn nothing.


    Reading well documented code can improve your programming skills.

    --
    Ian Collins
    Ian Collins, Feb 18, 2012
    #16
  17. Stanley Rice

    Stefan Ram Guest

    Learning to code by reading code (was: The way to read STL source code)

    Newsgroups: comp.lang.c++,comp.lang.misc
    Followup-To: comp.lang.misc

    Stanley Rice <> writes:
    >But if you said that reading others' code is not the way to improve your
    >programming skills, I have no ideas how to improve it. Reading the


    Reading others' code /is/ the way to improve the skills:

    - Of course, one should select code written by masters,
    not code written by arbitrary authors. For example,
    in the realm of C++, one might read boost source code.
    In the realm of C, source code for GNU commands.
    For Java, read the source code of the standard library.
    In the realm of Pascal, "TeX - the program". And so on.

    - A good way to enforce active reading is a goal, like
    porting the code or modifying it.

    - Reading masters' code must, of course, not be all that
    one does. One also has to read books and do other
    programming exercises. Reading masters' code might
    comprise, for example, 20 % of all programming activities.

    Newsgroups: comp.lang.c++,comp.lang.misc
    Followup-To: comp.lang.misc
    Stefan Ram, Feb 18, 2012
    #17
  18. Re: Learning to code by reading code (was: The way to read STL source code)

    "Stefan Ram" <-berlin.de> wrote in message
    news:-berlin.de...
    > Newsgroups: comp.lang.c++,comp.lang.misc
    > Followup-To: comp.lang.misc
    >


    I put comp.lang.c++ back on. Mr. Rice makes some wildly incorrect
    assumptions, IMO. Hopefully, it'll also end up indexed in the correct
    thread on c.l.c++.

    > Stanley Rice <> writes:
    > >But if you said that reading others' code is not the way to improve your
    > >programming skills, I have no ideas how to improve it. Reading the

    >
    > Reading others' code /is/ the way to improve the skills:
    >


    Wrong! Wrong! Wrong! Freakin' wrong!

    Reading others' code only exposes one to the inherent flaws of thinking and
    bad code implementation others, which one - especially the novice,
    inexperienced, or average intellect - then accepts as their own - since the
    code different, perhaps novel, and therefore *must* be better (sarcasm) -
    because they don't yet understand just how truly *bad* the idea they're
    reading is. Reading other's code is one of the absolute worst things one
    could do, especially for a novice who is one likely to be very accepting
    when reading others' code. It's like taking pure water (you) and drinking
    polluted river water (others) and ending up with a mix.

    > - Of course, one should select code written by masters,
    > not code written by arbitrary authors.


    Just how does one judge a master? If you aren't a master yourself, you
    can't judge who is a master ...

    That entire idea is so flawed. A guy with average intellect will only
    recognize a range of intellect similar to his own. He'll recognize that
    which is slightly more or less bright than he, but won't recognize dumb and
    genius level ideas as such. So, a guy with less than average intellect will
    recognize the code by an average intellect guy as being a "master". The
    majority - who are supposedly of average intellect - will be scratching
    their heads in confusion asking: "Why does this guy think that guy is a
    master? That guy's code is no better than my own ... I don't get it." The
    same is true for the average guy, the slightly above average guy, the
    brilliant guy, the genius guy. It's only partially true for the
    super-genius guy who will only recognize code worse than his own ... So, in
    effect, you're saying one needs to locate super-genius guy and have him
    waste his time reviewing code to classify who is and who is not a master
    before anyone can study the other "masters".

    > For example,
    > in the realm of C++, one might read boost source code.
    > In the realm of C, source code for GNU commands.
    > For Java, read the source code of the standard library.
    > In the realm of Pascal, "TeX - the program". And so on.


    I doubt any of the code produced by the open-source movement could be
    classified as "being written by masters". There are too many people with
    *widely* varying intellect levels, most of whom are only of average
    intellect, to claim that the cited code in it's entirety is somehow
    brilliant. For the code to be brilliant, a single brilliant individual
    must've coded it or a team of similarly brilliant individuals must've coded
    it. Both of those are things which were unlikely to be present during the
    codeing of any of the code you've suggested as being "master" level.

    > - A good way to enforce active reading is a goal, like
    > porting the code or modifying it.


    The way to improve your code is not by reading others' code, but by 1)
    really learning what elements the language provides, 2) writing your own
    code using the language elements, and 3) learning how that language is
    converted to assembly. You can read about implementing something, say a
    linked-list, numerous times, but until you've actually done so, you won't be
    able to identify and correct your own mistakes of implementation or of your
    thought process, which will happen no matter how good your memory or
    thinking is.


    Rod Pemberton
    Rod Pemberton, Feb 19, 2012
    #18
  19. Stanley Rice

    Stefan Ram Guest

    Re: Learning to code by reading code

    "Rod Pemberton" <> writes:
    >The way to improve your code is not by reading others' code


    But we should not forget that there are more man-hours in
    maintenance programming than in programming a new program
    from scratch. That means the typical work day of a
    programmer is not writing his own code (as you wrote »your
    code« above), but maintaining code written by someone else.
    And the first step to do this properly is to read and to
    understand that code that is to be modified. So, training to
    read code also is just a preparation for the very activity
    that will most often be exercised when being a programmer.
    Stefan Ram, Feb 19, 2012
    #19
  20. Stanley Rice

    Stefan Ram Guest

    Re: Learning to code by reading code

    "Rod Pemberton" <> writes:
    >Reading others' code only exposes one to the inherent flaws of thinking and


    The same could be said about reading a programming book.

    >Just how does one judge a master? If you aren't a master yourself, you


    The same could be said about judging a programming book.
    (Macchiavelli wrote about this, see the last paragraph in

    http://ebooks.adelaide.edu.au/m/machiavelli/niccolo/m149p/chapter23.html

    )


    >That entire idea is so flawed. A guy with average intellect will only
    >recognize a range of intellect similar to his own. He'll recognize that


    Yes. This means that a person with an above-the-average
    intellect will perform better. But this is a general
    principle, it does not apply to reading source code only.
    However, one might critize the implied assumption that the
    intellect is something fixed, see

    http://en.wikipedia.org/wiki/Mindset_(book)
    Stefan Ram, Feb 19, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Cloud Burst
    Replies:
    11
    Views:
    1,011
  2. abi

    STL source code

    abi, Sep 3, 2003, in forum: C++
    Replies:
    4
    Views:
    2,154
    John Harrison
    Sep 4, 2003
  3. Allan Bruce

    To STL or not to STL

    Allan Bruce, Oct 16, 2003, in forum: C++
    Replies:
    41
    Views:
    1,012
    Christopher Benson-Manica
    Oct 17, 2003
  4. Replies:
    4
    Views:
    783
    Daniel T.
    Feb 16, 2006
  5. Peyman
    Replies:
    4
    Views:
    570
    mlimber
    Oct 31, 2006
Loading...

Share This Page