Sorry your browser is not supported!

Can anyone give me some advise on how to tidy up my programs ?

i seem to write programs as i go along and as each project progresses things get into a mess, with criptic variables, unsequenced sprite numbers as ive added them and so on.

i guessing im not the only one who does this - so for me and others like me please add your sugestions on how to keep a program clean and readable.

You know REMs, don´t you?

Rems = Comments...
They can help a fair bit, if you explain what each bit does and its relation to other bits of code.
The best thing you can do is sensible variable names. Use full names for things.
"PlayerObject"
is much clearer than
"po"
for instance.

Try and split things that you do alot into functions and/or sub routines.
Its easier to read
Enemy_Collision()
than
<insert hundreds of lines here>
You can also debug code easier if its in functions, as you can isolate the problem to a single function then go from there.

Use INCLUDES!
This will help you out a whole bunch, it does for me.
I found, and I am no expert yet, but, by breaking my code up into different sections, and putting them into include files, and including them, it makes things easier to read. For example, I am working on an FPS game, based on Airsoft (like bb guns), and I have a main game loop file. That file calls subroutines that are stored in include files. I have include files that store player movement code, bullet creation and movement code, object loading code, sniper zoom code, global variables code, etc. In my includes, I just create subroutines and functions that are called in the main game loop file. Another advantage to this is code reuseability. If you decide to write another game, and you need to write player movement code, wouldn't it be nice to just reuse the code you did in the last game. Well, you can. Just include the file you put all your player movement code into your new game. The only catch here is, any variables you may have in the player movement code that might be used in other includes or the main loop. So, if you need to use a variable from one include to another, you have to make it Global, so, have a REM header at the beginning of each include that says what all the variables do, and make sure if you have to make them global, you put them in a global include. Works for me!

Edited to add:

One nice thing about VB is the Option Explicit statement. As far as VBPro goes, they don't have this. In VB, the Option Explicit statement forces you to declare variables, and makes sure these variables aren't already declared, and prevents mistyped variables. I'd sure like to see this in future versions of DBPro...

Devide your code into sections, like:
`------------Array declerations-------
lines
`-------------Main Loop---------------
lines
`--------------Functions-------------
I like to use these, because they make it easier to navigate throughout your code.
Use functions, my 80% of my code is functions, and they've been VERY usefull.
Use REM do describe a line's purpuse, or a variable's use, don't do it for every line, but for some.
Overall, try to tidy up your code in whatever way that works for you.

here's a screenshot of my code, maybe it'll give you a clearer idea.



EDIT: look at the functions, as the code shown above is not the best example ,lol.

Ok, here is my advice.

Don't sit at your PC and think 'Hey I am going to write a program'.

Instead go and make a cup of coffee, whilst you drink that cup of coffee think about the program you wish to write, think about what you want it to do, then start to break it down into smaller parts. Each part in effect becomes it's own small program. When you go and sit at your PC don't start writing 'the big program' but start writing the small programs. Eventually it will all fit together.

Back when I learned to code (a very long time ago) all we had was the GOTO statement (or it's equilvelent at least), and we were trained to write structured code because the languages of the time did not premote it.

Today we live in the OOP (Object Orientated Programming) world, where professional programmers define small segments of code that are then tied together to form the 'big program'. Although DB is not an OOP language you can and should make great use of functions and subroutines in your code. This will help you with structure and at a later stage dubugging.

Any time you find yourself repeating similar lines of code more than once to do the same thing, then this is a great place to use a function, likewise if you find yourself writing hunks of code to do one type of thing (say initialising a lot of variables) then you should consider putting this in a subroutine.

Do not be afraid to 'prototype' specific tasks in a seperate program, for instance, say you were developing some player movement code, write a simple skeleton program and develop your player movement code until it is perfect, at that stage it will almost always look very function shaped and you will be able to incorporate it into your main program easily.

And the most important thing of all.... REM's everywhere, right now you know what your code does, but trust me, in 18 months time when you come to ammend it, then it may as well have been developed by a stranger if you have not commented it sufficiently.

I think that this may tie in with Mac's advice somewhat. I maintain a simple text file for a large project; basically it is a running log or journal, in which I explain roughly what I am doing and why from subprograms and subroutines to functions. Think of it as a detailed explaination of what you are doing outside of the code remarks as a back up for memory and debugging work.

This has nothing to do with keeping tidy code, I'll admit, but it does help keep you from drifting off task during a lengthy or complex project, and it helps you when you return to your program after a lengthy time away from coding.

Aside from that, learn and practice proper code remarking and indenting and so forth. A word of advice I received from a mentor ages ago was to write code as if a really snarky instructor was about to grade you on the code's looks and remarks information as well as its functionality. It helps to keep this in mind as you work. It's a major pain in the posterior to go back and try to clean up code after the fact.

Bear in mind that you [particularly me] can still produce lousy and buggy code even if it is neat and well spaced and thoroughly remarked, but then if you follow these principles, and the advice offered in this thread by others, it is one heck of a lot easier to see where and how you messed up. It works for me.

Thanks for the post, Elie. It helps all of us to go over this stuff every now and then.

Opus