First Rule of NXT-G: Don't rush the editor. When you are inserting a block between existing blocks, you can click & drag it in to position so the 1x3 "shadow" shows in the right place... but don't actually drop it until the editor makes room for it. For reasons unknown, the editor seems to get "lost" most often if you rush it, and assume that it knows where all the drops, clicks, and releases in an editing sequence were.
Second Rule of NXT-G (&, really, everything else on a computer): "Save Frequently, Save Often ". Because you never know when something you did might pervert something that was working before, or when the editor might crash. Don't save over working copies with the same name, but save "new versions" of programs (& My Blocks!), so you can always backup a step or three.
Third Rule of NXT-G: Use My Blocks. These save huge amounts of memory, promote good coding, make things more readable, etc. About the only bad thing I have to say about My Blocks is you can occasionally (OK, I'm the only one I know who's done this) get them so they seem "broken" in the editor, but the compiler will still produce perfectly good code from them; that looks bad but seem to work fine. As far as learning to program, I'm beginning to think My Blocks promote reusable, self-contained code more than most text-based languages do.
4) Switches look great in "flat" form - now get rid of them. The "tabbed" form is both more useful (you can wire in & out of it in tabbed view, and can have more than two states) & more stable (possibly because it's much closer to how NI does this in LabVIEW, while the "flat" format may be a special adaptation for NXT-G only).
4.1) When wiring within a tabbed Switch structure, the wiring works fine in the "first" tabbed field (the "true" field of a logical Switch, for example), but does funny "straight wires to infinity" things in the other fields. You can wire up things on the sequence beam behind a Switch, and then select the entire thing (wires too) and drag it in to make your life easier.
this needs a picture
5) Don't use variables when a wire will do. I know every one of us from text-based languages finds this hard to handle, but NXT-G handles wiring values forward better in some cases than it does actual variables (among the problems: all variables are global, and long variable names aren't visible).
6) When wiring, first give yourself plenty of space in Switches & Loops (the old "crowbar & pin" routine). Do it once, and you don't have to do it again. Then use wires in ways that make sense to you (not just "hook up two points"). Clicking at an intermediate position allows you to "Tack" the wire to that point, and bend it another way along the next segment.
7) Try to resist the multiplication of sequences (tasks) every time you think you need to do "something else". First, that slows things down and often isn't needed.
Second, while NXT-G is pretty good on editing the first sequence... it's much poorer on the second, third, etc. Likewise splitting off a sequence from mid-sequence can work great if it's the last thing you do, but if you add/subtract any blocks ahead of that split later... things can get decidedly odd. Avoid if at all possible.
8) Debug with blocks that make your life easier, not harder. Below are two My Blocks that end up in nearly every program I write, because they're easy to use, and therefore make debugging insanely easy as well, PrintNumber and the block it calls, Printline
Note these are not complex or difficult My Blocks - in fact, you might think why bother at all. But with PrintNumber, I can drop a single block and that's all I need to get labeled, formatted numerical output on the LCD. Nothing earth-shattering... but it makes debugging easy instead of a task. And by having one My Block that calls another, I can make sure that these blocks only exist in memory ONCE, and all my simple screen prints are done through them. Saves memory, and the only cost is that I can't have two parallel sequences drawing to the LCD at once (and if that happens, actually, one just waits for the other, so 9 times out of 10 you don't even notice it).
Simple Sound blocks that "beep" at a different tone are another good example of debugging.
9) Option-dragging (on the Mac, Ctrl-dragging on the PC) an existing block (or series of blocks) clones them, with all their internal settings preserved. In other words once you have that "Motor B" block on the programming field, you need never go to the pallet to drop a new one and reconfigure it yet again, just "clone-drag" an existing block.
10) Have I mentioned "Wait for the Editor" yet? And if you get tired of the editor taking so blasted long to shift things, and all the icons in the map view in the lower right-hand corner look like single pixels... see Rule Three (but before you do it, use Rule Two again).
11) The great Copy-Paste issue. I don't know why, but I've not had good luck with this. However, Option-drag (Ctrl-drag) has been just great. So the result is the only time I personally use a Copy-paste type edit is when I'm taking something from one sheet and trying to get it into a second, different sheet.
12) Oh, and for designing those My Block icons, you can drop multiple overlapping icons, as well as resize them. Deleting an icon however had me stumped for a very long time. On the Mac, you need to select the icon you want to remove, and hit fn-delete ("function delete"). Actually still the only use for the "fn" key on my computer I've ever needed. (just "Delete" on the PC)
13) Incomplete sequence beams through a Loop & other odd structures. Ever had a Switch in side a Loop, and for some reason the sequence from the end of the Switch doesn't reach the tail of the Loop? This is a sign that the editor is starting to miss things. One way to fix it is to grab and pull free the entire Switch, and then replace it (being careful to follow Rule One above), and you'll find the editor has "found" the connection again. Likewise sometimes deleting the last block out of a Loop (particularly a Loop set to trigger on a sensor) will result in a Loop with no internal "space" to seed block into. If that's the case, delete the loop and drop a new one.
14) Undo for Mental Health: In general, if something looks wrong... assume it is. Either re-do it (following Rule One ), or use the other fantastic hidden tool at your disposal, "undo" (either from the edit menu, or the keyboard shortcut). This seems to work really well, even undoing the polite "rewiring" NXT-G sometimes (often) tries to do for you.
15) You can't wire into a Wait (to have the program set a condition that wasn't know at compile time) or a Switch... but you can always use Compare Logic blocks to come up with a condition, and set the Switch to select on logical, or wire a value into a Loop that does some internal checking to produce a logical that controls the Loop. Honestly, I think the default dropped state for the Loop and Switch should be "control on logical", as this is such a useful concept... and avoids some of the issues that crop up in #13 , above.
16) Clipping wires: selecting a wire and hitting delete not only removes it, but every wire attached to it, not just annoying but it can make you loose track of where the wires were coming from / going to. But if you click on the downstream (output) end of a wire, only that little branch is removed, preserving the rest of a multiply-branching wire. Oh, and while we're discussing wires (again), if you have a wire with a "bend" in it, but it's not the way you want it ("up and over" when what you need is "over & up"), just tap the space bar.
17) When no block is selected, the "1", "2", & "3" keys will select the pallet you want forward. Also the "tab" key cycles through the tools.
18)
If possible, don't mess with the directory structure. NXT-G is really
good about finding things (My Blocks, for instance) that have been moved... but
not always, and searching takes time, especially when you open a program.