Speaking of good design, I'd like to suggest a few things:

* For selecting, use BOTH 2nd and Enter. That way, you don't have any crazy confusion.
* For info screens (like "High score!", etc.) 2nd, Enter, AND Clear. I've ran into games that would seem to use 2nd to continue on, but I end up having to press some other weird button to continue on, almost thinking that I've crashed! The same applies to the above suggestion.
* AxesOff and AxesOn is a must, as well as FnOff. For the first part, not everyone turns off their graph axes, nor should you assume that they know how. DO IT! For FnOff, no one wants to see a graph of y=x^2 unless you are making a quad solver (in which there are thousands, mind you ). As for FnOn... beware that it *might* cause a graph to be drawn (if there is one). I'm not too nimble on preventing that, so you're on your own. (You can try my code below though to see if my guessing works!)

For those BASIC programmers out there, here's what I do every time:
ClrHome
FnOff
AxesOff
ClrDraw
"You're done! Have fun coding! :)
"(code goes here)
"OK, time to give the user their graph back!
ClrDraw
AxesOn
ClrHome
FnOn
ClrHome
For FnOn, beware that FnOn turns all of the functions on. You may wish to add "1" to the end of FnOn.
The code snipplet above is designed to (hopefully) prevent the user from seeing the graph, and therefore hiding the fact that you're using that place to draw.

As for Axe programmers - although this doesn't apply to you, I've seen some programs that have forgotten to ClrHome and ClrDraw! Unless you do an interesting homescreen transition (I have done and loved that a LOT, but most of the time if it isn't needed, don't do it), you should ClrHome. Finally, ClrDraw might be "corrupted" - some other program may have made a mess in there, or like some shells, leave the screen in the buffer. Erase it! ClrDraw^r is also a must if you use the backbuffer as well.
* Mental tip: never assume that the user will be like you, nor will they be as smart as you! All of the above stuff basically follows this rule! If you are deviating from the standard keyset, etc., include help inside the game. Give really simple directions, keymaps like "2nd to jump!" and "Clear to exit!". This will ensure wide acceptance and enjoyability of your game!
* Mental tip #2: never assume your environment is the same as your target user's environment! This pretty much encompasses everything above, but I thought to mention it if you already haven't realized it.

If there's anything that I've gotten wrong, feel free to correct me. I haven't done any serious BASIC game dev in quite a while... (Especially those involving the graph screen!)
I think this topic should be stickied; it would be very useful to new and existing BASIC/Axe devs.

About using both 2nd and ENTER the problem is that sometimes the programmer might be running extremly low in the 8 KB code limit (where every byte matters) and in BASIC speed. Every 0.05 seconds lost on an extra instruction/check/command can matter in long terms.

Yeah true. Personally, if possible, I think it's best, before the game starts, to store the graph settings, then apply appropriate game changes, then once exiting, recall the old settings. The issue with AxeOn is that someone might already have Axe turned OFF so if they're turned ON everytime he quits the game he might be annoyed as much.

One suggestion more, if you use the graph vars: StoreGDB0 (the last, is least used) and afterward RecallGDB0

Wait, I thought Delvar frees up memory. Am I missing something here? Also, for anyone who doesn't know, thanks to a bug in TI-BASIC itself, the following is actually legal code.
:DelVar ADelVar BDelvar C
This can be continued ad infinitum until you run out of memory, a very useful misbug that shaves a net byte off the two byte Delvar. Please note that you're not actually truncating DelVar, but the ommission of a newline/: saves an otherwise inevitable byte.

Oh. But that's why I keep all my DelVars in their own program.

That way, instead of chewing up my memory 50 times by putting a whole bunch of DelVars at the end of each program, I only chew up my memory once by putting them all in one program and having the other programs call it when they end. I also use it at the beginning of each program to set all the vars to 0.

The problem with having BASIC programs in multiple files is that if a user accidentally deletes one of the supporting files then the program stops working. It is even worse when BASIC progs require you to download pic variables because those are so easily corrupted by other programs.