Hacker News Reader

Comment by hashin | Hacker News Reader

I am being curious here. Do anyone really print out the code so that the comprehension really increases? I can imagine all the benefits, but can someone give any first hand experience were this has actually helped them?

Also, how better is it than the code map on Sublime Text or syntax colouring we have anyway?

View on HN

Sure, at a prior job we passed out hardcopies of a side-by-side diff before scheduling a peer review (including only the affected methods/functions).

No syntax highlighting, but it was quite useful. Off the top of my head, the two main benefits are: 1) You free up your computer for the review 2) You get a different form factor to interact with.

Regarding the first benefit, having a printout means you can use your computer to run the application, look up docs, and even (ironically) navigate the code in your IDE.

As for the second, having a printout means you can spread out the pages to compare different bits of code, draw diagrams, connect arrows, circle bits of code for notes, etc.

It was pretty useful.

Yes, I do print source code. If it's somebody's code (or mine from long ago) I need to rewrite or reorganize and it fits on several pages of paper, I find it much easier to analyze it this way.

I can doodle and write remarks on top of the code, but I think much more important aspect of written code is it gives different friction profile than browsing the same code with editor (or on a screen in general).

This "friction" thing is hard for me to put into words, as it's quite subtle feeling. I can't freely search the code for identifiers nor run it, so I'm sort of forced to make notes and remember things, but I can mark parts of the code in different ways, and I can write an alternative pseudocode alongside the original, and I can add a TODO or REMOVE or UNNECESSARY marks.

I do a similar thing for code I need to write, except, obviously, I have nothing to print yet. I write the parts of the code on paper, (what allows me to omit all the uninteresting trivia). Then I can proceed with what I would do with printed code.

I've done this recently for a few of the open-source third-party frameworks we use. I'll print out the source code and relevant unit test code for a particular class I'm interested in learning about (or in the case of js code I'll usually just print the entire file). I'll start by reading the unit tests first and then read the actual source. The real benefit of doing this is that I can easily write hand-written notes alongside code to come back and review later. I've found this way of note-taking to be superior to other note-taking tools that allow notes alongside code (like org-mode).

I have done, for code that fits on 2-8 pages (basically a demonstration program). I used vim's ":hardcopy", so the printed code was already syntax-highlighted in the way I was used to.

This did let me work on the code when away from my workstation, but I didn't otherwise find it very helpful. If you have lots of code, some form of code navigation is very helpful.

Vim's :TOhtml can be handy if you need to see syntax highlighed source on a tablet or some other device that doesn't run vim.

I do, usually if one of the following is true:

* I haven't worked with the codebase in the last 3 months

* I wasn't the author

* I'm heading into a major refactor

Paper is malleable. I can cut it out, slide things around on a desk, to show better relationships.

I can write all over the code without forcing any format or alignments.

It helps me understand the control flow, and the exposed API, faster.

I like to print things out because it makes them very concrete. I can literally see the whole code base I need to become familiar with. It's very useful for working in legacy code bases, or when trying to reverse engineer what is actually happening. The place memory (e.g. remembering that a variable was defined on the bottom of the third page of the printout) helps to situate you.

However, I'd say it's only worth it if you need to do "deep reading" of convoluted code, or if you're in very unfamiliar territory. Also, it doesn't work when the "printout" becomes too large—a full printout of a 30K LOC project is about 600+ pages. No way you're going to read all that!

I feel like most of the code I read at work should never be printed. Even if it is production code, it would make it very "real" and... embarrassing. Haha.

Reply on news.ycombinator.com