Unit testing! Every language I've seriously If you write extensive unit tests and they all pass, it's more likely that your program will work when all of the little bits are added together. If you modify something and a test case breaks, you know what's wrong, or at least near where the wrong thing lies in code.
Not that I'm saying that it applies here, but when I wrote my Rubik's Cube Emulator for the BBC model B computer at college (yes, that would place it firmly in the '80s, for you history buffs!) I wrote it in sections. The display procedures, in one, the slice-moving procedures in another, the human interface in another, code for storing user-defined procedures[1], and and I'm sure there were at least two more (but can't work out what they were). Having written them (inclusive of some test-lines) them all in BASIC (yeah, yeah, but the alternative was assembler[2]) I then had the challenge of putting them altogether. I found I could effectively "export" a listing to tape[3] and then re-import it through the CLI as if I was re-typing it all in again, by hand. (Just had to ensure that I re-shuffled the line-numbers so they didn't overwrite each other. But that was what the RENUMBER command was made for, so no problems there...)
Went swimmingly, until.... Error, error, error... Memory full. Ah, the limitations of 32Kb of RAM trying to containing (probably, if my memory serves, only in the lower half of it!) the huge amount of to-be-interpreted code in (YMMV) human-readable form. Poor little thing just wasn't capable of it.
The obvious solutions (mentioned in the project report) were to have perhaps written significant chunks of the code in Assembler or it might well have fit into a new-fangled BBC Master's memory space (128kb) with almost no core code re-writing necessary. I'm sure, now I come to think of it, I could also have introduced code optimisations. Perhaps generated the "Net" and "Perspective" display of the cube procedurally, rather than storing the line and square coordinates in a set of DATA lines, although not sure what I could have done with the sequence-storage bits, I was rather proud of how I handled that, as I recall... though who knows what I'd think of it these days if I saw it!
Anyway, I submitted the exercise anyway, and mentioned the obvious solutions in the write-up, and whether that helped or harmed my grades I can't tell, but it couldn't have done too much damage given the grade I got...
Erm, yeah. Sorry, that looks more self-aggrandising than I had intended[4]. You almost certainly won't break the memory limits, although watch out for "merging errors" of other kinds, is what I really meant to allude to when I started this post... Perhaps that should be the tl;dr; message you take away from this.
[1] The interface was text-entry, so type in R+ to twist the right-hand side, so I was allowing the user to store a number of their own sequences. Which reflects, pretty much, how I personally solve the Cube.
[2] Which would have probably avoided the main problem I eventually encountered, so maybe I should have done, in hindesight
[3] C90 tapes. Or C45s or C30s. I wonder how many Mb... possibly even Kb... they would have stored? Probably easy to work out from the baud rate.
[4] Perhaps I should have instead told you how I absolutely
hated the language Ada, instead. Designed (or at least taught to us)
specifically with modular design and testing in mind. But maybe I'd just been burnt by my prior experiences, because I absolutely detested its format. Never had any problem with Pascal (which at least became useful, later on with a bit of OO knowledge add, in getting to grips with Delphi), which I learnt in-between the two others and was my first experience of a proper compiled higher-level language, but then again there was more of a "try it and see!" philosophy in those lessons. Don't talk to me about COBOL, though... Wasn't even my class, I was just helping someone else out who wasn't that good at using computer keyboards. Sometimes wish I'd kept it up, though, and found a way to monetise the knowledge in the whole Y2K run-up. Until I remember how godawful it was. Which is perhaps the point.