As the article somewhat alludes to, code isn't like a sequential book, but more like a conceptual system or a complex model. Rather than reading from top to bottom in a literal sense, the top you need to find to start with is the overview from 1000 feet (may the API or the design docs/specs), and you work your way down to the conceptual bottom or end of the story, which is way down in the implementation.
I'm not sure that the solution in the article achieves this in a coherent manor, and is only of relevance to one particular code repository (albeit a very popular one!), although it's never the less useful.
There is a class or two of tools that already exist and do help in this top to bottom process, doc generators and profilers (and sometimes debuggers). These work across all types of code repositories and all variations in quality of code. For instance, see the chap recently on HN who was trying to read and get to grips with a large code base [1] and my comments to him [2].
Granted these tools are versatile and go beyond just "reading" the code, perhaps there is some space for derived products which use these to create a "story" of the code from a top to bottom perspective.
Books are by default sequential, but they also offer a lot of different means of indexing to get what you want: the table of contents, the index, or just flipping through. And if you have no idea where you start, you know where to begin: at the beginning of the book. Software projects are often not linear, but trees where the leaves are files. Even in a reasonably modular code base, there's no real beginning. But I'd disagree that code is inherently unsequential when it comes to understanding it. One would have to do exactly as you suggest. They'd have to start with an overview, tell the conceptual story, then write the implementation. They'd have to write a literate program.
Comments
As the article somewhat alludes to, code isn't like a sequential book, but more like a conceptual system or a complex model. Rather than reading from top to bottom in a literal sense, the top you need to find to start with is the overview from 1000 feet (may the API or the design docs/specs), and you work your way down to the conceptual bottom or end of the story, which is way down in the implementation.
I'm not sure that the solution in the article achieves this in a coherent manor, and is only of relevance to one particular code repository (albeit a very popular one!), although it's never the less useful.
There is a class or two of tools that already exist and do help in this top to bottom process, doc generators and profilers (and sometimes debuggers). These work across all types of code repositories and all variations in quality of code. For instance, see the chap recently on HN who was trying to read and get to grips with a large code base [1] and my comments to him [2].
Granted these tools are versatile and go beyond just "reading" the code, perhaps there is some space for derived products which use these to create a "story" of the code from a top to bottom perspective.
[1] http://news.ycombinator.com/item?id=4557919 [2] http://news.ycombinator.com/item?id=4558801
Books are by default sequential, but they also offer a lot of different means of indexing to get what you want: the table of contents, the index, or just flipping through. And if you have no idea where you start, you know where to begin: at the beginning of the book. Software projects are often not linear, but trees where the leaves are files. Even in a reasonably modular code base, there's no real beginning. But I'd disagree that code is inherently unsequential when it comes to understanding it. One would have to do exactly as you suggest. They'd have to start with an overview, tell the conceptual story, then write the implementation. They'd have to write a literate program.