What benefits can be gained by printing out code as opposed to reading it on screen?
Do you print your source code? If so why?
What benefits can be gained by printing out code as opposed to reading it on screen?
Do you print your source code? If so why?
You can put it up on the wall, and see it all at once.
You can write on it.
You can draw arrows from one place in the code to another.
You can draw on the paper or use a highlighter, which might be helpful.
Hand editting. Making giant marks on things you want to take out. Folding the leftovers into paper airplanes to throw at your co-worker when you know both you and him have nothing better to do.
In all seriousness, probably the only time you would want to print out code is to make big edits than you don't want to just comment out, but instead put a red mark though. Also, if you have developed a secret algorithm that is vital for your company to keep. And finally, if you are really really bored.
Anything after that it can be very situation based. If you want to edit code while you don't have a computer. If you were in school and needed to turn it in. And, as someone else already pointed out, you might want to put it all up on a wall and see everything in a larger space than your screen permits.
Portability. You can take it to meetings, and for particularly heavily used code, you can put the printout next to your monitor(s) for additional reference.
When you're on a fishing trip deep in the mountains and you have a dream where you solve some problem in your code, how else are you supposed to verify it?
Surely I'm not the only one that debugs programs in their dreams.
Reading something on a screen is like staring into a light bulb. Paper does not have a backlight.
To make an open-source paper plane! Gold!
But in all seriosuness, I print code out, when I take over a project and need an overview of everything in front of me at once. Not just a summary of whats on hand.
There is one clear advantage of printing code on paper: you get to see its shape
The shape of the code, in particular with a small font, is a telltale of interesting features. You can see methods that are too long, methods that are too short, lines that are too long, complex nesting, gigantic switch/case statements, gotos.
Try it. import your code into a word processor, make the font small (like, 5 or 6), print it and put the papers on the wall.
A nice, well designed code will be artistically uniform and pleasant. An ugly code will be noisy, nervous and irrational.
I used to work for a company where one of the developers doing code reviews always printed the most important part of the code (in his defense, he always used recycled paper). He always carried them with him and when he was idle, he take out the code and start analyzing it. The most insightful comments and suggestions came from this developer, I don't know if he simply was smarter than us, or that he concentrated better by having a piece of paper in front of him.
Other case where maybe source code will be required to be printed is for Disaster Recovery purposes. Electronic media is not reliable long term backup (I am not insinuating that paper is), CDs, magnetics tapes, etc could be damaged. So I think printed code could be a way for keeping the software in place and in the worst case scenario you could hire a code monkey to write your application back. If you don't think that will never happen, let me tell you that for the year 2000 bug/issue/hoax I used to work on a project which basically check executable binaries to check for the possibility of y2k bugs. Why? Because the programs were written zillion years before and nobody had the source code.
I worked for a company which had a binder for each server on the data center. This binder has hard copy of the system important files like /etc/passwd, /etc/hostname, lvm configurations etc. So why not code?
It's much nicer to read from paper than from a computer monitor (especially crt monitors).
In the past I have printed out sections of code that I thought could be cleaned up, but couldn't find a solution quickly. Having a copy of the code, in printed format that I could glance at from time to time helped iron the changes that I wanted to make.
For some reason printing out the code on tough issues seems to help me come up with better solutions in the long run.
Printing out the code could be benefial for few reasons one just like:
**u would be very much stressed out and wanna a glance having sip of coffee to locate wat went wrong in the code(cases when code is not working)(provided the code lines are minimal and it could accomodate only in few pages)
Writing (and reading) on a computer uses a different part of the brain then reading and writing on a paper.
The benefit is that get to analyze your code with two different sets of "eyes" to see it from two different perspective and catch defects, places of improvement and etc.
Very rarely do I print out source code - if I am looking at an unfamiliar codebase and I can't fit the whole class in my mind and figure it out on the screen I will print it out and try to figure it out from the printout, writing things on paper.
No. Never.
A printed version gets outdated as soon as you hit "Print". For reference purposes, a source control system works much better.
No, it is a waste of paper and time. We rely on a code repository and backup systems.
No, I don't.
Usually when I want to show someone my source code, I don't expect him/her to look at it for two seconds and understand everything the code does (except if someone == "Jon Skeet"...). Thus, I want to show it on a computer, so I can run it, debug and step through it to explain stuff.
Note that this is not necessarily because the code is complicated - I prefer to do this even for a small program like
def say(input):
print input
say("hello world!")
On occasion...
If I'm trying to understand a complicated class written by another (hopefully) developer, I will often print it and then disappear into a quiet room with a mug of coffee and a biro... Nothing annotates like a pen...
Only when I need to do some reading in a place where I can't (or at least shouldn't) bring a computer. I may print out some source code I've been meaning to read over then later dispose of it.
Yes, for code reviews. Reviews should take place away from all distractions, such as phones, users, managers and computers, so a print-out is essential.
I printed out the code when I made a rewrite of a small Python application to Objective C. It turned out to be handy to have the original Python code on the paper as I wrote all kind of notes and I also marked my progress of the implementation.
No. Its too inconvenient when everything doesn't fit on one page. I have sometimes printed source code snippets for people I interview to comment on.
Sometimes I do print y source code when I have a bug which I don't know where and I need to fix. Instead of staring at the computer screen for a very long time trying to fix the bug......I print the source code and start writing some notes. It worked many times and I find the bug easily. (of course I do that when the bug is some mathematical error ...)
I only printed it when I had a web project due for my school. The damn teacher can't use his brand new 2000€ MacBook to read it... Otherwise I'm against printing the code. If you have extra long lines (I'm so good at making that), and/or a total of 10k lines of code, it's really a pain in the a**/wallet to print, and really hard to read...
No, i like to read code in editors where i can jump from one section to other using minimum effort. Code on paper is irritating to go through.
Sometimes i print email for meetings which may consits of code snippets but thats very rare occurance.
The last time I printed source code was 14 years ago for inclusion in my final year project at University. Now that's got me thinking, where has the time gone!
I do, quite often. Especially long bits of unrefactored junk. Then I paste all pages together with cello-tape and use my colored pencils (you have those too, don't you?) to mark up stuff. Highlighters are also fun. Extra points for notes in the margins (x^k + y^k = z^k
for k = 2
).
I'd gladly move to e-ink / iPad, if only I could have this in DIN-A4, two of them and be able to scribble on them. In fact, electronic scribbles would way cool!
I've not printed out code for a while (a few years) - normally when I have it's been either to refer to code in another file without having to alt-tab between two editors; or it's been (as other people have already flagged) a specifically awkward function which needs a bit of thought.
However the increased use of dual-monitors has probably helped the decline of printing code as it's now possible to have the main editor open in screen 1 and the other bit of code open in screen 2.
The last time I printed code for analysis was a particularly nasty SQL Server stored procedure which I was trying to optimise. Scrolling back and forth wasn't helping as I lost track of the specifics I was tracing, splitting the window doesn't help due to the length of the code, so it was a print out on several sheets of A4, a red pen, a ruler, and a table with enough space to spread the thing out on.
Dual monitors are good, but when it comes to darting back and forth through code trying to trace and analyse, paper still has its place.
No I dont. Then again i don't print out documentation either.
Some guys here at work will print it out whenever we do a code review.
when you don't find bug or want to have a global look for modelise (AFTER coding! ;) ) it can help to all print and write on it on screen we have limits with the screen size, paper stay more easy to grab but I would like there is easy recyclable paper for printers :)
No. Every once in awhile I'll print out snippets of code, but more often it's configuration info or a list of requirements.
Only once have I printed some code. This was for a teacher who requested paper versions with highlights and hand written notes. I didn't deny him his pleasure, and using Word or similar text processor does good work, especially when the coder obeys the 80-character line width rule.
The review from paper can be quite relaxed opposed to a screen job but I wouldn't bother with wood these days.
A professor of mine always required an electronic and paper submission. It wasn't too bad on the trees though because he made us print it in print (size 6 font, landscape, 2 columns per page). I think my work for that class fit on just 50 pages that way.
Not for backing it up - would you really want to type it all in again later? Get a flash drive, CD, DVD or a tape.
On the other hand, when I've been tracing someone else's "spaghetti code" (or occasionally my own), I have occasionally found it useful to print it out, single sided, and lay it out on my desk or a floor, then just start marking it with a pen. No matter how much screen space you have, a table can always be bigger.
once resolution, multimonitors, and CPU advances made it possible to view and browse source code as efficiently or more efficiently than paper, it was game over for printing.
Printing on paper means that you're examining the code without any interactive assistance from the IDE or any code analysis tool.
This is a waste of paper, time, and money.
Get yourself a good code reviewing tool, and invest on a good collaboration room in the office, with computers, laptops, projectors, wifi.
And coffee. Lots of coffee.
We plan to print out the source code of our legacy software and burn it in a few months after our final customer switches over. The original source code is difficult to support and modify and it's been four years of hard work to get all the legacy customers to switch.
Code behaves like a hyperlinked document. It is like a choose your own adventure story. If you can't branch your reading and follow a method to its implementation, the story becomes a jumbled mess.
Sometimes I print source code of very intrincate code --or someone else 'fuzzy-functions'-- to be sure of the math, but generally speaking I use tech to read my code.
Well, if obfuscated code [ioccc.org] is your poison then staring at the computer will probably not work (unless you are the psychic type). To make sense of what is going on, you need a print-out of the code, a nice debugger, a copy of the standard and some quiet (and preferably no net connection).
The only time I print out source code is if it's extremely complicated, and I have no tools (i.e. IDE) to trace through the code upon execution. So I would have to print out the pages of code, lock myself in a conference room, and figure out what the heck it's doing.
I must say, it's quite a different experience reading through pages of code on paper than on screen.
I print it out on rare occasions. - usually when debugging legacy code. Sometimes a pencil trace on legal sized paper is the way to go.
However, with unit testing and shorter methods that come out of good design principles, I'm finding myself faced with a monolithic block of code less and less often.
Only times I've printed source code:
Rarely, if the project is complex enough that it doesn't fit easily in the brain. I'm more likely to print certain header files than the whole source (double-sided, to save trees). Then I can look for ways to structure something better without straining my eyes. Or I can refer to it while I scratch out algorithms in pen.
Sometimes separating from the machine helps me take on problems from a different angle... my fingers often 'know' how to make something work before I've had time to think about it, and the code just sort of flows out with a cloud of smoke from the keyboard. But if I unplug, it gives my head more of a chance to work on it and I can examine the composition process from new angles. I hope that makes some sense without implying that my nervous system is decentralized, or my hands personified, or whatever... I swear I don't talk to myself!
About 30 years ago, when I had a limited number of 8", 64K floppies of questionable reliability, this was all I had as a back up. And review was actually easier than looking at it on the 9 inch (or was it 5 inch?) green screen of the KayPro.
Also, I needed to test the Interface I'd cobbled together for the Selectric Printer. Not since.
I have printed code to make red pen marks all over the pages, so the client thinks I am worth my billable rate ;-)
I last printed a small snippet to bring over to the original developer and ask what it did. I could have used pastebin, but handing him paper is sometimes easier than saying "please check your email!"
No, never. Source code on screen is much easier to navigate through using a good IDE.
The only time I have printed some code was on university. My Cobol's teacher wanted a printed program we did to evaluate our grades. But it wasn't so bad, because I wrote the code on notepad and the printed.The worst time was when he gave us a test and made us write a full cobol program by hand... lots of papers and erasers were wasted on that daym, and we couldn't use some search engine to check syntax or something else.
In our day-by-day, I think printing code is a complete waste of time and money. Why do we have to print code if everything is connected by a network? We just have to send the link to the person who we want to check our code.
The only acceptable reason to print code is for studying pourposes, like a book or a printed tutorial of how to program in some language that can be bought in the supermarket.
Three cases where i print code (The two first it is code but not mine) :
Sometimes I like to print off code from a tutorial to keep around or read on long train journeys. Unfortunately Eclipse isn't very printer friendly - you can't specify a separate font (size) for printing, so it defaults to using whatever is being displayed on the screen.
When I was a TA on Haskell and Prolog programming I asked for a printed copy since the projects were sufficiently delimited to be implemented in 2-4 pages of 12pt printed code. Also, with these languages you can really enjoy reading the students solutions or disasters.
For any other case, I would categorically say no. Not environment friendly at all.
I've printed code for code reviews, to visualize an API all on one page, work through a problem, etc. HOWEVER, to address the other users' concerns around trees and "just use a laptop", there is nothing that says you have to print the ENTIRE code base.
Sure, they used to do that "back in the day" for "safety" reasons, but as it's been pointed out there's no reason to do that anymore. So instead try printing select portions of the code: a function, class, loop, interface, a portion of your DAOs, etc. Whatever is relevant to the problem you're trying to solve, section of code you're reviewing, etc.
If I do print out source code, it's not the whole thing. Maybe a function or method, but usually nothing more than that.
No. Although I can definitely see the value of printing for code reviews.
However, the same guy I worked with who did this also was in the habit of writing long strings of underscores at various places in his code as a way of delineating code blocks when he printed it out. You see, he edited his code with a pen, then went back and transfered his edits into the code modules. Seemed kinda dumb to me... and the rest of us were constantly perturbed by the seemingly random strings of underscores in the code base.
In general I prefer to avoid printing my source code. However, sometimes viewing the code in printed form is preferable. For example, my (very non-tech) boss wanted me to show him a few classes I had written and explain how they execute. Printing out the relevant pages and bringing them to his office is much easier than either having him distracted by all the other methods on the screen or sending him a copy to view/tinker with. He also strongly prefers reading printed documents and likes to make lots of comments/diagrams in the margins.
The only other time I print out my source code is when I've inherited a very dense and complicated code base. If you are normally limited to one screen complicated classes are much easier to understand when you can spread the whole thing out on a table. Even making a serial killer style map with pins and threads connecting method calls can be easier than constantly scrolling up and down on a little CRT...
I'm a teacher...I usually get the kids to print out code when their work needs to be backed up for moderation purposes. So if something goes wrong with the electronic copies, at least they have evidence of having done the work.
The vast majority of posters on Stack Overflow are pretty young.
Developers in the older languages (Cobol, Fortran, PL1, etc.) have to print the programs on paper to understand logic that's spread across individual source modules that can contain as much as 500,000 lines of code. Nope, that number wasn't a typo.
Nowadays, you can print out sections of a Cobol program. We didn't always have that ability, and Cobol developers in their 50's and 60's are in the habit of printing out entire programs. I suppose, since we'll all be retiring in the next decade or so, that this attitude will die out.
So far I didn't find the need to print source code. If I need to get my head around a large chunk of code, I use Pen&Paper(TM), but only to make a primitive flowchart/pseudocode monster that will get thrown out as soon as I get a grip of how the code works. Sometimes I do these on several occasions for the same code, until it makes sense, but the code remains on the computer.
Well, that's not entirely true. I printed code when for exams, so my documentation looks thicker than it really is :D
A follow-up question: what is the best way to print source code? Are there any utilities that will try to format things sensibly if some lines run a little long? If a long line of code has a hard-break ten characters past the width of the page, it's not very helpful to print the extra ten characters at the left edge of the page. If a long line is within 20% or so of fitting, it would be nicer to simply scrunch the font for that line; if it would still be too wide, try to wrap at a token boundary and then wrap a bit beyond the previous line's indent. Do any existing utilities do anything like that?
When you're working on a 200.000+ lines of code project printing the complete source code is only a waste of paper.
Maybe it could be usefull to print a critical function, an algorithm or something like that and review it whilst sitting in your lazy chair.
Printed code? Not since college, 11 years ago... Never saw the point of it really!
On a few rare occasions, where I was brought in as a consultant to fix someone else's mess. I've inherited projects with functions hundreds of lines long that made heavy use of global variables. (Visual Basic, of course. Zero comments, of course. Nonsensical variable names, of course.)
Then lots of multicoloured ink was needed to join up the beginnings and endings of loops, variable declarations with their usages, resource allocation and releasing (which often as not didn't happen). Sometimes this marking up would take an entire day or more.
A side effect is that all the overlapping multicoloured lines can impress management when I'm trying to explain how awful the old code is, and how necessary a rewrite is. I had one inherited application that scanned hundreds of thousands of customer account details in O(n^2) time, and with such a printout even the vice president of a bank was able to understand why this was a Very Bad Thing, and why it took more than 24 hours to produce a report.
Not anymore. Back in the day when the screen char size was 25x40 I would print it, but now it is pretty easy to find what you are looking for in the code.
I print it out in a few cases:
I printed things back in the olden days when we had dot-matrix printers and fan-fold green-bar paper. It was a great way to read or review code when our monitors only displayed 80 columns and 24 lines.
I haven't done it much since large screens and laser printers became the norm. There have been a few times when I've printed out big complicated functions and then taken them to a quiet corner away from the computer to focus, but I suspect that the next time I need to do that, I'll be using my iPad.
Some small snippets of my code were printed many times - as part of a book, whitepapers, tutorials and PowerPoint hand-outs.
But other than for educational purposes I never print out any code.
I rarely print code and when I do, it's a short excerpt of someone else's code, when I'm trying to decipher an algorithm (read: mess). On paper, I can highlight and add annotations.
The best thing about printing code is, you can take it to the toilet.
My university was very lame. In our lower-level programming courses we had to print out the source code for our labs and hand them in via dropbox. This sucked because we had to pay for our paper usage from the school printers. I think it was so that they could write on the code and hand it back...
I think the only time I've ever printed code was for a game design class I took. To this day I can't figure out how we were graded based on thousands of lines of code printed out... I think my final project was about 200 pages long...
err not since University, my dissertation was about 750 A4 pages of pure Java pain!! other than that printing it out seems a bit pointless!!
I sometimes find it easier to see the structure of the code when it's printed, especially if methods or blocks cover multiple pages.
I can also mark on printed paper, which is sometimes more convenient that adding comments to existing code (especially if I don't have write permissions to the code files).
As a side comment, if you intend to ever print out your source code, make sure that:
I print code out for:
That's really it.
I only used to print out source code to get a better overview of APIs and code interdependencies. I would print out multiple pages of code and spread them out on my desk :) IIRC, 2005 was the last time I did this. With large, high resolution displays cheap and ubiquitous now, I haven't done so in years. Two monitors with sizes > 20" and resolutions beyond 1600 x 1050 usually do the trick.
Not often as a developer, but when I'm doing a security audit on a piece of code I'll often print it out and attack it with my red and green pens. Red is for Bad Stuff. Green is for things I need to look into more (either look up an API or look it at in a wider context).
My 2 cent. I like very much fine printed code. Sometimes I read it instead of a novel before going asleep.
But sometimes it happens I have a good idea on how to make it better. I say to myself: well, tomorrow I will modify it and it will become a great program. But the next morning I've forgot the modifications I had in mind.
So I've learned to have pencil with me in the bed. When I notice something interesting, I make a note. But then the paper began becoming too small for all the notes or for few but long notes; I tried to write them small, very small, very condensed. The day after, I was not able to read what I've written: wasted work.
So I've learned to have the printed source, and a pack of new sheets to write anything I need to write... But the bed is uncomfortable for this, so I've started to work on the desk... and I've lost my sleep (and dreams)...
Moreover, since my programs started to grow and grow, it happens now I have no more room for myself in my house... and what a pity to have to burn all those sheets, that once were trees, maybe...
More seriously, I sometimes find it useful, (if the code is finely printed), but at enterprise level I think it is just a waste of time and sheets (and money).
You hate some piece of code so much that you gotta do something about it, you take the print burn it down and let the phoenix-code rise again from the ash
I print source code (rarely) when I need to scribble on it, usually for purposes of refactoring. I'm over 40 and can't see tiny fonts, so I can fit far more code printed on my physical desk than I can ever fit on two 27-inch widescreen monitors.
Why would someone do that? it's much harder to see the code and besides quoting:
gets outdated as soon as you hit "Print".
I did it once but I ended up throwing away the papers because I didn't understood a bit of MY own code.
NEVER DO THAT UNLESS YOU WANT TO WASTE INK, TIME, AND PAPER
On programming contests.
According to the rules of ICPC, a team of three people should write several programs using one computer. During the contest, an option to receive a printed version of your code is usually available. Printing code is invaluable: you can do a review and look for a bug in an incorrect code while the rest of your team codes another problem.