Reading Other People's Code (2012)

I&#x27;m quite stupid&#x2F;forgetful, so when I write code I try to do it such that some unexpected 3rd party (i.e. me in about 3 weeks time) can read through and figure out what&#x27;s going on. This generally means I include a sections both at the beginning of the code and in line which explain what I&#x27;m actually trying to achieve, broadly speaking. It&#x27;s amazing how much easier it is to read complex technical code if you understand what the <i>goal</i> is.<p>Comments which describe the code are much less useful than a commentary regarding the code&#x27;s objectives, in my opinion.

Maybe this says more about the quality of the code I have to work on or my own lack of ability.<p>Our legacy code often comes along with a large number of interfaces and dependency injection and it&#x27;s difficult to find where the code actually &#x27;does something&#x27;. So the only way I can understand what the code is doing is by stepping through it in a debugger.<p>If I just try to read it, I end up half a dozen classes away from the method I&#x27;m trying to understand in no time.

It says &quot;Entire businesses have been built on the idea of sharing and writing code, but not reading.&quot; and links to Github, implying that Github is not built on the idea of reading code.<p>I think that&#x27;s an unfair characterization. Certainly Github could do more to make code readable, but part of the reason that Github took off and largely replaced other alternatives was that it made it much easier to actually read the code instead of hiding it behind all the extraneous project administrivia. The project&#x27;s code is still the first thing you encounter on a project&#x27;s page, even emphasized above its README. Github&#x27;s code browser is actually pretty excellent compared to a lot of the alternatives. There&#x27;s fast navigation between files and decent syntax highlighting for a wide variety of languages.<p>I know that I at least spend a lot of time reading code on Github; probably more time than I spend doing anything else on Github. At any given time, I have a half dozen or so browser tabs open with Github code pages on 3rd party libraries that I&#x27;m using.

&quot;Only thing you can be sure of is the source.&quot; not sure that&#x27;s even true: <a href="http://cm.bell-labs.com/who/ken/trust.html" rel="nofollow">http:&#x2F;&#x2F;cm.bell-labs.com&#x2F;who&#x2F;ken&#x2F;trust.html</a>

Unfortunately, it seems that the tool hasn&#x27;t been worked on.<p><a href="https://github.com/myusuf3/rainman" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;myusuf3&#x2F;rainman</a>

I am working on a tool that helps document how code has evolved that I believe is similar in spirit to this post:<p><a href="http://www.storytellersoftware.com" rel="nofollow">http:&#x2F;&#x2F;www.storytellersoftware.com</a><p>I am actively working on it with students of mine.<p>Here are some thoughts on reading code:<p>We read code left to right, top to bottom, but how often is it written that way?<p>We need to be able to see the order that changes are made in order for us to understand them. Deltas in a version control system store the changes but we lose the order. The time in between commits in a version control system is way too long to understand how code has evolved. Because of this (and the loss of order) there is no good way to animate long term differences in a traditional version control system.<p>There is not a good place to document the reasons why changes are made. We are supposed to write the reasons why in the commit log but we all know we are terrible at that. How easy is it to remember the 50 changes to 20 files that we made since the last commit let alone describe them in a meaningful way? Very hard. This results in one sentence commit messages that are almost useless.<p>We could alternatively write reasons why changes are made in code comments. But, this doesn&#x27;t make a lot of sense most of the time. Who wants to read a comment about how some code has changed if we can&#x27;t see the old version of it anyway?<p>So, we make changes, and have good reasons why we make those changes, but we don&#x27;t write the reasons down anywhere. Storyteller permits a new type of documentation to be created. It animates the changes to code and allows the developer to comment on the changes as they are being animated. Developers can tell stories about why groups of changes are made and distribute them to team members. The stories are searchable from the code.<p>We are also working on making it have traditional version control functionality to completely replace so-called modern version control (even the most modern vcs seem to be built with 1980&#x27;s constraints- disk optimized, clunky command line interface, poor visualizations of changes, etc.)

It would be nice if there was some standard way to structure code so that it could be read through in order and mostly make sense. Maybe even a `how-to-read-this-code.readme&#x27; file which laid out an appropriate order to read things in, and making sure that the code is in an appropriate order.

I read this a year ago, I was really hoping for something to come of it.<p>Really cool idea.

I think reading code is a very good practice, and the more you read the easier &quot;step 2&quot; (the understanding bit anyways) becomes. That being said, I don&#x27;t think reading through huge blocks of comments so that you can understand a function is useful. Forcing yourself to write self-explanatory code with a short docstring is a lot more useful than some hacky code with a huge comment explaining what it does.

I start by reading the tests.