Assuming your code headers really DO look sort of like this - I’m glad I’m not the only person who injects humor into their headers.
From Beet the Devil:
Book 6 - Book of the Puppy
Part 1 - This Is A Puppy
Part 2 - The Puppy Goes Places
and you can find the following headers in the One Eye Open code (very spoiler-light, but potentially spoilery):
Default Messaging Sometimes Sucks
...
Help! I Need Somebody!
...
The Hallway Will Eat You
...
Your Love Is Like Medicine
...
Ian's Room
Not Confetti
Confetti
Everything Else
...
Dangerous Button
...
An Elevator That Works From The Inside
An Elevator That Works From The Outside
I can tell when I am getting frustrated with having to duct-tape together new actions as workarounds for Inform not just doing the thing I want it to do, because I’ll start calling them things like “whoregobbling.”
“C***punching is an action applying to one visible thing and requiring light.”
That’s more rage than humor though I guess.
ETA: Oh man I need a Section: I Couldn’t Figure Out Where Else To Put This so bad.
It had never occurred to me that there might be non-AIF writers with NSFW source code. Goodness.
Section: I Couldn’t Figure Out Where Else To Put This sounds brilliant. I usually shoehorn parts like this in weird places and then misplace them, and then rearrange my entire source code and break things.
Seems that along with “programmers’ handbook”, “book of examples” and all sorts of tutorial, there’s a part of I7 that could use a guidebook: “How to organise your source code”.
Seriously, though, this thread is humorously bringing together similar experiences in various authors - the pain of source code organisation.
One of my I7 WIPs has a section called “Stuff That Might Break Stuff” and another commented out section called “Stuff That Is Totally Broken And I Don’t Know Why (ask Zarf)”.
I could definitely do with that guidebook. My current work in progress is just one long block of text without chapter headings or anything. It’s a horrible mess and gets worse every time I add anything.
For whatever it’s worth, my organization is generally as follows (whether it’s volumes or sections or what depends on the size of the code):
1 - Settings and set-up stuff. Use options, memory settings, and other fiddly stuff.
2 - General world model. Rules about how the world will work in general. If there’s a conversation library, if I’m introducing a special mechanic for fire or liquid or whatever, etc. If there are multiple complicated features, they get subsections. Rules that go with general kinds are listed alongside the kind.
3 - Map specifics. The rooms and the objects in the rooms. Rules that go with specific objects are listed beside the object.
4 - Conversation and/or scene stuff. These bits are the bits most likely to depend on something having been defined previously, especially conversation quips, which may mention subjects previously established.
5 - Test scripts and not-for-release commands.
I also frequently write in the chapter headings before I actually write the code – the headings then serve as an outline or reminder of what I’m going to need to implement later. Sometimes I will put asterisks in headings that aren’t finished yet, so that a glance at the contents page will show me what still needs to be filled in.
I thought I renamed lots of rules to something funny. But I guess I did not. Still, if a lot are named similarly, I think the following could be useful for debugging, if only to make searching for that bug when you type RULES feel less demoralizing.
check going nowhere (this is the why you gots to be runnin into wallz rule):