4 ms·

Ask HN: How do you "read"/understand/interpret existing code for software?

• _delirium 15y ago
  I haven't found a good skimming solution to this. If there's no good documentation, interface, variable naming, or other hint to what it's doing, it either has to fit a code pattern you recognize easily, or else you have to fall back to mentally tracing through what's going on. If I really need to understand it, I start segmenting the code into sections and adding comments about what it looks like each section is doing. Then you can do a few iterations in bottom-up style. For example, with branches, start out by commenting what every branch does considered in isolation. Then from those comments (now hopefully more transparent than the original code was), see if you can find what pattern a series of tests is doing in aggregate.
  • mpg33 15y ago
    funny you should say skimming...because thats how i have been looking at code and i think it is my main problem...i try scanning the code over and over but get nowhere with it
• samdk 15y ago
  It really depends where you're starting from. If you don't have any idea what a particular piece of code does, finding that out is your first goal. If you can, ask someone: a two-sentence summary of what a module does can save you hours of digging through things, and takes almost no time for the person you're asking. From there, I have a couple of things I usually look at immediately. The most obvious thing to do is to try to find entry points into the code, and figure out what happens when those calls are made by reading sequentially. This is often the best way to work, although not always. The second thing to do that can be very helpful is to look at the external library calls that are being made. Those can give you an idea of what the code is actually affecting, which can be very helpful for getting a high-level overview. Another entry point is state that's being kept and modified from multiple locations. (Figure out what's being stored and why by looking at the code around where the state is modified.) One last thing you might try to do is reformat the code if it's particularly ugly. I try not to refactor unless I understand what's going on so I don't introduce bugs, but just reformatting can make a big difference sometimes if the style of the person who wrote the code is significantly different from your own. (And truth be told, 1000 lines of code in one file isn't that bad. When you start working with multiple files, some sort of method of jumping to function/method definitions becomes extremely useful. Since I use Vim, I often use something like ctags. Knowing how to use Unix tools like find and grep is also extremely helpful.)
• BrandonMTurner 15y ago
  I think I am probably a little above average when it comes to reading, understanding, and fixing other people's code. Here are a few things that helped me train myself: 1) I read a lot of open source code, the more you read the more aspects you learn about the way other people code. 2) I fix a lot of bugs. At first I fixed bugs in an large open source project. Thats all I did in the project, just kept fixing bugs. Then when I got my first real job outside of school (MSFT) I fixed tons of bugs. I poached bugs off other people (this has a side bonus of your team quickly growing respect for you). Now, those are things that will help grow your skills but probably won't help you at this moment. Here are some tips for the way I approach the problem: 1) Use a debugger. Right from the start, use a debugger and look at the variables that are coming and going. Look at their values. Do this over and over again. 2) Rewrite the code. Even if you don't use the code and you end up reverting it all (which I do more often then using my re-written code). Start with the smallest methods and work your way up. You will begin to run into issues that the original author also probably ran into. Often times, these issues force the code into a certain form which would be non obvious just reading it.