Well for really big projects, you'll need something like UML to sketch out the relationships between the major components of your system. A lot of UML is only applicable for certain kinds of problems, so don't feel weird about only using a couple (out of the dozen or so) of diagrams. It doesn't even need to be that formal, even a couple of rough sketches could be very useful.
I aim to pitch one line of pseudo-code would expand to 5 to 10 lines of actual code. Don't go into too much detail in the first instance, you can always refine later. If you have more than 5 lines of pseudo code for a function (25-50 real lines of code), then perhaps you need to split that up into separate functions as well.
For a group of related functions solving some particularly complicated algorithm, you might want to include more detail in a discussion format, or site references to books/the web.
Also be wary of going into too much detail. If you want to sort something, then just say
"sort the data", rather than trying to list all the actions of say quicksort. You're just going to use the library code anyway, so no need to labour the point.
When it comes to writing the code, it should look like this
Code:
/* Line of pseudo explaining the purpose of the function */
int aFunc ( type param ) {
/* Line of pseudo */
...
...
...
...
...
/* Line of pseudo */
...
...
...
}
That is, your pseudo-code should form the inline block comments of your actual code.
pseudocodes
