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?

+6  A: 

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.

Robert Harvey
Your programs are that *small*? ;) (Or you have one *big* wall :)
You might just do small sections.
My cubicle is bigger than yours. :)
Robert Harvey
+4  A: 

You can draw on the paper or use a highlighter, which might be helpful.

Greg Hewgill
Interesting. Do you do any these things?
No .
Greg Hewgill
+1 for the comments.
I do both these things. I also have a mobile phone which doesn't play music or take pictures. I still buy CDs. How did all these things which seemed so modern become so old-fashioned so quickly?

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.

Some good points. I worked with a guy who would print out more code than he wrote... of course he got fired.
There's a good role model for ya.
Robert Harvey

You can read it when you don't have a computer available.

Ahh, yes... but why? Perhaps those in-flight movies are too boring?
Well, not every company gives their employees notebooks to carry around, and not every company have Wi-Fi access or LAN cables in meeting rooms, and maybe simply because not everyone likes looking at the screen all the time.
@aberrant80: If your company doesn't give you a laptop, and doesn't have WiFi or LAN in meeting rooms, why are you going out of your way to help them? Change your company.
Roger Lipscombe
That's quite an unrealistic statement so I'm not sure if you're being serious.
The best way to change company policy is to vote with your feet. You are free to find another job (even in a different sector or position)
Matthew Whited
+2  A: 

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.

You should have another monitor next to your monitor for that
+8  A: 

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.

*Sigh* You don't *really* deserve it.... but +1
Soooo *true*...
Aside from a class that required a paper copy of the assignment, I believe it's the only thing I've actually printed code for.
+13  A: 

Reading something on a screen is like staring into a light bulb. Paper does not have a backlight.

In other words, it shows your code in a whole new light!
That's an *excellent* ploy to make it look like you're working... "Just reviewing my code sir!"
That's why light gray on black is the best =)
Stefano Borini
That's why I can't wait for laptops with fast/color eInk screens
Matthew Whited

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.

+18  A: 

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.

Stefano Borini
Best answer I've heard so far.
Robert Harvey
*Totally* agree. As long as their isn't an ascii art comment in front of *every single darn* function ;)
Or worse, form-feed characters in the source which put each function on its own new page.
Greg Hewgill
In Visual Studio 2010, you just hold down ctrl and zoom the mouse wheel out, and you can see the code-shape without printing.
Dave Markle
+1  A: 

I usually print it to read when I'm travelling.

+6  A: 

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?

they have /etc/passwd printed out in a book near the server... LMAO... I hope they at least were using /etc/shadow (and not printing it out)
Matthew Whited
+1  A: 

It's much nicer to read from paper than from a computer monitor (especially crt monitors).

+2  A: 

I like to staple.

I can staple every page.

Then I can hole punch.

Do you use
Robert Harvey
now I'm gonna have to burn the whole place down
Angelo Genovese
+2  A: 

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.

+4  A: 

You can debug in the bathroom.

Thats what laptops are for
I don't really have a lap. I'm too skinny.
You can also delouse in the bathroom *at the same time*
@Nosredna, I think lap size is more dependent on height than on weight...

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)

And it's cheaper to spill your coffee on paper than on a computer.
+1  A: 

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.

Nikola Stjelja
interesting. references for what you state ?
Stefano Borini
+29  A: 

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.

