I think "the best way to read code" doesn't exist.
I'd say that only for very small projects are you going to have the time to read all of the code. So for any real world example, you'll need some strategy to decide which part of the code is important. [as an aside: your brain is being bombarded with visual information all the time, but you only pay attention to (and process thoroughly) a small part of it; you want a good attention-like mechanism for information in the form of code]
The best strategy for deciding which part of the code to read depends very much on why you're reading it.
Say you're writing a window manager and need a good placement algorithm. It might be useful to find the window placement code in another window manager or two, study that code intently, and be inspired.
Say you've written a patch to a program, but introduced a bug in the process. Your reading is by necessity going to be spread out much more: you're looking for interactions between your new code and any preexisting code.
Say you're trying to get an architectural overview over some piece of software. Your reading will again be spread out, but even more than for finding the bug: you have no particular place in the code to "start from". Some visualisation tools might also be handy (static call graphs, class hierarchies, time and memory profiling hot spots in color).
That said, there may be ideas that can help you no matter why you're reading the code. I'm blank on that bit, sorry :-)