You should try to imagine that you are working in a professional programming context. We aim to help you to develop (in the long run) a programming style that will promote quality in the software that you produce. You may be working on your own, but it is more likely that you will be working as a member of a team: therefore your programs must be readable and understandable to your co-workers. You may leave your job, or fall under a bus: therefore your programs must be readable and understandable to the programmer who takes over from you. It may be several years later that a customer comes back to ask for enhancements to be made: therefore the programs must be readable and understandable to whoever is assigned the task (even if it is you, it is surprising how quickly you will forget exactly how a program that you have written works - a few weeks is enough to obliterate most of the details from your accessible memory).
So, the general principle is
This is an important test of your communicative ability - being a good programmer is not just about hacking out code that works, and it's not just about using tidy programming techniques (although there's some fine judgement required there too). In many ways it is no different in principle from the skills involved in writing an essay or giving a short talk: you have to imagine yourself in the reader's/listener's position and ask yourself what you would need to help you understand what is going on.
As we will see, it is usual to take into consideration
Note that we would like you to produce programs during assignments as if you were working in the professional context. We will be assessing the presentation as well as the actual code. (Also, obviously, if the program is well presented then the markers will find it easier to understand and so give credit for what you have done.)