+1 I wish there was an annotation feature in IDEs which doesn't need to change the source.
Aaron Digulla
@Aaron Digulla - such a comments? ;)
@Oded: "which **doesn't** need to change the source". Basically, I want to be able to do the same as you can do with pen and paper: Draw figures on the source.
Aaron Digulla
@Aaron Digulla - I do understand, and annotations would be great. And in some ways, you could consider comments as annotations that do not change the code...
print-screen, then use MSPaint to write on top? :)
@John: +1, I have actually done this, though I used photoshop as I'm more comfortable with that (I can write plugins for it!)
Grant Peters
Hmmm. Need moar red freehand...
+1 It seems so much easier to work out what's going on when you can scribble all over something.
+1 In addition to the ease of annotation, a desk full of printout can show more of the code than a monitor can.
Josh Kelley
@Aaron: there is such a tool - Crucible by Atlassian. We use it for code reviews (with a single laptop and projector, as Tomas Lycken mentioned in the comments to Neil Butterworth's answer).
Stephen P
+81  A: 

No. Never.

A printed version gets outdated as soon as you hit "Print". For reference purposes, a source control system works much better.

...Nonsense. Code doesn't magically change without anybody touching it; if you're the only person editing a file and you print out the code for some reason, you're busy reading/writing on the print out and not changing the file
Michael Mrozek
@ Michael -- not meaning to be offensive, but that is a "smartass" answer. The point is quite clear in that systems change ALL the time if it is a decent system. Things never stay the same, and if they do, your system is getting old. The bigger and better the system is, the more people and more revisions it will have.
@Kerry It's not, I'm completely serious. There are essentially two different reasons to print out source code, which is why there are two types of answers in this thread. You can print source code because you want to write on the printout, show it to people, or otherwise use it immediately, and then you're going to throw it away, which is fine. Or you can print out source code and store it in a binder for archive purposes, which is obviously insane, and you should use source control. This answer ignores the former case and only addresses the latter
Michael Mrozek
Sure, you *could* print it our for those former reasons, but that doesn't mean it's the best idea. There are many tools where you can write notes that go along with something, and to show it to people, can easily be done through email, online, an iPad, a USB stick, etc. etc.
@Kerry ...or by printing it out. What does it matter if you make a static copy of source code and annotate it electronically, or just print it out and write on it?
With the "green" push in our day and age, it is a way to not use those resources. Cut down company costs. Make it easier to store revisions, collaborate with others on it, whether they are in the next room or the next country. Easier to transfer to other locations.
@Kerry Sure, printing it out isn't necessarily the best way, but it is *a* reason you might print source code out
Michael Mrozek
+13  A: 

No, it is a waste of paper and time. We rely on a code repository and backup systems.

+1  A: 

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!")
Tomas Lycken
+24  A: 

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...

Martin Milan
+1. Sometimes it's easier to understand something when you're not sat in front of your workstation as with the rest of the working day :-)
I know you meant "I hope it wasn't me", but I read "another (hopefully) developer" more like "I hope it was a human".
Jon Purdy
This is the same (and only) reason I end up printing source. There's no "squiggly arrow from here to there" button in VS2010.
+1. Source code comprehension is much easier when it's printed and marked up with my pens.
Paul Nathan
+14  A: 

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.

