rules of programming

[[e-mail]]

elsewhere someone says that rule #1 of programming is that 90% of the time when something goes wrong, you yourself are to blame.

how 'bout we start a list of general programming rules?

1)  never have more than two copies of the program you are working on -- one for work, and the other for backup.

2)  (in qbasic) use short, easily-typed variable names, to minimize the occurance of typographical errors

[brisray]

I gotta disapree with you already m, to my mind the variable names need to bear some relationship to what they are. If I wanted to keep the high scores from a game, I'd use HiScr or something. For a keeping track of a name someone typed in I'd use UserNam$.

These are probably trivial, but think of a more complex program where you need to keep track of a lot of variables. It's my personal opinion there are a lot of programs that become practically unreadable as whoever wrote them use A$ or whatever. A nice short variable name but not very descriptive.

Anyway, here's another rule for you, put comments in the program. A couple of reasons for doing this, it helps keep you focused on what you are trying to do. If you need to ever update a program or even try and work out what it's supposed to do, especially a couple of weeks or do after you've written it, then the comments act as reminders and bookmarks.

Ray

[pebe]

A few more:

1. Use lower case for variables - it makes for easier reading 'cos it separates out variables from keywords.

2. Always add the variable type. Tally as a variable defaults to Tally!, but you may have already dim'd Tally as a string*3. Then its a pig's ear when you try to debug.

3. *Definitely* lots of comments - especially if its an unusual bit of programming.

4. Always indent contents of FOR-NEXT and DO loops. It makes for much easier reading and you can easily see if you've left out an END IF.

[[e-mail]]

I still say short, easily typed names.  high and user$ are the max I go.  several times I've spent up to twelve hours debugging some program, only to find that the source of the error was a simple typo.  in my opinion, qbasic's worst feature is its ability to incorporate and run with any undeclared variable it happens to stumble across.  if your program has an excessive number of variables, then you can simply attach a remark to each line of code -- which is what I do.

[jamppa]

I've always used quite long variables (as you can see in the timer problem topic) like goal$ and help$.

[piegopher]

Heheh, one of my questions from about a month before I got on this site, "What do I use for variables once I run out of letters?" eventually common sense kicked in and I answered it myself... yet I still cant quite kick the habit of making single letter variables...

[jamppa]

I also sometimes use single letter variables like this:

INPUT q$
IF q$ = "1" THEN GOTO goal
IF q$ = "2" THEN GOTO home

[piegopher]

a$ is for letters
a is for numbers
a% is for numbers when you run out of letters

There, it's THAT simple.  ^_^

[pebe]

Correction, piegopher.  

a is for single precision numbers (defaults to a! It's used for numbers with a decimal component).

a% is for integers (no fractional part)!

[jamppa]

This is why I'm not gonna take 10000 posts.Don't know (almost) anything 'bout QB!