Indention and comments

Here you can suggest additions and modifications to BB4W or BBCSDL
Post Reply
Posts: 4
Joined: Tue 07 May 2019, 16:47

Indention and comments

Post by Ivan » Tue 14 May 2019, 11:36


First of all: My English is bad so please forgive me. :)

For 35 years ago I had a BBC model B. I programmed in BBC BASIC, 6205 assembler, comal and ansi pascal. In 1987 because of my job then I had to use a Danish programming language UNICOMAL. UNICOMAL was in many ways as BBCBASIC, but with a strict syntax check for each line and some automatic e.g. adding THEN if you for forget.

Recently I started to program again and it is a joy. I have read that Python should be easy to learn and it is. I even learned OOP in Python and relatively easy to learn. The syntax can be frustrating and can sometimes be strange for me.
A for loop from 0 to 2, therefore running 3 times: you write for x in range(0, 3): CASE instead of WHEN (why) and each case normally and with break (reminds me of GOTO). I could get used to use Python syntax, but graphics is very hard and Windows API is also hard to use.

Then I tried C++ and wrote some test programs. I understand to some degree, why C and C++ is so fast - closer to assembler. I actually like C++ and syntax is for the most part easy to grasp. I particularly like the clean code, that is not compressed. Again Windows API is also hard to use.

BBC BASIC my old love had survived to this day. Russell have done tremendously work and I really don't have to use the Windows API, but he had made Windows accessible via SYS. Back in the eighties I also wrote very compact code and thought is was fine.

Today I wish more clear and readable code. I think it is because of UNICOMAL and C++

I don't want step on any toes, but please let me know what you think.

Code: Select all

 10 REM suggestions: indentions and comments	// UNICOMAL and C++ comments style
 30 PROC dummy(TRUE)				// use tabs or spaces to comment coloum
 40 PRINT FN_function(2,1)			
 50 END
 70 DEFPROC dummy(indention)
 80   CASE indention OF                         // #1: Indention in procedures 
 90     WHEN TRUE
100       IF indention THEN			// #3: Comment on every line
110         PRINT "Indention #1"
120         PRINT "Indention #2"
130         PRINT "Indention #3"
140       ENDIF
150     WHEN FALSE
160       IF 1>2 THEN
170         PRINT "Indention #4"
180         PRINT "Indention #5"
190         PRINT "Indention #6"
200       ENDIF
220       NULL
240 ENDPROC dummy
260 DEF FN function(a, b)			// #2: Indention in functions
270   IF a>b THEN
280     =a/b					// #5: =a/b or RETURN a/b 
290   ELSE
300     =a+b
310   ENDIF
320 ENDFUNC					// #4: easy to read

Posts: 116
Joined: Mon 02 Apr 2018, 18:04

Re: Indention and comments

Post by DDRM » Wed 15 May 2019, 09:41

Hi Ivan,

These are my thoughts, and are in no way "official"!

I agree that indentation of loops etc can be very handy in clarifying structure, and in finding bugs. This happens automatically in the IDE, which I find very helpful. I must say I find the very strict formatting requirements of Python (where indentation is used to indicate/control block structure, and even a single space too many/too few is fatal) quite annoying, though I'm slowly getting used to it.

The standard way of adding comments to programs is to use the REM statement: I often follow your approach and place them off to the right of the code, e.g.

PRINT "Hello World" :REM You can't get more traditional than that!

Note that you can use a colon to indicate a new statement, and then put your REM after that.

You can also use *| to indicate a comment - but those comments won't get deleted in a compiled program.

Best wishes,


Posts: 4
Joined: Tue 07 May 2019, 16:47

Re: Indention and comments

Post by Ivan » Thu 16 May 2019, 12:18


I agree regarding Python.

Again Indention in procedures and functions would be nice.

If I remember correctly : was also used in the old BBC Model B. I'm ambivalent about : because I can write a line of code e.g. If THEN: something: bla bla

It's good when code is fresh in your head, but later when you have change or correct something for me at least more easy to read.

I rather write more simple lines than compact code.

*| gives me associations to C++ /*

Instead of writing REM on each line // is more readable because of less text in my opinion

Example from an editor I wrote in 1989 - about 2000 lines, but not finished:

Code: Select all

0685 PROC gem 
0690   gem_linie //					save line
0695   gemmer#:=TRUE //                         	show only dirs
0700   klargor_hent //                          	prepare path
0710   svar$:="" //                             	emty 
0715   IF tast$<>escape$ THEN //                	regret save
0720     gem_administration //                  	write filename
0725     IF tast$<>escape$ THEN //              	if regret, avoid savefile$
0730       IF samme_navn# THEN //               	filename exist
0735         svar$:=sporge$ //                  	replace
0740         IF svar$="j" THEN gem_filen //     	yes
0745       ELSE
0750         gem_filen
0755       ENDIF
0760     ENDIF
0765   ENDIF
0775   afslut_hent
0780   hent_pos(1)
0785   gemmer#:=FALSE
0790   IF svar$="n" AND tast$<>escape$ THEN gem
0795   tast$:="" //                             	emty
0800 ENDPROC gem
Best wishes,
Udklip.JPG (104.27 KiB) Viewed 69 times

Post Reply