how important is it to read other peoples code?

[buckED]

Hello everyone.

The topic says it all I guess.

Well to give you a bit of a background. I have lately been downloading and trying a whole load of different libraries, which I consider using in a project of mine. For now it is no more than a vague Idea floating around somewhere within the creative juices in my brain.
These libraries are all great and I really appreciate that people have done that work in order to share it with others like me, who have less of an understanding of the subject these libraries adress.

One thing I really enjoy about it, is that these people give me a pretty easy interface most of the time, so I don't have to care about the interior of the libs I am using.
On the other hand however, this is exactly the thing that bothers me about it.
Can I use other people's code efficiently, without knowing what it looks like under the hood? This is the purpose of Object oriented programming after all, isn't it?
Plus I might need special functionality that the author of the library has not implemented. A thorough understanding of his code would be necessery in this case in order to adjust the library's functionallity according to my wishes.

And that is where the trouble begins. I tend to be very bad at reading other peoples code. At least when there are no lengthy explanations like on the wiki and when it gets longer than a few lines. (which it rarely is on the wiki either.)
It is even worse. Code which I did not write scares me somehow.
I have never even attampted to have a proper look at ogre's code for instance. Even though Ogre has a great documantation I sometimes feel the wish to know more about certain parts. I do not want to adress the forums everytime I happen to run into an issue which I cannot solve directly by looking at the wiki.
(Of course I love the ogre community. The forums are great and people tend to answer each of my questions very competently. It is just that I don't want to go on anyone's nerves )

It is my understanding that reading the code would be the best way to solve each and every problem, as one would not only know what to do (as you would by looking it up in the forums/wiki), but as well why you do this specific thing.

But as I said. When I open a project and the first thing that comes upon me is a wall of macros (I am not saying this is the case with Ogre... never really looked at it) I tend to loose all motivation to keep going.

Another thing is wrapper libraries. I like the fact that things are made as easy as possible for me. But again, if I really had the desperate need to adress a very specific part of the wrapped class I would be more or less lost at this point.

I feel like using interfaces and not knowing what's beyond makes me kind of dumb and inflexible.

One last point I'd like to mention. Often enough it is a small thing I want to solve, but searching for a certain class leads to a run up an incredibly long inheritence ladder, throwing in tons of other classes and functions, which seem to be there only for one purpose... confusing me

So the question is, how would one best go about finding very specific things without having to read ALL the code.


Ok. I could certainly keep going like this for hours. But that would not do me any good and would certainly only discourage people from reading the whole thing.

So let me summarize and finally put my questions:

Other people's code is a great thing to have (especially for free),
as they have already done most of the "dirty" work for you. Sometimes however one feels the desire or the need to actually understand what this dirty work looks like.
Other people's code is often enough a scary thing as well when you attempt to understand it. This is even more true for a C++ novice like myself.

So, does one really need to understand it? How deeply does one generally have to dig into it? Is it recommendable (even if applicable) to use it without EVER knowng what exactly it does.

When you read the code of others, how do you go about it. Just dive in with the class you want explained and then do it the hard way, gathering the bits and pieces as you go? Or do you do it more organised? (API references come to mind)

I am pretty well aware that I do not need to understand every little detail of the libs I am using. That's what they were created for after all.
However I often feel like missing something when I just dumbly obey to there rules without ever questionning, let alone understanding them.
Sure I do not need to know how exactly a car works to use it for my purposes. I just need to understand the interface.
But then again, I am not intending to build or modify my car (in which case I would need to know some if not all of the details).
Hope this metaphor (is it a metaphor? ) Helps a bit in clearing up what this whole thing is about.

To anyone who had the patience to read that monster of a text. If you still have enough power left to write something helpful, you are highly encouraged to do so.

Thanks,
Ed.

[jacmoe]

To anyone who had the patience to read that monster of a text. If you still have enough power left to write something helpful, you are highly encouraged to do so.

I am almost powerless!

If you're just starting out, don't worry about the code behind the nice interfaces. Just code along and adopt.

It will gradually become easier and easier to browse and grok other peoples code.
You really can't help doing it after a while.
And you'll understand more and more of it. Eventually.

[Azgur]

I'd say, a library is a good library if people don't have to read your code.
If your interfaces are clear and your documentation is sufficient, you never should have to dive into the code.
You can read the code if you want to, but you never should be forced to.

It would sort of defeat the purpose. You want to save time, not end up wasting time reading code

