Different assignments permit different levels of collaboration. These are the main ones.
Occasionally, but very rarely, I will give assignments that are fully collaborative, where two people will work together and turn in one solution with both their names on it.
Some assignments (e.g. exams) are not at all even a little bit collaborative, and you can't discuss them with other students at all. You can't even discuss them with people who aren't students. The only person you can talk to about them is me (and the TA, if there is one). Typically I will still allow consultation of inanimate sources, such as books, notes, lecture notes, and the web. You still ought to document sources other than course materials---a good habit to get into in any case. Nevertheless, direct copying from any of these sources is still plagiarism, and not allowed.
It should be noted that getting someone else to give you their notes or old exams or solutions is still not allowed, even though the notes themselves might be inanimate.
"Lightly collaborative" assignments---which will be most of them---are meant to be written individually, but this does not preclude discussing the ideas with others. In fact, I highly recommend you work together on the homeworks; but except where noted, I will expect that everything you hand in will be written by you. A good model would be to work out the problems on a whiteboard with someone else, erase the board without copying down anything, and go write out the homework. Remember: work together, but write alone.
Debugging is always a tricky case. Disallowing debugging help gives rise to quite unrealistic evaluations, so I don't want to forbid it entirely. On the other hand, it's easy for "debugging help" to turn into "imparting algorithm and design decisions", which is Not Acceptable. So on the "lightly collaborative" assignments I allow a limited amount of debugging assistance: you can help other students find bugs, but you can't help them fix them.
Good: "You have a fencepost error in line 73." "The variable foo is never getting initialised."
Borderline: "Should that semicolon in line 47 be there?" "That method probably ought to be virtual."
Bad: "You should use a map<int, int> there, not a vector<int>." "You need to use a separate counter variable to keep track of this."
Really Bad: "You need a for loop here with an iterator through the map, that takes each key and..."
What you can do, is if you see someone doesn't understand a concept, go back over that concept in the abstract or using examples from lecture or the book, or made-up and unrelated to the programming assignment at hand.