Well the question is in the title - how do I improve my code reading skills.

The software/hardware environment I currently do development in is quite slow with respect to compilation times and time it takes the whole system to test. The system is quite old/complex and thus splitting it into a several smaller, more manageable sub-projects is not feasible in a neare future.

I have realized is what really hinders the development progress is my code reading skills. How do I improve my code reading skills, so I can spot most of the errors and issues in the code even before I hit the "do compile" key, even before I start the debugger?

  • I've been dealing with a similar problem. Our team decided to invest time in retrofitting a very large legacy code-base to a new build that supports shared caching. We managed to improve our build times and build reliability significantly. Also, if you can refactor just enough to start using large pre-built parts of your application, you can also save building time. – smithco Feb 27 '11 at 3:08
  • 1
    like all skills, its only gets better with practice and seeking advice from those who have more experience. – user18041 Feb 27 '11 at 14:27
  • Just like learn language. More code you read, more proficience of your reading skills. – Steven Mou Jun 30 '11 at 15:30

Read more code

I, for one, got my somewhat decent code reading skills from reading certification questions, those were very difficult to follow, because they were badly written on purpose

They are supposed to test your knowledge of the language (Java in my case) after all.

The more code you read, the more experience you'll accumulate, it's that simple

| improve this answer | |

Enhance your development environment as much as possible so it can give you feedback you can use.

Modern IDE's can help a LOT if you can provide them with the necessary information. Examples are:

  • Syntax coloring: Constants in one color, comments in another, identifiers in a third, strings in a fourth, etc. I found recently a piece of code which was ... odd ... It turned out that a variable was named as a constant would be - the wrong color gave it away.
  • Catch simple compilation errors. Most languages have a simple syntax which an editor can be taught, so it can tell you ahead you will have errors.
  • Catch complex compilation errors. Many compilers can generate informational files which can be loaded into your IDE so it knows how many arguments a given function takes, etc.

Also programs exist that can identify logical errors in your programs, which you can use to get even more information about your program you can learn from.

Also, your IDE can help you navigating your source when it knows all these things. This allow you to easily look things up instead of having to memorize everything

I suggest you edit your question to provide more information about the environment you work with and the programs you write, for better suggestions.

| improve this answer | |
  • 1
    Also, a tall monitor (or a wide, pivoted one) can do wonders because you can SEE more of your code at one time. – user1249 Mar 5 '11 at 11:39

In addition to what everyone else said, you need patience if you are going to read code (especially if it's not yours). Yes, reading per line of code by heart takes practice but all worth it, and you also learn the coding styles/tricks of others. Here is what I check for in order:

  1. variable names, matching braces, imports etc.
  2. check that conditions are properly placed, and errors are caught
  3. everything else - usage of functions, etc.

I'm used to coding in a plain text editor so Ctrl+F is my friend, but an IDE is very useful especially when you're reading from multiple files.

Now if you are the one who's going to write the code, do not be afraid to put white spaces and indentations, and comments. Honestly, if it doesn't look pleasing to the eyes, it becomes a pain in the head.

| improve this answer | |

Even if I could spot all errors before I hit do compile I still would check by testing and compiling. I only would trust the a positive test and a running program.

I do think that good code reading skills can get you very far in hypothesising about code. "Probably this would go wrong !", and test that. And in finding bugs "this might be the cause lets test it"

The best way to get there is by writing the code yourself. The second best way is that the code simply is really good and explains itself (if it is really hard the code just isn't that good)

If it isn't your own code and it isn't written well the only way to get better is by doing, doing, doing. Read the code , try different things, write tests against it, get to know the code base, refactor. Tools might help, tools that can find where methods are used, where interfaces are implemented, where variables are declared etc. And tools that give you an overview of the namespaces, their relations and metrics about them.

| improve this answer | |

I had a similar problem in the past - My trick was to write a little test , leave the desk for a little time , come back , and simulate the test on paper. This way , you get to go over your code with a fresh look , and you have a specific value to check (unlike going over your code and saying "ahh.. ahh... makes sense" )

| improve this answer | |

Possibly it would be good to focus on learning one code-reading skill at a time, just as in formal code reviews each reviewer has a different responsibility. Take a body of code, and spend a week (say) looking for just bad variable names. Hit the same code again next week looking for potential null pointers; the next week look for duplicate code blocks; then multithreading issues, etc.

Having spent dedicated time honing different detectors, you may find that you can now read code with a couple - or maybe all - of them active, so you have a richer sense of code now in a single reading.

| improve this answer | |

If you are talking about compilation errors, it's not going to happen. The best solution for compiler errors is to assign the person who broke the build to baby-sit the builds until someone else breaks the build. You broke it, you fix it.

Logic errors are much more difficult to detect let prevent. One technique to prevent the simple cases is to write unit/regression tests.

| improve this answer | |

One tip I heard this morning (On SE Radio) was take a file and shrink it down to 3pt type, then look for patterns in the text. You won't be able to read the text but all sorts of patterns will show up. Its rather a nice trick.

And this is one of those place the command line is your friend, grep and pipelines can do a lot of useful things.

| improve this answer | |
  • "was take a file and shrink it down to 3pt type" - what do you mean - to change the font in the text editor to the 3pt font? – user18404 Feb 28 '11 at 10:47
  • Exactly, the idea is to see the shape of the text and not the actual words. – Zachary K Feb 28 '11 at 11:00

I used to be a programming instructor for several years. During this period I spent a lot of time reading code and commenting on it. This involves spotting compilation errors (we didn't always compile the students' code), logic and design errors and standardization issues.

In order to do that well we had to develop a keen eye for this type of mistakes, and to be able to "dry run" the code. This kind of activity also exposed me to many coding styles. Today my code-reading skills are fairly good thank to that period.

So my suggestion to you is this:

  • Do code review with your peers.
  • I recommend reading their code alone before you go over it with them so that you will have to figure out what the code does for yourself.
  • Comment on the code structure and cleanliness, standards and logic.
  • This will improve your code quality as well as your code reading skills.
  • Code review your own code some time after you've finished coding it, this way you'll be able to evaluate it "with fresh eyes" and learn from your mistakes.

Good luck!

| improve this answer | |