

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

You are looking at a chuck of code that is 1000 lines long...<p>- Say if the code has little to no documentation.<p>- Say that variables are mostly named with acronyms.<p>- Say there are 20 if statements including nested.<p>I am a very visually oriented person so i find it difficult.<p>What techniques do you use to understand what is happening?
======
_delirium
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
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
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
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.