+1 for that link alone
would not want to know how you dispose off the code, given that you are at that "place". :-)
@user I guess it depends on the quality of the material ; )
+38  A: 

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 absolutely agree with this. It's the only justification I can think of for priting code though.
Surely you could do this from a terminal in a quiet area (like an empty meeting room) with all non-IDE apps shut-down (with the benefits of code analysis tools and similar)? I can't see the justification for printing reams and reams of paper you'll barely be able to process. Save trees - buy a laptop.
@annakata For atypical review, there will probably be half a dozen or so developers taking part - you can't fit them all round one laptop. So you will need multiple laptops (with WiFi, which not everyone has) and soon people will be reading their mail, using SO and worst of all editing code just as they would be if they were back at their desks.
We used to do this 7 or 8 years ago but lost the habit. Part of the problem was that we couldn't find good software to format code for printing, and part was that no-one really liked working to hard line limits. Now there's good diff tools it's just as easy to do this all on screen really. There is something theraputic about covering a page in red pen though.
@Rup This is one reason why many coding standards specify that lines must be broken at column 80.
@Neil, What stops your team from installing a projector in the meeting room? One computer, a screen everyone can easily see, and one meeting leader who can make sure that only the IDE (and maybe other relevant apps such as diff tools) are enabled.
Tomas Lycken
@Neil why is a review typically taking so many developers? If all code is reviewed by so many people, everyone's going to spend _all_ their time reviewing. Overkill!
@Thomas Cost? Projector availability?
@John I do not suggest that all code is reviewed by the whole team, or even by part of it. As a manager, I've normally reviewed all commits myself, and then instituted reviews for for complex or contentious code. And you know what they say about bugs and many eyes...
I dont like code on paper which is supposed to execute on computers! :)
Praveen S
@Neil... Cost? A few hundred bucks is a big deal when the cost of a few developers in a room for a couple of hours is probably more.
@Rup ... +1 for the red pen. Striking bits of code out with ink somehow feels more permanent.
Chris J
I'd buy the projectors myself, if only to destroy the 80-column rule forever.
Jeff Sternal
@Jeff The 80-column rule simply makes the code more readable, no matter where it is displayed.
I prefer to perform a code review with a diff tool, so a workstation is required.
Surely code reviews within the IDE are much easier, especially when you can jump straight to a function from the place where it's called. Try that when you've printed out dozens of pages and have to look through them by hand to find the correct function.
@Jeff: The 80-column rule is good! Makes it possible to put 2 or 3 source files on the screen at once.
Donal Fellows
@Donal - I guess opinions vary. ;) I personally find that vertically compact code is far more important than horizontally compact code. (To say nothing of the bizarre formatting and naming choices people often make to conform to the 80-column rule.)
Jeff Sternal
Rarely do I print source code, but occasionally it is useful to print a very small segment of a class definition or some other snippet to stick on the cubicle wall for reference. (Rather than buy a third monitor or constantly alt-tab to review it.)
@Neil: Every other answer in which you've been stuck in the jurassically-old way of doing things I've been able to forgive and still respect you as a great programmer, but this is absolutely absurd. I seriously hope you do not actually do this.
BlueRaja - Danny Pflughoeft
@BlueRaja "jurassically-old" presumably means something you do not agree with. Luckily, I don't care what you think, and 40 or so people seem to agree with my "jurassic" opinion.
Sorry, totally disagree. You can't do any kind of analysis (unit test, code coverage, does it compile, etc) using paper. You could only really review POCOs properly on paper. Your far better off revewing the class/UML diagrams on paper and doing the actual reviewing of code inside Visual Studio. Plug-in tools like Pex immediately spring to mind.
Simon Hughes
@Simon None of these things "unit test, code coverage, does it compile, etc" is what a code review is supposed to do. And I (and lots of other people) don't use Visual Studio.
@Jeff: Vertically compact is good too, but it's really convenient if you can see several things at once. It's nice to be able to see lots of things at once, and intellisense-like things are a poor substitute. Give me that fourth monitor and I'll just have *more* things open at once!
Donal Fellows
We used to, and I think it's best, to do code review on the computer together with the writer of the code.
I truly agree with Neil. It don't only remove all the disturbing elements which is present at code reviews, but it's also better to read on paper then on a computer screen.
having a hard time believing this is not satire. are you all really serious??!
+8  A: 

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.

Petteri Hietavirta
+5  A: 

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.

+1  A: 

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 ...)

+7  A: 

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...

This is the only reason I have ever printed source code--required by the college instructor.
+1 I could never understand it either
Agree... my old college instructor first made us write the COBOL programs then type them in on an AS400..then print them out to review any mistakes.. I still have nightmares
+1  A: 

Nope, dont need to

+1  A: 

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.

Praveen S
+2  A: 

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!

+1 for "where has the time gone"
+2  A: 

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!

Daren Thomas
Very good. Some times, print your code for do some math sometimes keep your system healty thin
I write pretty small. The e-ink version had better support 4-point scribbles. :-)
Donal Fellows
+1 for sneaky reference to Fermat's last theorem.
Mark Robinson
+2  A: 

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.

Chris J

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.

My firm doesn't print source because we like to be green. We don't print documentation because we don't have any. :-(

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 :)

