I definately don't want to tell people what they must do, but it's a historical issue; there's a famous quote by cranky old Dijkstra:
And I think he's mostly talking about line numbers (He also wrote the famous Go To Statement Considered Harmful.)
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Now I think he's full of crap, but I despite their retro-feel, I think people, especially newbies, should be made aware that 0.2 Batari BASIC lets you program without line numbers, and there are some excellent advantages (with a small number of minor disadvantages) to doing so.
Advantages to No Line Numbers:
* Much, MUCH easier to insert new code, no tedious renumbering by hand
* No counting by tens, hoping there's enough room
* You can remove a line without scanning the rest of your code to ensure there are no GOTOs try to jump to it.
* You can give chunks of code meaningful labels. You can add in text labels anywhere, whether it's a seperate subroutine , goto location, or just a section of your main loop (you can label parts of a main loop with REM statements, but "goto moveplayer" doesn't need a REM to tell you what it's up to, unlike "goto 1200")
* One of batari BASIC's stated purposes is to help people ramp up to assembly programming, and assembly uses no line numbers. Many parts of writing in bB resemble coding ASM in macros, and removing line numbers helps that connection.
* Come to think of it, higher level languages don't use line numbers either, so it's worse traning for programming at lower levels as well as higher levels
* All these things mean it should be muche easier for someone to examine your code and see what it's up to--including your future self.
Advantages to Line Numbers:
* Keepin' it real with that ol'-school 8-bit numba flava!
* It's slightly easier to give "code patches" -- I made a suggestion for F-4, and I have to admit giving lines with line numbers was easier than saying "insert this line after this other line" to make sure the code ended up in the right place in the flow
* Some folks find it a bit easier to "order" their thoughts.
* Right now with quirks in the bB code parser it might be easier to make lines that choke the parser (like a line consisting of nothing but a space)
But since the initial release was line numbers only, and since old school BASIC was stuck like that, I'm really worried that people won't see how much easier learning to live without line numbers can be.
On a similar note, USE THE DIM STATEMENT TO GIVE YOUR VARIABLES MEANINGFUL NAMES! "A this, Q and R that"...ugh! "dim buttonIsUp=u" means you can say "if buttonisUp = 1" which is much clearer than "if u=1"
Batari, I know you prefer to code using line #s but maybe we could consider including both a line #d and a no-line-# version of sample.bas in the documentation? If/when I get to coding some tutorials, I'm going to try to set people down the path of a line number free existence.
I think the code to NECG Drumma is an ok-ish example of life with labels for code blocks and variables rather than line #s and A-Z. It's never easy to read someone else's code (especially if they're lazy about comments, ahem) but I'm confident that 6 months from now I'll be more able to figure out what this code is up to than I would be if it were written old-school.