For a five-line sequence, we don’t need a lot of structure. We can try things and revise on an ad-hoc basis. Have fun.
With something more complicated, we often don’t know where to begin or how to proceed. That’s writer’s block for sure. Here are some tips to get going.
Break the task into pieces
Most ideas are procedural, that is, one part happens after another and another. Then it repeats. Think of the parts that need to happen.
Make a Cheesy Version First
You know all the embellishments you want. Before doing that, take it down 5 notches and demonstrate just a piece of the functionality. Watch it work.
It’s okay to write bits of code that you’ll soon discard when the embellishments replace them. The total time will not change much. In fact, it will probably go faster.
Write pseudo-code
Although sequence statements -almost- look conversational, they tend to be more exacting than the way we would describe to another person what is happening. Try writing down all the steps in more basic terms, without every inner detail. We can add that later.
Such high level descriptions are often called pseudo-code by programmers. Of course, pseudo-code will cause errors if typed directly into Sequence Composer. But we can turn them into comments (with //), so they can guide us in writing the code to follow.
Test each piece separately
Don’t write the whole thing before testing it. In some cases, you want to follow other examples you have seen: Copy and paste. Test it. Make your modifications. Test it. Add more. Test it. If things get messed up, you know exactly where it happened.
If it takes time to test pieces, test each piece in a separate file. Make changes to get the right look. Combine them in a new file after they look good.
Use relative time stamps
Working with separate pieces and putting them together is much easier with relative time stamps. They don’t need to be recalculated. As code becomes more than say one page long, this practice becomes a necessity.
Comment amply to save time later
Comments are free, they use no space in the Morsel and your PC won’t notice enough difference to ever matter. Don’t hold back.
The code needs no comments. It knows what it’s doing at each statement but has no idea where it came from or where it’s going – until it gets there. The comments are only for us. They stand outside of time, so to speak, being able to say something about the process and what is happening, what led up to it and what will happen after.
It’s easy because you’re writing to yourself, your time-traveling future self who (an hour from now, a week or 6 months later) has no idea what code you wrote, or remembers only pieces. This is your chance to set that fool straight and make your code live on.
Comments are also essential at highlighting where the code can be easily modified for different purposes. Again gratefully appreciated by any number of future selves.
Use descriptive labels
Each label in a sequence needs to be different. So we could name them A001, A002, and so on. But we have an opportunity here: We can make the labels so descriptive that they help document the code. Wow, that’s like including a comment, but easier, because we had to make up a label anyway. Short, cryptic abbreviations are tempting but their meaning is soon forgotten. There is no limit to the length of a label.
Use define
Here’s another one that uses no memory in the Morsel (the others being comments and time stamps). You can’t Go to a define, the player passes through it like it’s a ghost, stopping only at the first real statement. So you can use defines without reservation.
Defines allow numbers to look like names, the values they really represent. A lamp that is at 66% is one thing, a probability of 66% is another. If those values represent a lamp with a 3-way light bulb set to medium and a spark repetition intensity, we should call them that. It sure won’t be obvious later:
define bulb3WayMediumHi 66%
define sparkRepeatIntensity 66%
Defines also allow us to group together the values we might want to change together. If sparkRepeatIntensity needs to be adjusted to look right, it’s so much easier to have it collected all in one place, rather than find the dozen cases throughout the code.
There are other uses of defines, since they can hold entire statements or groups of statements. That can help too.
Whitespace is meaningful
Usually, pieces are copied and pasted one after the other. Add some carriage returns (whitespace) between pieces, so you recognize them when scrolling through the sea of words.
Don’t get too complicated too quickly
There are a lot of cool things to do with just a handful of code. And, that’s where we need to stay while we are learning the ropes anyway. A hockey stick curve should be avoided. Don’t write 10 line sequences, then 20, then 30, then jump to 1000: We need to stay in a comfort zone and stretch it gradually to larger sequences. If we ever even need larger sequences.
We don’t want a tax-law-sized file that we at last begin testing only to encounter a problem that we cannot figure out. What to do next? That is the most disliked part of programming and the twilight zone like irony is that a person can spend all their time here. What a rotten deal. Better if we had started simple and tested a little at a time along the way.
Summary
Perhaps these tips, once learned well, amount to nothing more than a common sense approach. That is good! Now we can concentrate on what could well be uncommon and never before seen: Our next effects!