There are several goals to that:
To see that the person can code.
Don't be surprised: many programmers who come to an interview don't know how to write code. While it's indeed difficult to write code under pressure during an interview, some are also unable to write it outside an interview. If those copy-paste programmers are useless in a company, asking them to provide their own code is a good way to filter those candidates.
To see that the person has his own projects or participates to existent open source projects.
Many programmers I was interviewing had only source code they've written at work. This is a good sign that for them, programming is just a way to gain money, not a passion.
To see high quality code (or what the person thinks to be high quality code).
A non-negligible part of the candidates I interviewed was bringing code full of bugs, and by bugs, I mean clearly visible bugs such as infinite loops, dead code, etc. Nearly every candidate bringing C# code had his own style, or rather no style at all (remark: C# has well-established conventions created by Microsoft and enforced by StyleCop, a tool which integrates well within the IDE used to write C# on Windows).
A glance on the source code can tell you much more about the candidate than fifteen minutes of interview.
To check that the person is not bringing proprietary code.
I had done several interviews where the candidates were bringing proprietary code. They weren't even hiding the name of the company. One, to the question “Don't you think it's disturbing to show to a third party a piece of code for a project probably covered by NDA?”, answered: “I really don't bother, in all cases this company was lame!”.
To see that the person is able to handle or participate to a large-scale project.
Personally, I ask the interviewees to send me a piece of code before the interview. During the interview, I ask them questions, such as:
At line 27, you are using a stream without disposing it. Why? What are the two ways, in C#, to dispose it?
You have code duplication between the line 14-18 and the line 55-59. Why? How can you easily avoid it?
At line 62, you do a cast. Why?
Some of those questions are related to bugs: when I ask them, I want to know how the candidate would handle this situation (and if he would see the bug himself first). Some people are extremely bad at handling that. For example, answers such as: “It has bugs because this part wasn't written by me.” (well, I asked to bring your code, not your colleagues' one) are frequent.
Other questions are related to dark parts of the code. I was often surprised by candidates who were perfectly able to explain why they did it this way, and why a different approach would have been worse.
If you think that you may be subject to such questions, be sure to bring a short piece of code you know perfectly well: answering questions about the parts you don't know well is not easy. Try to bring a piece of code which may not be particularly challenging, but which is flawlessly written, clean and easy to explain.
If you don't think the interviewer will ask questions (but rather listen to you showing your code), bring larger pieces of code to be able to show architecture, as well as highlight technically challenging aspects.
Remember: if your projects are open source, putting the link to them in your CV can only be beneficial (unless there are reasons to be ashamed of your code).