It is common for students to start with a mix of very small coding projects written from scratch and larger coding projects written within a provided skeleton. Eventually, however, you need to move to writing larger projects without a skeleton, which can be a daunting thing to do especially on your first time.
This is my effort at making that less daunting.
When faced with a big open-ended task start by asking yourself what’s one thing the program has to do that can be done on its own?
Maybe the answer is segment a byte into bits
or read a 4-byte big-endian number from a file
or split a string into lines of text
. Write a program that does just that one thing, nothing else. Test it. Fix it. Test it again. Celebrate that you’ve got one thing working!
Then ask yourself what’s one additional thing it needs to do?
Sometimes that’s something you can just add, either on its own or fitting nicely into what you’ve already done. Sometimes it’s something you can build out in its own little test program, then integrate later. Sometimes it’s something that requires you to first refactor your code, changing how it is doing what it is already doing so there’s a good place for what you’re adding.
And so on.
I have written programs of several hundred lines in one go, but that’s a very risky thing to do. Almost every program I’ve ever written was a small delta on a program I’d also written.
If (a) an algorithm is described (either by me in the course material or by you when thinking about it) by referring to chunks or messages or pixels or code points or some other thing, and (b) you don’t have that thing as a data structure/object type in your code, then (c) you are doing things the hard way.
Perhaps even more importantly, if you have something you would refer to in describing the code that you store in several different data structures at the same time, you’ve set yourself up for confusing bugs. Should the thing we describe as a character
be an integer or a list of bytes or or a custom class? It may be one of those is better than another, but the worst of them is still better than some kind of chimera mix-and-match. One structure for one concept.
In principle, any piece of code can be factored out into its own function. The following are all signs that a piece of code should be factored out as a function:
If what the code is doing has a name, put it in a function with that name.
If you wrote code by copy-paste-edit, you probably should have moved it into a function (or possibly a loop) instead.
If you ask yourself should this be its own function?
the answer is generally yes.
See also out text on debugging