[mr. iknoweverything]

let's put it this way: if even the allmighty Knuth (http://en.wikipedia.org/wiki/Donald_knuth) sees the necessity for a language like CWEB (http://en.wikipedia.org/wiki/CWEB), you're in good company.
[/url]

[ajs15822]

This is a little like asking if professional singers listen to other singers, to which I reply, emphatically, yes! If you wish to be a competitive, competent programmer, it is absolutely necessary for you to regularly read other people's code!

I'm never satisfied with just reading the API of a library-- I always, given that the source code is provided, dive in and trace most of it's execution from beginning to end. Besides gaining an in-depth understanding of how best to use the library, I'm able to answer the questions "How does it work?", "Can I apply any of what I learned to improving my own code?", and "Can I make this library better?".

Don't be afraid of other people's code-- you just need to understand how to analyze it. Start by asking yourself "What is their motivation for writing this-- what are they trying to do?", from there, as you read each class, member function, and utility function, you should be looking for relationships, "What calls what? What uses this variable? How does this function fit into the big picture?". After a little practice (and a little help from debug tracing), you'll find that analyzing even the most monolithic pieces of code is quite simple by thinking in terms of goals and relationships.

[Klaim]

aj++

I'll add that reading other's code is maybe the hardest basic skill for a programmer, so it's the one you should train when you can to better understand the rest of your skills (like writing the code for the others).

[jacmoe]

Yeah, yeah..
But don't despair when you don't understand what's going on.
That's normal.
I agree that it is a must have skill, but it is one you develop as you go. An important skill, yes. But it's perfectly fine to treat it like a black box for starters.

[mr. iknoweverything]

it s not even a skill, its simply hard by definition. i mean, after all, the code is condensed contemplation. you know, a single line of code might look simple, but that shouldnt fool you into thinking it is. sigh, i dont want to think about how much thinking can be sunk into writing just a few lines of code, even less how hard it will be to read it. thats why its important to comment. comment. comment. comment a lot. and then comment again.
thats why i dig the CWEB idea. properly and easily understandable code should look like a text book: lots of text, then a bit of code, lots of text. but thats just my, quite utopic, opinion.

[enligor]

Absolutely agree with what has already been said.
And just my 2cents to add - try disassembling compiled executables, when not only do you not have any comments, but not even the idea of what the hell is going on, and once you'll get used to it - reading other's code will be a charm! Well, just don't get any foolish ideas about understanding the entire Linux kernel source code...

[buckED]

"Can I apply any of what I learned to improving my own code?"

Yeah that is something I had in mind as well when I started this thread. Must have forgotten to write it down however

[Klaim]

jacmoe> Agreed!

[buckED]

Ok. From what I have read so far I understand that I should read other people's source code from time to time, but shall not push myself to do it, if no need be.

Thanks to everyone for all that input.

Now there is still the question of how one would best go about it.
ajs already gave his opinion on that and it sounds like a good way to go.

However I would like to hear more and get to know other peoples standpoint.

Assume we have a free library. It is absolutely kickass and from it's feature list is just mindblowing. However documantation is rare and hard to find. How would you go about reading the source code.

[Minthos]

As one who is facing much of the same worries, I can only suggest starting small (the tiniest library or the most trivial program you can find). Smaller program means less code to get confused by. And by small I mean really small. Any library that you might find useful is probably way too big.

[JohnJ]

First of all, IMO:
- A good library will document all you need to know to use it without looking into the code - in other words, detailed descriptions and information about performance (like which function is slow, fast, etc.)
- A good library is written well enough that if you need to, the code is easy to understand at a glance, with well named variables/function/etc. and comments clarifying when necessary

Unfortunately, many libraries are poorly documented, and difficult to read the code.

Fortunately Ogre and other really good libraries are generally well written and documented, and aren't very difficult to work with. When you need to look at the underlying code, it's usually not too hard once you get used to it. Don't be afraid of trying to decode it based on bad experiences with poorly written code. But also don't try to understand every detail and line of code of every library you use, because you'd never get anything else done

I think the ability to read others code isn't so much an ability you can learn, but more a responsibility for the programmers to write readable code. For example I sometimes have to work with code with hundreds of global variables named things like "dwtr". I don't think any amount of "reading skill" will help you decode what bad code does, as long as you understand the syntax and style of C++/C, all you can do is use common sense and (sometimes) a lot of tedious tracing and code searching.

[jacmoe]

Well put, JohnJ