Become a fan of Slashdot on Facebook


Forgot your password?
Open Source Programming

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."
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How To Start Reading Other's Code?

Comments Filter:
  • Test and Break (Score:4, Insightful)

    by Jacky Alciné ( 2953293 ) on Sunday June 16, 2013 @04:27PM (#44023571)
    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 :)
    • Re: (Score:3, Funny)

      by Anonymous Coward

      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!

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

    • Contacting the earlier developers is good advice.

      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
  • by Beryllium Sphere(tm) ( 193358 ) on Sunday June 16, 2013 @04:30PM (#44023587) Homepage Journal

    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.

    • by girlintraining ( 1395911 ) on Sunday June 16, 2013 @04:43PM (#44023683)

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

      • by gl4ss ( 559668 )

        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.

      • by inasity_rules ( 1110095 ) on Monday June 17, 2013 @03:15AM (#44026783) Journal

        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.

    • That's assuming the original programmers followed the MVC pattern. Very often they didn't. That's when you start reading tea leaves.
  • How to read code (Score:5, Insightful)

    by girlintraining ( 1395911 ) on Sunday June 16, 2013 @04:30PM (#44023595)

    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.


    • Re:How to read code (Score:4, Informative)

      by stephanruby ( 542433 ) on Sunday June 16, 2013 @08:47PM (#44025033)

      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.

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

  • by Anonymous Coward

    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)

    by Anonymous Coward on Sunday June 16, 2013 @04:32PM (#44023607)

    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)

      by skids ( 119237 ) on Sunday June 16, 2013 @09:12PM (#44025149) Homepage

      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.

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

  • by jd2112 ( 1535857 ) on Sunday June 16, 2013 @04:34PM (#44023621)
    Everything else will seem simple after that...
    • by c0lo ( 1497653 )

      Everything else will seem simple after that...

      Everything? I doubt [] it.

    • Better yet, read your own 3 year old Perl code. Everything else will seem simple after that...

      • by fyngyrz ( 762201 )

        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

        • by jd2112 ( 1535857 )
          Coding in Perl with a chronic case of CRS taught me the importance of writing legible code. After rewriting my own code a few times because I couldn't figure out how it worked I found that writing legible code is even more important than writing well documented code. And one you learn to write legible code in Perl (yes, it can be done) you can do it in any language.
  • Doxygen (Score:5, Informative)

    by mapinguari ( 110030 ) on Sunday June 16, 2013 @04:39PM (#44023657)

    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.

  • by Laxori666 ( 748529 ) on Sunday June 16, 2013 @04:41PM (#44023667) Homepage
    First, figure out how the code gets loaded and runs. Find the equivalent of the 'main' function. Then start tracing it, seeing what functions get called, how things are loaded, etc. What really helps here is an editor you can CTRL+click on a function on to go to its definition. When you hit a function that doesn't call any other unknown functions, then you can start understanding what it does without having to step into it. These are the basic functionality units. Then when you know enough of those, you can start going a level up, etc. Eventually a picture forms in your mind of just how things work. You can optionally skip over functions for preference of looking at them later if it seems pretty clear what they do based on the name & how they're called, but you might find important stuff in there later. This is how I go about it, anyway. It can be very frustrating and very confusing at first, but eventually the picture starts making sense, then things click in a most satisfying manner. That being said, the above is also the reason I can dislike complicated frameworks. There's so much indirection that it can take quite a while indeed until you hit something concrete. The mark of a good framework is, either it doesn't do that, or it does but soon enough you figure out its parts and then you can treat it intuitively.
  • by zieroh ( 307208 ) on Sunday June 16, 2013 @04:42PM (#44023675)

    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.

    • by Anonymous Coward on Sunday June 16, 2013 @05:01PM (#44023781)

      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.

    • by MAXOMENOS ( 9802 )

      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 [] is a great place to get started....

  • by stevegee58 ( 1179505 ) on Sunday June 16, 2013 @04:49PM (#44023717) Journal
    It won't help you understand the code but you'll stop worrying about it so much.
  • Bug hunting (Score:4, Insightful)

    by tinkerghost ( 944862 ) on Sunday June 16, 2013 @04:55PM (#44023755) Homepage
    I recommend starting by working on the bug list. It gives you something to work on constructively and it also makes you look through all the code to track the problem.
  • As others have said, read the code. Do this top down; start at the main function and look at the call tree.

    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

  • by benjfowler ( 239527 ) on Sunday June 16, 2013 @04:57PM (#44023761)

    The trouble with university education, is that most people who teach there are computer scientists, not software engineers with years of experience in the trenches.

    If this were actually the case, there would be a recognition that reading code is far harder than writing it. And far more emphasis would be on coming to grips, understanding, and working on large code bases. There'd be more stuff on things like unit testing, breaking dependencies, troubleshooting, and refactoring at least.

    • At the university I attended, courses did include some of that material, and I doubt it's curriculum was anything out of the ordinary. I recall a project where we had to document sed, the UNIX utility, using only it's source code for reference. (I know that doesn't count as a large code base, but there's limited time available) Even if the only point was to experience the feeling of being handed a vast code base to maintain with no documentation, I'd say it was a success :)

      I think I'd rather try to pro
    • by Zalbik ( 308903 ) on Sunday June 16, 2013 @07:57PM (#44024827)

      he trouble with university education, is that most people who teach there are computer scientists, not software engineers with years of experience in the trenches.

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

    • 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

  • by spasm ( 79260 ) on Sunday June 16, 2013 @05:00PM (#44023775) Homepage

    Find out what drugs the original coder was using when writing, and take the same.

    • by AmiMoJo ( 196126 ) *

      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)

    by Rob the Bold ( 788862 ) on Sunday June 16, 2013 @05:01PM (#44023785)

    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.

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

    by eulernet ( 1132389 ) on Sunday June 16, 2013 @05:02PM (#44023793)

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

  • At work I am a big fan of Visual SlickEdit. It builds complete tags of all the functions, variables, classes etc into tags. Allows me to find all callers of a particular function, definitions, references etc. In Linux it will work with gdb to do step through debugging. I believe most of the functionality is available in emacs, with its ctags. Though most developers in our company use Microsoft IDE, I build all my sln files using slickedit and edit using slickedit. It has good integration with version manage
    • by jasno ( 124830 )

      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.

  • by Greyfox ( 87712 ) on Sunday June 16, 2013 @05:14PM (#44023859) Homepage Journal
    1) Just because your predecessor was paid to program doesn't mean he craps daisies and unicorns. I have often gone in with the assumption that the guy before me knew what he was doing. Quite often I find I was wrong.

    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.

    • What, you mean doWhatImean( X ) isn't a valid way of coding?

  • by Anonymous Coward on Sunday June 16, 2013 @05:17PM (#44023873)
  • 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.

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

  • by Idimmu Xul ( 204345 ) on Sunday June 16, 2013 @05:36PM (#44023965) Homepage Journal

    echo "i am here";

    or print or console.log or printf or ...

  • 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

  • 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

    • If your code needs comments, it needs re-factoring. If the code is not self-documenting, it's worthless.
      • by drolli ( 522659 )

        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:

    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

    • 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 unit tests for the code and develop a regression test suite for it. This in itself can help you understand what's going on, but then also when you later start re-factoring or changing the code, you can be sure you're not breaking other parts of the code in subtle ways (or at least if you do break it, you'll know sooner than later). This will also help anyone else who might contribute to the project. Your mileage will vary depending on the size of the code base of course.
  • make it move (Score:5, Insightful)

    by superwiz ( 655733 ) on Sunday June 16, 2013 @06:15PM (#44024197) Journal
    It's just how your brain works. It's a lot easier to examine a piece of mechanical machinery when it's in motion. You notice more. Do the same with the code. Run it. Run components independently. Put plenty of log statements or if it's feasible, watch under a debugger. But don't try to look at stale code just sitting there. You'll notice more as it moves.
  • by Kittenman ( 971447 ) on Sunday June 16, 2013 @06:38PM (#44024389)
    This calls to mind the story of the king who was in a class for learning algebra, and after realizing it was hard, he took the teacher aside and said 'I'm the king - show me the easier route'.

    There's isn't one. Sit down and read it. Then re-read it. Then think. Then read it again. Think again. Repeat.
  • by decora ( 1710862 ) on Sunday June 16, 2013 @07:06PM (#44024553) Journal

    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.

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

  • by Java Pimp ( 98454 ) <java_pimp AT yahoo DOT com> on Sunday June 16, 2013 @07:18PM (#44024613) Homepage
    You will never fully understand the code just by reading it. My approach is to ignore all of it until something needs to be changed. When you need to change something, add a feature, etc... find where in the code the functionality is and tweak it a bit. See what happens. Tweak it some more. See what breaks. You will start to get a deep understanding of a focused section of the code and not have to worry (yet) about other unrelated areas. Start with small changes first. Larger changes may require a deeper understanding of the architecture and how pieces interact. This will come in time. After a few iterations of this and you will eventually become intimately familiar with all the pieces of the code.
    • by Tablizer ( 95088 )

      You will never fully understand the code just by reading it...Tweak it some more. See what breaks.

      Aaah, the Toddler Method of learning. Just keep that copy in the sand-box, please.

    • best advise I've seen here.

  • by shess ( 31691 ) on Sunday June 16, 2013 @07:32PM (#44024679) Homepage

    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)

    by Antique Geekmeister ( 740220 ) on Sunday June 16, 2013 @07:51PM (#44024795)

    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)

    by bloodhawk ( 813939 ) on Sunday June 16, 2013 @08:36PM (#44024995)
    I always find this greatly depends on the quality of the code, which varies greatly from well written and documented and just involves some boring reading and tracing through of execution paths too the absolutely appalling where you can sometimes only understand why the fuck they did something when you change the code and see how it breaks. The former I usually rely on a quiet room and lots of caffeine, the later requires swearing, loads of code changes to trace what is actually happening and cursing the original author, their relations and the goat you are sure they must have been molesting while writing the code.
  • 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

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

  • 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

  • This [] was posted on reddit a few days ago (pdf warning yadi yada). I think that the "From Legacy Code to Clean Code" section may be relevant to you.
  • Fire up your debugger and start stepping!

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

"If the code and the comments disagree, then both are probably wrong." -- Norm Schryer