Ask Slashdot: How To Start Reading Other's Code? 254
BorgeStrand writes "I'm reviving an open source project and need to read up on a lot of existing code written by others. What are your tricks for quickly getting to grips with code written by others? The project is written in C++ using several APIs which are unknown to me. I know embedded C pretty well, so both the syntax, the APIs and the general functionality are things I wish to explore before I can contribute to the project."
Test and Break (Score:4, Insightful)
Re: (Score:3, Funny)
If there's a lot of documentation, interpret it like your favorite religious text. Try to hit up some of the old developers from the VCS. :)
Also, I'd like to help
The Great Programmer commanded his bytes to carry their bugs to the bitstream and drown them, or 7 years of seg faulting would follow.
Join the Church of Emacs today!
Re:Test and Break (Score:5, Funny)
Re: (Score:3)
And lo, yea though ye shifteth right 8 bits, counteth not thy sign as verily carried henceforth unto the int8_t.
16 bits is right out.
Re: (Score:3)
If there's a lot of documentation, interpret it like your favorite religious text.
So it's got some pretty good ideas, but nobody really pays attention to what it says?
Describes the documentation for most projects I've worked on.
Re: (Score:2)
Unfortunately the OP doesn't say how much code there is. Understanding 10K lines by reading the source code is feasible; doing so for 1M lines isn't. Documentation is of some use, but it's typically scant and years out of date. Really, the best guide is an explanation given by someone who already knows the codebase.
A good way to proceed here is to spend a bit of time digging around the codebase by yourself, write up a proposal for some significant impro
Re:Test and Break (Score:5, Informative)
Also, vowels apparently used to be very expensive in C variable names "back in the day."
Certain early C implementations would only use the first 8 characters of a variable name. At that point, the vowels are usually the most expendable when coming up with names.
Re: (Score:3)
Back in the day, it was the current 'fashion' to remove vowels as a method of shortening variable names.
Later on, it was determined that simply truncating longer words was actually significantly more readable.
Start with the headers (Score:5, Insightful)
Knowing the data structures gives you the ground work for understanding what the code is doing. The data structures are a more direct description of the design decisions.
Re:Start with the headers (Score:4, Insightful)
Knowing the data structures gives you the ground work for understanding what the code is doing. The data structures are a more direct description of the design decisions.
This approach assumes the programmer hasn't gone native. Great for managed code, but when the data structures are basically pointers being passed back and forth and calls to APIs deep in the guts of the OS... well, how do I put this: You're screwed. It's a crap shoot on if the programmer even knows why it works... sometimes in C++ you stop debugging the moment it starts returning sane outputs and consider yourself lucky you didn't have to fully grok wtf just happened. :/
Re: (Score:2)
well the headers are a way to learn what the pointers are pointing to...
using os libs isn't always referred as going native though.
here's a tip though, use an editor that lets you quickly jump to the definition of a thing(function, struct, whatever). it speeds up things a lot. even if you just end up in a header for some native lib you don't have the source for and that is uncommented.
Re:Start with the headers (Score:4, Interesting)
I maintain a huge C++ codebase written by someone else. Pointers are no problem at all. The structures and classes they point to are all defined somewhere. The problem is, after loads of features tacked on randomly, the code has become unmaintainable. Core features break other core features and ugly hacks abound. Also Microsoft's OLE library breacks because the original coder did some extreme use case things that expose a long unfixed bug in modern OLE32.dll libraries. Working with code like this leads to the conclusion, that once understood, sometimes it is better to reimplement the whole thing building in all the core functionality from the base.
This has been my practical experience with fairly well written C++ code. Comming from an embedded angle, there should be no problem understanding what the code does, or the data it works on, but maintaining or extending it may be a lost cause.
Re: (Score:2)
Interesting. I was actually thinking of the infamous case when a US Navy ship running Windows NT had to be towed to port.
Re: (Score:3)
Re: (Score:2)
You certainly would expect that a similar system was set up on land first.
The latest thing a sailor is expecting that his ship loses power due to a computer failure.
Even less on a warship!
Re: (Score:3)
So, the end result was the ship NOT running Windows NT?
Maybe. (Score:3)
Re: (Score:3, Funny)
That's when you start reading tea leaves.
Well, at least that's better than reading JavaBeans...
Re:Maybe. (Score:4, Informative)
How to read code (Score:5, Insightful)
What are your tricks for quickly getting to grips with code written by others?
For me, it comes down to a lot of mountain dew, techno music, and hours of guru meditation. As you dissect each function, sketch out its relationship to other major functions. I take a two pass approach .. first, just look at the function call outs and the return values and make a rough sketch of the 'scaffolding' of a program. On the second pass, any function that you can't see the obvious application of, or appears obfusciated or complicated, dissect into functional units and sketch out what it does in your notes. I do this by actually physically drawing the relationships using something called a mind map.
Until you get used to it, actually writing it down, even if it's just a bunch of messy arrows to blobs of circled text... it will help job your memory and help things sink in until you have the necessary 'ah ha!' moment.
YMMV.
Re:How to read code (Score:4, Informative)
For me, if I can't understand code written by someone else (which happens much more frequently than I care to admit), I'll do a spike and I'll try to rewrite the core functionality from scratch. Now don't get me wrong. This doesn't mean that my code will be half as good as the original implementation, in fact, it won't be for sure, since I won't spend much time on it. For me, that exercise is just a way for me to initially orient myself (and I do not keep the code I write during that phase).
If I'm lucky enough to have a good original version history of the code base, I'll go and pull up the original 0.1 version of the code (while I'm doing my own rewrite). Even if that version of the code is completely wrong. It still has a much higher chance of being something I'll understand. And then, I'll have a better understanding of what the developers were trying to do in the subsequent evolution of the project. Then, I'll isolate the parts of the latest code base I can safely break without breaking the entire thing, and I'll focus on those parts first.
Of course, during that next phase, I'd like to say I write unit-tests for the parts I modify before I modify them, but that's usually not how I work. I'll often have to fall down flat on my face a couple of times, cry in pain and frustration, and tear my hair out, before I'm willing give up and go back to doing things properly with unit tests. This does happen quite frequently, because I never seem to learn my lesson.
And of course, like someone else said already, I will also draw all kinds of mind maps and doodles throughout the entire process. And also, if I have access to one of the original developers who wrote the code, that's even better. If I can pair program with one of those persons, that's the ideal. If I can't, then talking to that person is the second best alternative. That person will be the best person to know all the weak points of his code base, give you a thumbnail overview of the architecture, and he will also be the best person to point out what parts you can work on first (so that you can gain confidence and a gradual understanding) that are the least likely to break the entire thing.
Re: (Score:2)
For me, if I can't understand code written by someone else (which happens much more frequently than I care to admit), I'll do a spike and I'll try to rewrite the core functionality from scratch. Now don't get me wrong. This doesn't mean that my code will be half as good as the original implementation, in fact, it won't be for sure, since I won't spend much time on it. For me, that exercise is just a way for me to initially orient myself (and I do not keep the code I write during that phase).
This is especially helpful in understanding some of the "Why the hell did he do it like THAT?" questions you get when reading someone else's code. Sometimes it's because the original developer was an idiot, but very often it's because you haven't fully grasped part of the problem yet. Or as I like to put in when I need to communicate in cliche-esque speak, "It's a lot easier to appreciate a round wheel when you've built a square one."
Re:How to read code (Score:5, Informative)
Are there tools that do this automatically?
Have a look at Scitools Understand [scitools.com].
Since this is an OSS project ... (Score:5, Interesting)
Since this is an OSS project, can you suggest any tools similar to Understand that don't cost $995?
The only thing I could find was source navigator NG [berlios.de], but I have zero experience with it.
CCVisu (Score:3, Informative)
You can use doxygen to create a dependency graph and visualize it using CCVisu.
http://www.stack.nl/~dimitri/doxygen/
http://ccvisu.sosy-lab.org/
http://ccvisu.sosy-lab.org/manual/main.html#sec:input-dox
Re: (Score:2)
source navigator still works OK. doxygen can provide reasonable callgraphs (especially for C). DXR has improved dramatically recently---it's not just for Mozilla now. DXR requires the code to be compilable by clang, but doing whatever's necessary for that might be a useful exercise.
Re: (Score:3)
Honestly, I wouldn't get too comfortable with a given IDE -- some of them (I'm looking at you, Visual Studio) abstract away and hide a lot of the code and it can make for some really confusing times for you. Just open up the raw .c or .cpp files with whatever is comfortable... anything with color coded formatting... and then just sit back and try to absorb it without any preconceptions.
Can you elaborate on that? I haven't seen Visual Studio hiding any code.
Re: (Score:2)
Can you elaborate on that? I haven't seen Visual Studio hiding any code.
Mostly the initialization routines. In the old days, it would have been called winmain() and it would do all kinds of (pretty standard) initializations before regurgitating a useful handle to a window that you'd then nail the rest of your code to. It can also be frustrating when it derps on some dependency and you have to go searching for the right reference to add. When it derps hardcore, it won't even display the full IDE, spitting out a clusterfuck of errors over something you deleted but forgot to remov
Re:How to read code (Score:5, Insightful)
Honestly, I wouldn't get too comfortable with a given IDE -- some of them (I'm looking at you, Visual Studio) abstract away and hide a lot of the code and it can make for some really confusing times for you.
Honestly, I would take more time to get comfortable with a given IDE so you can actually use it well instead of feebly. A good IDE like Visual Studio rarely abstracts away anything that you aren't trying to abstract away. And since most of the time you want almost every part of your program to be abstracted away from you, ,which is most of the power of a good IDE, this is what makes an IDE so useful.
Not being competent with a good IDE is far worse than not completely grepping your coding environment at a low level. At least in today's world (I had a different opionion 15 years ago). Google and coworkers can fill in a lot of gaps in knowledge when necessary, but spending day in day out using an IDE and never realizing how much better it is than command line tools is a big waste of productivity.
The only way (Score:2, Funny)
Look straight at the code for a few hours without moving an inch. After that its details should be printed into your brain.
Unit Tests (Score:5, Informative)
If possible, I would try writing unit tests for the existing code. This tests your understanding of what you are reading and will come in handy later if you change the code. If unit tests already exist then I suggest that you read them since they will tell you the intention of each function.
Re:Unit Tests (Score:5, Insightful)
This. Looking at existing tests is also very educational. They often show where the codebase was confusing enough to cause recurring regressions.
The other place to make very, very sure to read is the repository commit logs, if you have them. They'll tell you a lot about why the code is in its current state, and will often show you where refactors have been left half-complete.
Re: (Score:3)
If possible, I would try writing unit tests for the existing code. This tests your understanding of what you are reading and will come in handy later if you change the code. If unit tests already exist then I suggest that you read them since they will tell you the intention of each function.
Unit tests are a lot like documentation: they will tell you what the code is _expected_ to do. (Not what the code actually _will_ do, especially in corner cases). Thus, if you are already digging in to see what any section of code is doing, document what you've found: write a unit test.
Re:Unit Tests (Score:5, Insightful)
No, unit tests are a good idea. They wouldn't be my first choice, but they're a good option when deciphering a particularly difficult project.
(1) It gets you to interact with the code. This is always a good idea when leaning how something behaves. Fiddle with it for a while and see if you can figure it out.
(2) The unit tests don't need to be particularly true to their original requirements to be useful. When you do eventually start making changes, the law-of-unintended-consequences comes into play. If you make a change and one of your unit tests starts failing, then it will give you a clue that things may be interacting in a way that you did not anticipate.
Read someone elses Perl code first (Score:5, Funny)
Re: (Score:2)
Everything else will seem simple after that...
Everything? I doubt [wikipedia.org] it.
Re: (Score:3)
Better yet, read your own 3 year old Perl code. Everything else will seem simple after that...
Re: (Score:3)
I can vouch for this.
Reading old Python? Easy. Reading old C? Easy. Even reading old C++? Not too bad.
But... reading old Perl after a break from the language? I need to go re-learn the language, find out what all the obscure special variables do, do a complete refresh on regular expressions (remember when that was how people routinely parsed text? omg/lol), re-learn the broken parts (like, no 2D or higher arrays) and how the work-arounds look, and that only *preps* you to read the old code... it's still lik
Re: (Score:3)
Re: (Score:3)
Somewhere, I have a coffee cup that says CRS on it in large letters, and underneath reveals this to stand for "Can't Remember Shit"
I love that cup. Wish I knew where it was.
Doxygen (Score:5, Informative)
Even without Doxygen's specific format for comments, you can use it to graph object relationships, call-trees, etc.
You can generate docs limited to a few files or classes if you just want to focus on them.
www.doxygen.org
Re: (Score:2)
Well what do you expect? Lazy programmers focussed strictly on functional components result in comments that are useless 99.9% of the time. GIGO. Have someone go in and incorporate decent documentation into at least your top-level comments and doxygen will collect them into reasonably well organized hyperlinked documentation that can be easily kept up to date by simply updating the comments when the associated code changes. Of course nobody will bother to do that so it will rapidly become useless again,
pretend you are the computer (Score:4, Informative)
Reformat, Reformat, Reformat (Score:5, Insightful)
I find that going through some key functions (assuming you can find them) and reformatting them to your own liking can be helpful, commenting code along the way. Then if you want to get more aggressive, start cleaning up some code in minor ways that still stay true to the function's meaning. After you've done a bit of that, you should probably have at least a vague idea what's going on.
Re: refactor, discard, repeat (Score:5, Interesting)
Find a function. Refactor it until you grok it. Discard the results.
Keep in mind that it will be VERY tempting to commit your changes, but you must throw away the work and chalk it up as a learning experience if you ever want to be taken seriously by the others who work on the project. Junior developers (and even some senior developers) often think they're doing everyone a favor by doing drive-by refactors, but they're not; they're just slowing down the entire team and coming across as that a**hole who keeps f***ing up the diffs and destroying the useful output of tools like git blame.
If you found any bugs in the previous step, make a patch with the absolute minimal change to fix each individual bug. IMPORTANT: Before committing the patch, first be sure that you can reproduce it in the old code, and that the test case is fixed by your new code.
Repeat the process until you understand the entire system.
With any luck, you will finish with a solid understanding of how the code actually works, and you will most likely also fix a few dozen bugs (if you didn't find at least one bug per kLOC, then "you're doing it wrong" or the code was written by an inspired genius with OCD). At that point, you will be the team's expert on how things work, and you will be in a position where you can start proposing simple refactorings that will improve the code quality.
Re: (Score:2)
This is good advice. I've gotten to know the guts of some massive core systems mostly by cleaning up code, making minor bug fixes, and adding a new feature (10 digit SSNs instead of nine).
Openhatch [openhatch.org] is a great place to get started....
Try some good quality marijuana (Score:5, Funny)
Bug hunting (Score:4, Insightful)
Write your own documentation (Score:2)
As you are doing this, start generating you own documentation. If the code doesn't use DOXYGEN, add that. Reformat and add comments. Write external documentation. When you are documenting, think of what you wish the previous coders had done for you, and then do that.
This is the way I write code from the beginning, and it leads to better code. If I can explain what is going on then I know I understand
Comment removed (Score:5, Insightful)
Re: (Score:2)
I think I'd rather try to pro
Re:Reading code is hard (Score:5, Insightful)
Exactly. And it's why I always encourage programmers to write for readability rather than for terseness or whatever the latest cool tool is. Code is also read many more times that it is written.
I'd much rather see a procedure that takes 10 lines is immediately obvious what it does than an "optimized" 5 line procedure that takes some head scratching to figure out.
People who claim "more lines of code mean more probability of error" are typically very wrong. .
Re: (Score:2)
There'd be more stuff on things like unit testing, breaking dependencies, troubleshooting, and refactoring at least.
A big obstacle to more unit testing, breaking of dependencies and refactoring in industry is that all of these things take time and effort, time and effort that could be put into new code and features, and mostly for things which have little or no immediate business payoff. To invest in these things is to invest in the future of the code base and the productivity of future programmers who may come in years after the code was written or long after the original programmers have moved on. In an industry that o
Substances and coding (Score:5, Insightful)
Find out what drugs the original coder was using when writing, and take the same.
Re: (Score:3)
In all seriousness it can help to find out what books he read and thus what bullshit design paradigms he was into. Also try to get his username on Stack Overflow so you can find all is questions to get an overview of the development process and the challenges he faced.
C vs C++ (Score:5, Insightful)
You mentioned you have embedded C experience and the code of interest is written in C++. You didn't mention if you had any C++ or other object-oriented programming experience. I assume the C++ code uses the OO features of C++ that distinguish it from C -- but this assumption is not necessarily true.
So, if you lack OO experience and the code is truly OO C++ code, you might want to do a little reading up on the basics of OOP in order to spend less time spinning your wheels.
Re: (Score:2)
If he's used to working with electronics he'll probably find the basics of OOP quite easy to grasp.
OOP : Electronics
Object : Component
Class : Production line
Public functions/methods : Interconnect
Private functions/methods : Internal connections
Even this basic mental model naturally leads to interesting theoretical questions like "can a program generate a class at run time based on information that it has gathered?". (Probably not in any easy or recommended way in C++ or Java AFAIK.)
Rewrite some parts (Score:5, Interesting)
Here is how I work on legacy code:
1) I don't look at the whole picture because there are too much details, so I prefer to attack little by little.
2) I quickly check what I can rewrite in order to optimize the code. If I have no idea, I run a profiler, and take a look at the routines that take the most time.
3) once I understood or rewrote the most consuming parts (sometimes it's heavily optimized, but most of the time, I can make a real improvement), I decide what most important functionality I would like to add, and I just focus on that.
4) if I really need to have robust code, I write tests for the routines before optimizing them, so that I can validate if there are regressions
5) whenever possible, I use "assert" and put some bound-checking tests, in order to validate the ranges of certain values or conditions.
The important thing is to start by taking ownership of a small part of the code, then a bigger part, etc... ... ?
Take one slice at a time, not the whole pie.
And one last point: knowing every little detail is useless, concentrate on what is important for you: performance, functionalities,
Visual SlickEdit/ Emacs ctags help a lot. (Score:2)
Re: (Score:2)
SlickEdit has saved my ass time and time again. I'm a cheap bastard and I hate paying for software, but SlickEdit is worth every penny. I can't imagine dealing with a large codebase without it. Yes, I've also tried cscope+vim and ctags, and it's fine, but SlickEdit is faster and easier to deal with.
I start reading other's code with... (Score:2)
less
Keep Some Rules In Mind (Score:5, Insightful)
2) Just because the code is awful doesn't mean it has no value -- No matter how bad it is and how difficult it is to read, if it works at all it has probably got years (maybe even decades) of bug fixes and feature requests. Until you have a handle on it, any little change could cause a catastrophic cascade of side-effects.
3) No, we don't need to rewrite it. See 2. A working program now is worth more than all the pie in the sky you can promise a year from now.
4) It takes 6 months to have a reasonably good grasp of any moderately complex in-house application. It could be a year before you get to the point where someone can describe a problem and you immediately have a good idea of where in the code the problem is occurring and what functions to check.
Maintenance programming is as much about detective work as anything else. The only clues you have about the previous programmer are his source files. Once you've read them for a while you can start to tell what he was thinking, when he was confused, when he was in a hurry. Most of the atrocious in-house applications have changed hands several times and each programmer adds their own layer of crap. You can redesign these applications a chunk at a time until nothing remains of the original code if it's really bad, but it's best to save really ambitious projects until you understand the code better. I heartily encourage the wholesale replacement of "system()" calls with better code immediately, though. In several languages I've run across these calls to remove files, when they could have simply called a language library call (Typically "unlink".) If the original programmer used system("rm...") you can pretty much assume that they were a bad programmer and you're in for a lot of "fun" maintaining their code.
Re: (Score:2)
What, you mean doWhatImean( X ) isn't a valid way of coding?
Re: (Score:2)
Stackoverflow, CodingHorror (Score:5, Informative)
Read this: http://stackoverflow.com/questions/3586073/reading-others-code [stackoverflow.com]
Also: http://www.codinghorror.com/blog/2012/04/learn-to-read-the-source-luke.html [codinghorror.com]
Document it (Score:2)
Chances are that no-one else has and doing so will help you understand it as well as producing some useful output to get the project going again.
Architecture Recovery (Score:2)
You can use static and dynamic analysis to gain knowledge on the structure of the program. Static analysis can be done with tools like Modisco (however, Modisco is not for C++ I guess). For the dynamic analysis, you need to add a monitoring feature to the code. This can be done with AspectC++. Instrument entry and exits of public methods (if it is OO code) or structural blocks detected by the static analysis.
However, if the program is rather small, then you can do the analysis also by hand.
Re: (Score:2)
Try grabbing the demo version of RSA, (Rational Software Architect) [ibm.com], it's great for turning Java and C++ code into UML models and has a neat way to explore models through diagrams.
The trial version is free for 30 days.
I am sure there are open source tools out there for this, but nothing so complete.
easy.... (Score:3)
echo "i am here";
or print or console.log or printf or ...
Use an IDE with a debugger (Score:2)
Learn to use a debugger with a nice interface for exploring call stacks, data structures, threads, etc. Then, get the mystery code to do something simple. and put a breakpoint at the point its about to complete the task. (Try grepping for a string you see in the output.) Work up the call stack putting a breakpoint at the start of each procedure that is being called. Now repeat the task and look at each procedure as it is invoked.
This will be a slow and painful process. Make sure you don't have anything bett
Try and error (Score:2)
If a function is to arcane to be understood in 10 Minutes, start breaking it down into smaller *documented* functions while maintaining the same test results. Good chance that this will also help the project directly
Re: (Score:2)
Re: (Score:2)
Yea. Sure. Ideally speaking, yes. However i found one line about hte intent of creating a function not too much. But yes, breaking it down *is* refactoring (Could still be that you arrive at a function which is so fucked up its better to start from zero than to break it down)
Two steps (Score:2)
Two steps:
1. Make an act of thanksgiving that you're not dealing with code written by someone trained in FORTRAN, where all variable names are two characters long and all function names are six characters long. "You can write FORTRAN in any language." If you do happen to be dealing with FORTRANesque code, give up now.
2. Become familiar with the idioms of every programming language, of every programming paradigm (structured, object-oriented, functional, event-driven, dataflow, etc.), and of every programme
Re: (Score:2)
Calculated gotos in FORTRAN aren't trivial to reproduce in C/C++. Jumping to a pointer is the obvious analog. In FORTRAN you GOTO an int variable line number.
Write Tests (Score:2)
make it move (Score:5, Insightful)
King's route to mastering algebra ... (Score:3)
There's isn't one. Sit down and read it. Then re-read it. Then think. Then read it again. Think again. Repeat.
print statements (Score:3)
print statements are the greatest debugging tool ever invented.
it will work on any piece of code, any language, any type of situation. you can trace anything.
or their equivalent (Score:2)
spitting hex into a buffer, then reading that buffer later = primitive form of print statement
UML (Score:2)
Well, if it's not documented, write the documentation. Skip the automated crap. You need to do this yourself in order to ensure that you understand it.
That's why people take notes in classes, etc.
I'd start with a class diagram, some sort of high-level flowchart, and grouping modules into layers.
Build it and run it (Score:4, Insightful)
Re: (Score:2)
Aaah, the Toddler Method of learning. Just keep that copy in the sand-box, please.
Re: (Score:2)
best advise I've seen here.
Circle around for awhile. (Score:4, Insightful)
Spend an afternoon or three skimming around the code pulling threads and following them. Jump around kind of randomly, if things start making sense in one module, go somewhere else for awhile. Take frequent breaks. Take notes about what you think things are doing, or perhaps ideas about how to improve the code - but don't start improving things now, you just want to figure out how much you're in for.
After awhile doing that, you should have a few ideas about good accomplishable problems, now pick one and go deep for a limited time (hour, afternoon, week, depends on the scope of the code and your commitment to it). Again, keep notes, and then throw all your work away (or check it in somewhere - but don't focus on shipping, that detracts from learning). Again, go somewhere else in the code, fix something, take notes, throw it away. Alternate back and forth between research and application, trying not to bias towards one or the other (which can be a form of procrastination).
Now throw away all your notes. They were written by someone who had no idea what was going on. By now you're pretty sure you know what's going on (you don't) and how to make things better (you have no idea), so circle around for another pass. Stop when you start finding that your notes seem to be recognizing actual immediately-actionable problems and solutions, rather than hypothesis and speculation. Or just stop because you're now so busy fixing things that you don't have time for exploration.
Find the author (Score:4, Insightful)
Find the person who wrote the code. Make sure that educating you or your colleagues is part of their paid responsibilities, and make sure that you respect their work when reviewing it: this helps them share the ir work and take it well if you need to revise things. My colleagues and I often bring new features or help stabilize old projects, and a working relationship with the original author is invaluable.
And ff the author says "just read the code, I don't do documentation because documentation can lie", or if they say "don't bother checking the data for correctness, just don't make mistakes", be ready to throw out _everything_ they ever wrote. It may work at the moment, but it's likely to be as broken and unsustainable as their attitudes.
hard to say (Score:4, Funny)
Depends... (Score:2)
Depends on whether you understand what the code does. If you understand what the code does from the user perspective, then find the code which does the most critical and interesting bits and find out how it works. If you have little clue about what the code does then its trickier. I think just browse the code and be guided by your own curiousity. Examine any documentation that might exist, or any user interface that might be available to find clues to what is important.
Look at what external libraries it use
Bottom-up (Score:2)
Load up the UI/interface, find a very specific piece of functionality, and then find the UI hooks in the code and work backwards from there. Repeat for another function that involves something completely different, i.e. access control/data/rendering/logic.
Once you are comfortable with that process, you are ready to absorb from the top-down.
I like starting with data structures (Score:2)
If possible, I usually like to start by getting an overall understanding of the various data structures used to implement the program. Sometimes this can be very helpful, particularly if the code was written by someone who designed the code rather than hacked it together. Ever since I took my first data structures class I have maintained that if you can understand the structures, the algorithms become almost self-evident. However, it's not always tremendously helpful, particularly if the implementor just
Relevant advices (Score:2)
Debugging! (Score:2)
Fire up your debugger and start stepping!
Whats the point? (Score:2)
Whats the point in reading foreign code if you don't plan to work on it?
If you want to work on it, isolate the area your code will touch the old code and work on that with a debugger.
Reading huge C/C++ code bases is rather pointless ...
Re: (Score:2)
You should have a look at Codeblocks. Its a nice IDE and it does a pretty good job. Runs on Linux
Re:Use the tools Borge (Score:4, Interesting)
Reading other people's code is a punishment that one must master if you hope to grow as a programmer.
So what is the reward for reading comments which are unnecessarily set in monospace type?
Re: (Score:2)
In fairness I don't think I've ever read *any* STL implementation that wasn't hideous. Seems like non-trivial template programming internals are sort of like VB - without exhaustive self-discipline the result defaults to hideous abominations you pray you never have to look at again. And it doesn't help debugging that compilers all seem to be optimized to deliver maximally-obfuscated error messages if they encounter a problem related to templated code.
Don't get me wrong, I love templates and even engage in
Re: (Score:2)
Re:Don't (Score:4, Interesting)
A person is a genius if he knows every nook and cranny of C++. But no one is expected to. Even just classes and objects are a fantastic addition over C, so there is really no reason to shun C++.
The problem is that taking C and just adding classes and objects would have been nice, but the changes in C++ go so far beyond that they can reach a perl-like level of syntax confusion.
Re: (Score:2)
The problem is that taking C and just adding classes and objects would have been nice, but the changes in C++ go so far beyond that they can reach a perl-like level of syntax confusion.
You still have that option. Just take the basic OOP parts and don't use the crazy stuff [google.com] at all. :)
Re: (Score:2)
Actually Linus wrote a follow-up [indiana.edu] for that in rc6. :)
And I didn't even need to curse all that much at people. Sure, I talked smack about some of your hamsters, and I declined a couple of pull requests, but let's face it, it was pretty halfhearted. Most of the time things were good.