The best way to read a OO code?

[the3rdStorm]

This might be a dumb question. But I wanna advices from you guys.
When I find a complicate and interweaved OO code, what's the best way to read it?:

1. Go directly to the main() and go along each of the function calls through classes and structs?
2. Start from the very beginning and read down and back-to-back files until I reach the final one?
3. Another method?

Thanks for your interest.
Have a nice day.

[Andreas Masur]

[Moved thread]

[Andreas Masur]

Well...there are many ways of doing it, and I guess nearly everybody has his/her own preferred way of doing it...

Nevertheless, object-oriented programming is - as the name indicates - about objects which interact which each other. Thus, I usually start by looking at the different objects (classes) to get the understanding what the purpose of each one is. After getting the complete overview over all the classes, it is simply a matter of following the program flow ('main()')... :cool:

[Sam Hobbs]

Programs can be written that supposedly use object-oriented methodology but that are in fact poorly written. If a program is difficult to understand, then it probably is not written well and probably does not use good object-oriented design. I am not familiar with object-oriented design very much but I assume use of it will result in a program that is as easy to understand as possible.

Regardlous of how well a program is written, you might need to just spend time studying it. For a complicated program, such as a reconciler of engineering and manufacturing parts lists, you might even need to execute it with some test data and maybe put some debugging types of code in it to determine it's flow and such. However the specifics of what you do often depends on the program. For a complicated program, you might have to struggel for a week or two before you begin to understand. Then it might take another week or two to determine how to modify it. At some time you are likely to feel very confused, and that is the point that separates the real programmers from the semi-programmers. If you are sufficiently stubborn (persistent) you will take a break when you get that feeling but you won't let it defeat you. You don't give up and instead you return to the battle and defeat it.

[Kheun]

Well... coding reading is implicitly part of the job description for programmer. This book, Code Reading (http://www.amazon.com/exec/obidos/tg/detail/-/0201799405/qid=1078712476/sr=1-1/ref=sr_1_1/102-1548351-5071355?v=glance&s=books) by Diomidis Spinellis, might be helpful. It tells you the do's and don'ts, what works and why.

[Mick]

fire up a debugger, walk through it, fix all the stuff teh original coder didn't think of...

/never fails.
//Your eyes will betray you if your walking through complex code <not just a couple of modules> outside of a debugger.l

[Sam Hobbs]

Originally posted by Kheun
Well... coding reading is implicitly part of the job description for programmer. This book, Code Reading (http://www.amazon.com/exec/obidos/tg/detail/-/0201799405/qid=1078712476/sr=1-1/ref=sr_1_1/102-1548351-5071355?v=glance&s=books) by Diomidis Spinellis, might be helpful. It tells you the do's and don'ts, what works and why. I would be surprised if a book had anything significant to say that a good programmer would not think of on their own.

[Kheun]

Originally posted by Sam Hobbs
I would be surprised if a book had anything significant to say that a good programmer would not think of on their own. No, please don't take it wrongly. I didn't mean that. Looking at a different perspective, it teaches new programmer on how to write effective and clear code at a shorter time. It may even be valuable for experienced programmer.

[Mick]

Originally posted by Kheun
No, please don't take it wrongly. I didn't mean that. Looking at a different perspective, it teaches new programmer on how to write effective and clear code at a shorter time. It may even be valuable for experienced programmer.

teaching the pitfalls and wisdom (dice roll please) is never a bad idea.