Avoiding Spagetti

Yeah, yeah, I've heard it all before, "I can read my code just fine", "nobody else needs to read it". I've even said some of those things myself. Y'know what? You're full of it. ^_^ Making your code clean and readable will benefit you even if you're the only one looking at it. Especially when you're returning to it after a period of absence. I should point out that a great many of these aren't specific to any language, while some are centred around VC. So! Without further adieu, the rules.

1) Indentification

Indent code in loops! It helps.

for (i=0; i<5; i++) { Initchar(i);

givexp(i,500); GiveItem(i,5);

}

While this fragment is small enough to classify as "legible", 10 lines of code like this will reduce an innocent passerby's mind to mush. Putting one command per line and indenting helps immensely.

for (i=0; i<5; i++)

{

InitChar(i);

GiveXP(i,500);

GiveItem(i,5);

}

ooh, purdy. Now you can tell what's in that loop instantly, just by looking at the indentation. It's particularly clear when you have several levels of nested if's, for's and switches in a complex function.

void Text(int font,string name,string s)

{

int x1,x2,y2,i;

int y1;

int numlines;

numlines=WrapText(font,s);

x1=5; x2=screenx-6;

y1=screeny-8-(fontheight(font)*numlines);

y2=screeny-6;

UnPress(0);

b1=0;

while (!b1)

{

Render();

if (strlen(name))

{

DrawBox(x1,y1-fontheight(font)-8,x1+(fontwidth(font)*strlen(name)),y1-8);

GotoXY(x1,y1-fontheight(font)-8);

PrintString(font,"‚"+name+"~");

}

DrawBox(x1,y1,x2,y2);

for (i=0; i<numlines; i++)

{

GotoXY(x1,y1+(i*fontheight(font)));

PrintString(font,wrapped[i]);

}

ShowPage();

UpdateControls();

}

UnPress(0);

while (b1) updatecontrols();

}

You might not understand the function as a whole, but at least you can tell what's happening when. It's pretty plain to see that everything from the initial Render() call up until UpdateControls() is looped while b1 is false, and we have an if that does a few things, then a for loop in between.

2) Accessor Functions

This is particularly important in VC, due to it's lack of matrices and other data structures. If you're going to "fake" a 2+ dimension array, write little functions to read and write from your array.

int GetValue(int x,int y)

{

if (x<0 || y<0) Exit("GetValue: Incorrect parameters");

if (x>maxxsize || y>maxysize) Exit("GetValue: Incorrect parameters");

return myarray[y*maxxsize+x];

}

void SetValue(int x,int y,int newvalue)

{

if (x<0 || y<0) Exit("SetValue: Incorrect parameters");

if (x>maxxsize || y>maxysize) Exit("SetValue: Incorrect parameters");

myarray[y*maxxsize+x]=newvalue;

}

See what we've done? Now, not only do you have an easier way to access your array, but you've added some error checking. Two birds with one stone!

3) Special case scenerio

Yup, hate to break it to you, but there's rules for upper/lowercase too. It's not so important in VC, however, since VCC is case insensitive, but it's still a good idea. Here's the lowdown of the "standard" methods of expressing things:

void ThisIsAFunction() {}

int thisisavariable;

#define THIS_IS_A_CONSTANT 5

Is that so hard? Didn't think so. ^_~

These rules do vary a little, depending on what coder you ask, but it's usually quite similar to this setup.

4) Hungary?

If you want to be a real Jukebox hero, you can use what's referred to as Hungarian notation. This isn't real Hungarian, since we're coding VC, and not C, but it's still nice to have, even moreso due to certain oddities in the VC language.

int nItems;

int pData;

int iCursor;

string sName;

Summed up real quick, 'n' is put at the beginning of int variables that hold numbers, 'i' is put at the beginning of image pointers, and 'p' is used for pointers that don't point to images. (weird data structures of your own devising) Strings are also given a prefix of 's'. Sure, it looks like obfuscation at first, but think about it. You'll never confuse a pointer with an int again! How's that for handy-dandy?

5) Divided we stand, united we fall!

Compartmentalization is a very powerful tool to keeping your project from becoming too complex to be maintained.

Instead of shoving your entire game in system.vc, split it into logical parts. For example, put your in-game menus in menu.vc, your party manipulating things in party.vc, and your item management code in items.vc.

As an extra wrinkle, you can set rules for how those files inter-operate. For example, if you had an item system that used a simple array to hold how much of what the player had, you could either manhandle that array everywhere in your game, which would be technically easier, but error prone and generally sucky. ^_^ Alternatively, you could restrict access to that array to a few simple, helpful functions. (see Accessor Functions above) This has the added benefit of making your sub-sections less interdependant. You could rewrite your entire item system, but as long as your accessor functions work the same basic way, the rest of your game doesn't need to be touched!!

Happy coding!

--tSB