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