Print out your code. On paper(medium.com)
medium.com
Print out your code. On paper
https://medium.com/@tashian/print-out-your-code-on-paper-7c760a376bca
6 comments
Agreed. This really just sounded like a "Look at this new tool I found" type of article. Which is great, but I was disappointed that he didn't go over bugs that he found with this method and more specific value-adds that this helps provide.
I do think there is merit to looking at code outside of an IDE (for the sake of keeping yourself focused on the task at hand), but that's what a typical code review provides.
Maybe a process like this is good for looking at "bad" code and theorizing how to improve it. But even then a lot of my problems span multiple files and multiple modules (and I don't suspect I am alone in this) so it seems inefficient to print all of that out.
I do think there is merit to looking at code outside of an IDE (for the sake of keeping yourself focused on the task at hand), but that's what a typical code review provides.
Maybe a process like this is good for looking at "bad" code and theorizing how to improve it. But even then a lot of my problems span multiple files and multiple modules (and I don't suspect I am alone in this) so it seems inefficient to print all of that out.
It’s probably not necessary to print it out, but it’s a great way to establish the discipline for doing it in an IDE/editor.
A company I used to work at did code reviews this way, we printing out pages of code and go through it in a meeting room with multiple reviewers. It could be overkill for binary deliverables, but when the deliverables included source code it really forced you to focus on it, having no other distractions.
In an IDE you’d go-to-definition on a symbol, maybe get distracted, start reviewing some other file, a refactor here or there, and before you know it you’re down a rabbit hole and have lost context on what you were initially reviewing. On paper you have to mark it to come back to later, and continue the rest of the review.
A company I used to work at did code reviews this way, we printing out pages of code and go through it in a meeting room with multiple reviewers. It could be overkill for binary deliverables, but when the deliverables included source code it really forced you to focus on it, having no other distractions.
In an IDE you’d go-to-definition on a symbol, maybe get distracted, start reviewing some other file, a refactor here or there, and before you know it you’re down a rabbit hole and have lost context on what you were initially reviewing. On paper you have to mark it to come back to later, and continue the rest of the review.
I only print out code and read it when hunting for an elusive bug. This is a last resort effort and often successful.
Also, going through big blocks of code on paper in stead of a screen is easier on the eyes.
Also, going through big blocks of code on paper in stead of a screen is easier on the eyes.
Unfortunately the code that I have to read / review is stored across multiple repos and many many lines. I'm too used to using VS Code to look up functions and jump to relevant declarations. While I can appreciate the aesthetic of going over my code with pen and pencil, it would largely slow my (and probably others) down quite a bit.
This is how I worked as an undergraduate back in the day when we had to fight for computer time.
It's just not tenable now for anything longer than a handful of methods. It adds no value.
It's just not tenable now for anything longer than a handful of methods. It adds no value.
> You’ll learn something every time you do this.
Learn what? Reading through code to ensure that variables and functions have the best possible name is a great value-add but I remain unconvinced that you need to print out code to achieve this.