Programming things that drive you up the wall.

[K133]

Is there anything you see in others' BASIC programs that drives you bonkers?

I absolutely can't stand unnecessary math involving constants and just have to take it out when I see it in a program. Stuff like X=1+1, or POKEV+21,1 instead of POKE53269,1, or SYS DEC("CDDA"). Using just a variable (like POKEV,1) makes some sense as it does run faster, but doesn't forcing the computer to do math when the answer is unsurprising just slow things down? It's not like the Commodores had built-in optimizing compilers.

Also, seeing gotos or gosubs targeting REM statements drives me nuts.

[nikoniko]

Most of those things are done in magazine or book code listings to make it easier for readers to follow what's going on without the benefit of line-by-line analysis in the accompanying article. Unfortunately, sometimes people then pick up such habits as their own programming style. I don't see anything wrong with it if it aids someone in development, but it should definitely be fixed for anything where performance matters... which means pretty much every BASIC program running on a slow machine. :cool: Back when I did type-ins, I usually just fixed such things while I was typing.

You can hardly blame people for adopting SYS DEC("address"). That's the preferred presentation style of both Jim Butterfield and Fred Bowen, and it's used in the 128 PRG and maybe Mapping the 128 also. And I have to admit, I do it myself sometimes if I'm writing something real quick. I would never use it for final code, but in a pinch it'll do since I prefer hex to decimal.

I'm totally with you on jumping to REMs being irritating, but again I think that's mostly done in published listings. If I really need to have a REM before for a routine at, say, line 1000, I'll stick it at line 995. I rarely use REMs at all, though, except perhaps at the beginning of a longish program to document which routines are where.

[Guest]

What you guys are describing is premature optimization at it's worst.  Performance is not always the most most important aspect of a program, especially if you are sharing that code or working in a collaborative environment.  If it's your own code that you don't plan on sharing with anyone then it's fine.

[nikoniko]

As I said, such conventions can be useful during development and aid in readability. In the end, though, nearly any BASIC program on a 1-2Mhz machine could benefit from a speed boost, so it's usually worthwhile going through and doing what you can. It's not like you have the benefit of developing with an optimizing compiler or modern interpreter that does some of that for you. However, it can be very worthwhile keeping a copy of unoptimized code around for later reference, especially for any particularly long or obtuse program. And for shared or published code, it's usually best to leave final optimization as an exercise for the reader should they wish to do so.

If it's your own code that you don't plan on sharing with anyone then it's fine.

I think that would describe quite a few people who write (or wrote) programs on their Commodore machines. Consider how many millions of programs have been written by people for their own enjoyment or utility, compared to how many have ever been released. In one respect, it's a shame that people don't share more, but then again not everything needs to be shared. Goodness, Quantum Link used to have more than a hundred virtually identical loan amortization calculator programs... I'm all for choice, but when paying by the minute to browse download listings, I would have appreciated people keeping more things to themselves.

[hydrophilic]

Actually I like POKE V+21,X (once I figure out what V is) because I'm used to hex notation for the hardware registers and that notation is easier for me to think with than say POKE 53269,X.  Kudos to anyone who can convert a 5-digit decimal number to hex in their head!

A long time ago I made it a habit not to do the sort of optimizations being discussed.  There are so many possibilities that I would get completely side-tracked with optimizing BASIC programs.

The best way, for me, to speed up slow BASIC programs was to find the bottle-neck.  Sometimes it is a short sub-routine that is called repeatdly, but is located at the end of the program.  Moving it near the beginning (like line #1) often will produce dramatic effects.  Other times it is due to disk access in which case I write a short (in a monitor) ML program for BASIC to call.  This also dramatically improves the program, even though 99% remains BASIC.

In summary, I think BASIC programs are great for their ease of use and understanding but if I want speed, a touch of ML is usually all that is needed.

Tangent subject: I've seen some BASIC programs that are both 'optimized' and 'copy-protected' by somehow (a dedicated application probably) making most of the program lines near 256 bytes.  The BASIC editor only allows 80 characters per line (64/plus4) or 160 characters (c128) so these programs cannot be 'hacked' in the usual manner.  And due to the way BASIC parses a program, it runs faster due to fewer (and smaller) line numbers.

You think I could eBay a program that does that BASIC programs?

[JamesC]

The BASIC editor only allows 80 characters per line (64/plus4)

Plus/4 can handle a whopping 88 characters per logical line.

I've seen some BASIC programs that are both 'optimized' and 'copy-protected' by somehow (a dedicated application probably) making most of the program lines near 256 bytes.

Yes, Virginia, there is a BASIC program optimizer.... and it's usually a BASIC program, to boot. It does this by examining the program's line links, and removing as many as possible without going over the 255 byte limit. This gives the effect of a RENUMBER as well as packed program lines. Some lines can actually be longer than 255 bytes when listed, since BASIC keywords are stored as tokens.

[Golan Klinger]

I don't optimize things in BASIC. I just write quick and dirty programs to do what I need to get done. If I want something fast and efficient, I will write it in ML. Come to think of it, I'd just as soon write it in ML anyway.