BBCBASIC and C++

[KenDown]

The trouble with the "List Variables" is that if you have a really large program the list of variables gets a bit unwieldy, plus it only gives the value when the program ends, not at some particular point in the program - which is what you really need for debugging. The same applies to Cross Reference.

Personally I hven't found Trace all that useful, as it slows program execution down to an unusable degree, particularly if the fault is at the end of a complicated loop.

On the other hand, Differences can be a life-saver if you can't remember which of two program versions is the best one or what changes you have made between them. Have one program loaded into BB4W and then click on "Differences" and follow the usual filer window to the other program.

[DDRM]

Hi Kendall,

Actually, I use list variables dynamically all the time: you can watch variables change while a program is running (though of course some changes are too fast!), and/or put in "checkpoints": I'll often put in a "q$=GET$" near a problem point, so I can see the variable values, then continue execution.

Best wishes,

D

[Ivan]

The first line in procedures and functions is not indented. For a person like me with dyslectic issues it blurs the code.

It also an issue I can't have comments in a line with if.

I write console programs.

I takes a lot of time for me to debug. My wishes are breakpoints and only the relevant variables and structs being watched.

Cross refence is great.

I think BBCBASIC might be the fastest Basic and it compiles very fast.

[KenDown]

Wow! You're right. The values do change as the program runs.

However there is still the problem that in a really large program (like my NewDisplay) there are more variables than can fit within a single window and if you are wanting to keep an eye on anything% and whatever% that just will not be possible - you'd have to scroll from one end of the list to the other. Just a pity that you can't specify the variables you want to track!

Anyway, thanks for pointing that out. Any other tips?

[Ivan]

I had tried many ways to debug but for me it more or less clutters the code. In CodeBlocks it takes only one click and you have almost everything you can wish for.

Hi Kendall,

Actually, I use list variables dynamically all the time: you can watch variables change while a program is running (though of course some changes are too fast!), and/or put in "checkpoints": I'll often put in a "q$=GET$" near a problem point, so I can see the variable values, then continue execution.

Best wishes,

D

[KenDown]

But why on earth would you want to indent the first line of PROCs and FNs? By *not* indenting, they are made to stand out from the rest of the code!

Incidentally, I always separate the DEFs with a colon and stick in a REM to describe what the code is meant to do.

Code: Select all

:
REM Procedure to do this
DEFPROCthis
ENDPROC
:
REM Function to return that result
DEFFNthat
=0

I'm not sure what you mean by comments with IF. This program seems to work exactly as expected.

Code: Select all

      a%=1
      REPEAT
        a%+=1
        IFa%=10VDU7ELSEPRINTa%:REM This is some code
        WAIT 10
      UNTILa%=11

Breakpoints are catered for with STOP (or, as I pointed out earlier, RUM), both of which can have an IF statement before them.

I agree with your desire to have only relevant variables watched or listed.

[Ivan]

For a dyslectic like me is "IFa%=10VDU7ELSEPRINTa%:REM" giving me "brainfire"

When having such issue I must code as clear as possible and variable names meaningful and short.

Your code will I write in such a way:

Code: Select all

      a% = 1
      repeat
        a% += 1
        if a% = 10 then
          vdu 7
        else
          print a%
        endif
        wait 10
      until a% = 11

If I place a rem after then the indention goes crazy and the code don't work correctly.

A space is better for me than colon that clutters the view.

The indention helps me to recognize the procedure/function more easily.

A good description have almost the same value than the code. I always try to minimize the descripton by using good name for variables and data structures.

But why on earth would you want to indent the first line of PROCs and FNs? By *not* indenting, they are made to stand out from the rest of the code!

Incidentally, I always separate the DEFs with a colon and stick in a REM to describe what the code is meant to do.

Code: Select all

:
REM Procedure to do this
DEFPROCthis
ENDPROC
:
REM Function to return that result
DEFFNthat
=0

I'm not sure what you mean by comments with IF. This program seems to work exactly as expected.

Code: Select all

      a%=1
      REPEAT
        a%+=1
        IFa%=10VDU7ELSEPRINTa%:REM This is some code
        WAIT 10
      UNTILa%=11

Breakpoints are catered for with STOP (or, as I pointed out earlier, RUM), both of which can have an IF statement before them.

I agree with your desire to have only relevant variables watched or listed.

[KenDown]

One very simple way to make your code more readable would be to follow the convention of capitals (upper case) for BASIC commands and lower case for variable names. If you did that, you might find that your DEF statements would stand out better.

I agree that not everyone likes the code without unnecessary spaces. I learned coding on the BBC Micro, which had a maximum of 27K for your program, so every byte mattered! Having learned that way, I find it easier to read than the code with spaces - each to his own.

Hmmm. Yes, if you add a REM statement after the THEN, the indenting does disappear. I've never noticed that before. I guess the solution would be to put the REM on a line of its own before the IF...THEN statement. The REM would then apply to the whole block of code, a fact you could emphasise by putting a blank line before and after that block.

Actually, I put a REM statement before each DEFPROC or DEFFN, but I further break up my code into sections with additional REMs. So all PROCs that deal with filing, for example, are together in one place, all those that deal with sorting in another, and so on.

Code: Select all

PROCinit
PROCgame
END
:
REM ===== Main procedures =====
:
REM Draws the player screen
DEFPROCscreen
ENDPROC
:
REM Moves the rocket
DEFPROCmoverocket
ENDPROC
:
REM Handles key and mouse in put
DEFPROCkeypresses
ENDPROC
:
REM ===== Initialisation =====
:
DEFPROCinit
ENDPROC

I agree with you on good (and usually long) variable names adding to clarity when it comes to debugging.

[Ivan]

I agree that follow the convention makes the code more readable, but I must admit that using capital letters is becoming a kind of screaming...

I never ran into space issues on my beeb. I used a lot of assembler. It was normal back then the to pack the code. I also used Pascal and Comal. I had tons of good ours with my beeb. Actually it was the reason for my profession as a reseller for the last 35 years.

One of the reasons I started this thread was to find out, what the "old guards" thinks of the situation with BBC BASIC?

The next Windows is near and who knows will BBCBASIC work and will Richard deal with it if it don't?

You can of course use a virtual machine and for those who have not tried it's relatively easy. I have programs from the eighties running.

So I decided to give C++ a try and now after 3-4 month I'm close to my BBSBASIC skills and can relatively easy shift between BBCBASIC and C++.

I often cut and paste BBCBASIC to C++ and after a little while I have made a working transition.

[KenDown]

As soon as I sit down to do some programming I pressing <Shift>+<CapsLock> which sets the keyboard to uppercase by default. However if you hold down <Shift> you get lower case. I find that easier than trying to remember to hold down <Shift> to get upper case for BASIC keywords. (Not saying that it actually *is* easier, just that that's what I find works for me.)