Using a pen and paper is a shame and a guaranteed zero.
That's definitely a shame but I guess they get to set the rules.
These days it is easier to share documents electronically and being editable by computer is handy.
I've always taken the 'book publishing approach'; the author creates ( with whatever tools they want to use, including pen and paper ), the publisher / editor gets some poor sap to convert all that into the form they want. Of course, that poor sap is sometimes yourself so it's easier to start with the intention of what's ultimately required.
I'm not trying to be rude but how will comments for a 20kbyte source code looks like on a power point presentation esp if you've to explain how a program in a functional block works.
I think it depends on what you need to explain. It's rare anyone is particularly interested in a line by line source code explanation but wants to see the overview, understand the big picture, then perhaps those overview blocks broken down into some more detail. The occasional snippets of code may be included but only where it helps demonstrate a particular trick described.
For example you could describe PICAXE programming as a list or sequence of flowchart blocks -
1) Open Programming Editor or AXEpad
2) Type source code
3) Click on Syntax Check
4) Any Errors : No - Continue, Yes - Edit code, back to (3)
5) Click on Program
6) Did it download okay : Yes, Continue, No - Fix problem, back to (5)
7) Test downloaded program
8) Does it work as expected : Yes : Continue, No - Edit Code, back to (3)
9) Go "YeeHaa!", take an early lunch
You can break any one of those down into much greater detail, but not all of it has to be broken down further. It really depends on what the audience is most interested in.
It may be worthwhile talking to your tutor or having a look at some thesises (thesi?) published on the internet.