I`ve been getting to grips with XNA and C# for a couple of months now.

My projects are getting longer and harder to find my way around my own code.

What recommendations have you to keep your code legible and tidy. (Seperate classes ?,#regions ? etc.)

Cheers

GP

use header files, for each important group of functions used in your application, and then include these files in your source files.

although you may be more advanced than me, i suggest you to apply the following rules:

if (condition)
{
    if (condition2)
    {
        something else;
        for (, , ,)
        {
            instruction1;
            instruction2;
        }
        instruction100; 
    }
}
so, pay attention to the scopes.
don't forget you can use comments  //like this
void usefulfunction(parameters) {             //this function is doing... it is called in main() when...
    instruction;                                       // this instruction is changing the value of... to ...
    instruction;
}

so, use //comments
or /* long comments, explanations, etc, etc,
etc, etc... */

I hope it helps!
have a good day

PS: name your variables, structures and functions with proper names... not only letters.

andreibanc:

use header files, for each important group of functions used in your application, and then include these files in your source files.

There are no header files in C#.

Gingerprince:

I`ve been getting to grips with XNA and C# for a couple of months now.

My projects are getting longer and harder to find my way around my own code.

What recommendations have you to keep your code legible and tidy. (Seperate classes ?,#regions ? etc.)

Cheers

GP

Separate classes is the go. One cs file per class. Not only will your code be nicely separated into smaller pieces in separate files but your program design will be better expressed.

Rewrite

When I'm coding something its not unusual for me to write it again one I have it working. The second time round it usually looks better and takes less code. Its also at this stage I consider again if it can be better placed in its own class.

It sounds like you might be doing to much procedural code; something I do myself.

Yes, separate classes is the way to go! Even then really complex ones can get out of hand quickly - I favor #regions to keep everything nicely segmented. For example,

#region Fields
//variables
int foo;
SpriteBatch sBatch;
Vector2 textPos;
...
#endregion

#region Update
//main update
void Update()
{}
#endregion

#region Update Helpers
//any other updater methods

#region Draw
//main draw
void Draw()
{}

#region Draw Helpers
//any other Draw methods

You get the idea.. :-)

Some more random tips:

• DO: Compartmentalize everything into GameComponents or DrawableGameComponents if it's logical to do so. I've built up a nice little library of useful stuff this way that's easy to add to new projects. Code reuse FTW!
• DON'T: Create separate .cs files for tiny little do-nothing classes, if it's only going to be used in the same class or screen. This makes navigating your project unnecessarily cluttered.
• DO: Keep your project tree organized! Use folders for everything. Content and source files can easily get way out of control on anything but the simplest projects. Group them logically, like "Components" for your game components, "Screens" for your GameScreens, etc etc.

Make sure you're not repeating things... if you do the same method in several classes, you can add a utility class and include that method. Then you can just call it from one place. Much easier to maintain and it will reduce the amount of code you have.

I tend to refactor (that's a fancy programmer term for rewrite without changing functionality) portions of my code quite often in order to make them cleaner or shorter.

Take the time to plan how you want to design your classes. Things will be a lot clearer and easier to understand if you have a well thought out, logical design.

Thanks for all the reply thus far.

I have #region - ed my code now.Which makes it much easier to navigate the code (as I close the region unless I`m actually working on it)

My methods all have descriptive names eg.UpdateLoadingScreen(),VibrateGamepad1(), DrawWaitingScreen() etc.

My question is :  In terms of Class`s  How much functionality would you attach to each one ?

eg. Would a Class  to handle gamepad functionality alone be a sensible idea ?

Or is a Class best suited to larger chunks of code with more functionality ?

Your thoughts

Cheers

GP

Gingerprince:

In terms of Class`s  How much functionality would you attach to each one ?

eg. Would a Class  to handle gamepad functionality alone be a sensible idea ?

Or is a Class best suited to larger chunks of code with more functionality ?

Whatever works best. I would do a class for controller input. And I have classes for larger things, like an entirely project-independent instanced shadow map rendering engine (well, there's a couple small code files that are referenced, but 80% of the logic is in one place). Purely for example, I WOULDN'T make a class for, say, rumbling controller #1 (actually you can already do that with the GamePad class). Instead I would have a static class that can rumble any controller, maybe with options for fading the intensity up and down.

Use classes to encapsulate concepts. So whatever is a single concept to you, make it a class. Classes can be for small or large chunks of code, it's not really about splitting up code into smaller chunks, but more about splitting up code into separate concepts so that your program is expressed as a set of concepts.

yea now that i know how to kinda link classes together and return values its cool.  One positive thing i will say about xna is that it taught me C# instead of using vb :P.  any way also I would suggest using comments which the torque game engine lacks.  thats about all i can tell you which is a basic repeat of what everyone else said.