There are limits with screen size but that's the reason 24" monitors (or larger) got invented.

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.

+7  A: 

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.

This is the only reason I have found for printing code, fortunitly I have not worked with spaghetti code bad enoughto warent this for a long time.
David Waters
But you could just use a UML round trip tool to visuali… sorry, no I just cannot say that with a straight face! :-)
Donal Fellows
Actually storing valuable data on paper is not that a bad idea:
But then you have to protect it. Is this a new market for the Space Bag?

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.

+11  A: 

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.

Please show me where I can get a monitor(s) that will let me see 20 pages of code at the same time (print our on a table/floor does this easily).
@bigredbob: Perhaps the software should've been designed and written such that it's NEVER necessary to see 20 pages of code at the same time.

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.

Robert Gowland
Print a single significant page... if it's symbolic, keep it symbolic.
Did someone down vote this on ethical grounds? I'll go plant a tree right after, I promise!
Robert Gowland

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 [] 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).


i print my backups :)


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.

Moses Ting

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:

  1. For a court case I was consulting on.
  2. As a bit of reference material for myself when teaching a friend programming.
Alex Gaynor
+1  A: 

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!

+1  A: 

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.

+5  A: 

I have printed code to make red pen marks all over the pages, so the client thinks I am worth my billable rate ;-)

+1  A: 

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.

+1  A: 

Three cases where i print code (The two first it is code but not mine) :

  1. When disassembling code to understand what happens and be able to annotate the paper. IDA is pretty handy but when the code is really complex pen and paper are still useful. Too bad that i nearly never have to do low level stuff anymore.
  2. When reading .Net code generated from Reflector... You can't imagine what code smells and horrors could be found in assemblies provided by subcontractors or hardware manufacturers before you have seen it. When printing the code it still sucks but at least you could read it under the sun with something fresh in hand.
  3. When someone that isn't a programmer but know programming basics need to check some algorithms (Implementation of some complex math formulas for example) or have some hardware outputs that he want to debug. I print the corresponding methods/classes and they could ask questions / take notes if they don't understand some part of it.

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.

+1  A: 

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.

+4  A: 

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.

Sam Bisbee

What else are you gonna do on the john?

Um, I would have thought that was obvious...
Mark Robinson
+1  A: 

If I do print out source code, it's not the whole thing. Maybe a function or method, but usually nothing more than that.


Printing is for DB diagrams not for code ;)


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.

+2  A: 

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...

Converning the pins and threads approach: Very cool idea, I can imagine that really helps. Anyway, there are (digital) tools for this kind of task, which may produce nice graphs with boxes and arrows... which are a great thing to print :)
Brian Schimmel

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.

Don't you have electronic backups?! In the event of a harddisk crash, do you expect them to retype their code?!
Mark Robinson
+1  A: 

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.

Gilbert Le Blanc
The question is what will die first: the attitude or the forest? 500k lines printed seems like a horrible, unhelpful waste.

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

Radu C

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?

UltraEdit ( prints nicely.

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.

Matt Hucke

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.

+1  A: 

I print it out in a few cases:

  • When I need to concentrate on a concept I am having a problem grasping.
  • When I need to reference some complicated code and it is longer than a screen length.
  • When I either need to show a co-worker something (either for difficult bug or for examples).
Mike Wills

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.

Kristopher Johnson

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.

Ates Goral
+1  A: 

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...

+1  A: 

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!!

what was the topic of the dissertion / what was the code about?
Click Upvote

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:

  • the line widths are reasonable for most printers (e.g., somewhere between 80 and 120 columns wide maximum);
  • tab widths are consistent (8, 4, 3, whatever, just choose one width for all printable source files).

I print code out for:

  • Programming competitions
  • Professors who want hard copies of source

That's really it.

Wayne Werner

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).

Dan Ellis

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).

+1  A: 

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

Devil Jin

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.

Norman Ramsey
+1  A: 

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.


+1  A: 

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.

Pavel Shved