• Prime Mover (unregistered) 
    FRIST2
  • The Beast in Black (unregistered)

    You've heard of unrolling loops, right? This is just an extension of that optimization technique - unrolled arrays. There's an ACM paper in this.

  • Daniele (unregistered)

    The question is "why?"

  • Sauron (unregistered)

    I like how they mixed up (and messed up!) the variables starting in PRICE and PIECE. For instance, there is no PIECE30 and no PIECE80 (and I think there are other missing).

    Also, I never coded in BASIC, bu having stuffs named ADD27$ in the codebase looks also very nice to add confusion about whether it's a variable name or whether it's an operation that adds 27 dollars to something xD

    I'm confused about those variables starting with MAT. Are those for used to do some math? Or do they represent the various materials sold by the company? (unless both cases actually exist in the codebase!)

    Anyway... Good luck Argle!

  • (nodebb)

    A couple small-detail WTFs:

    1. Why is there never a PIECE that's a multiple of 10?

    2. Why is add140 the only one that's lower case?

  • Shiwa (unregistered) in reply to Dragnslcr

    That would be premature consistency.

  • (nodebb)

    I think I knew that version of BASIC once. The COMMON keyword declares those variables as global variables, so they never go away while the program is running. I say chuck all the variables, especially the Globals, and then see what missing variables the compiler complains about. Also, the naming conventions for variables is incompatibly different between various BASICs and C#.

  • TVJohn (unregistered) in reply to Dragnslcr
    1. You'd have to pay PRICE10 to find out
    2. Because someone lost the will to live? Although in every version of BASIC I've ever used variables are not case sensitive.
  • Foo AKA Fooo (unregistered)

    Sorry, but I see no abstraction here. Premature abstraction would be something like a (badly implemented) map of variable names and values, preferably using RTTI, serialized into XML and persisted on distributed databases with multi-level caches and cloud backups, when all you need is a local integer variable. That's what I want to read about on this site!

  • Sole Purpose Of Visit (unregistered) in reply to Foo AKA Fooo

    Needz moar wooden table ...

  • holy shit now I'm actually commenting here... (unregistered) in reply to Sauron

    Also, I never coded in BASIC, bu having stuffs named ADD27$ in the codebase looks also very nice to add confusion about whether it's a variable name or whether it's an operation that adds 27 dollars to something xD

    Back when I was a kid I played around in QBasic. Variables were (mostly) not declared, but instead got a type by some sort of inverse hungarian notation. Ending the name with a dollar sign made it a string, a percent sign made it an integer. Not sure if that was just a convention or an actual requirement though.

  • Brad K. (unregistered)

    As an old BASIC programmer, typically string-typed variables are those that ended with the dollar-sign and those without were either a FP type or an integer type. (Applesoft BASIC used trailing % to indicate integer types.)

  • SomeRandomName (unregistered) in reply to Brad K.

    The '%' sign was also used in the somewhat earlier BASIC-PLUS, developed by Digital Equipment Corporation for the PDP-11. I did a lot of work in that back in the early '70s. (Yes, I'm that old.)

  • (nodebb)

    And don't forget things like Microware's BASIC09, which was only just BASIC, having lots of similarities with more modern things like VB.

    https://en.wikipedia.org/wiki/BASIC09

  • Benjamin (unregistered)

    GW-BASIC had
    $ String variable
    % Integer variable
    ! Single-precision variable
    # Double-precision variable

  • Fizzlecist (unregistered)
    Comment held for moderation.
  • (nodebb)

    It's been decades... BUT... "COMMON" was for sharing, and changing the layout was a breaking change. Think of it as a record structure with implied members (each variable at a given offset). This was often binary persisted also as a "blob"... So pre-declaring spare variables was actually a common practice.

  • (nodebb) in reply to Benjamin

    The important thing to keep in mind is that different specifiers denote different variables. So A$ isn't referring to A in some sort of string context, it is a completely separate and independent variable from A.

  • (nodebb) in reply to Shiwa

    That would be premature consistency.

    Congratulations, you caused me to spill my coffee. Though that laugh was urgently needed.

    On a more serious note: This kind of issue is why I hate when languages require a separation of declaration and assignment. Technically present in C, but especially present in Fortran: Don't you love seeing 20 100-character-lines of declarations at the beginning of a function?

    Plus, in Fortran declaration and assignment cannot be on the same line, unless you want a variable, that is persistent across function calls;

    INTEGER :: iItem = 0

    looks innocent, but it is implicitly the same as

    INTEGER, SAVE :: iItem = 0

    which is very different from

    int i_item = 0;

    The most insulting part? Fortran could be a good language, if it just filled out a few annoying omissions. And I count "variables must be declared in a separate declaration block" as one of the largest.

    Less annoying but still annoying is the issue of compilation cascades, which are solved completely backwards... You can use submodules for that, but its hard for an existing code-base, and the language just hasn't cultivated a culture of cleanly separating "header" and "implementation" files. Especially, given that Fortran has compiler-generated .mod files, which are essentially header files, but are messed up for build systems by nonsense like Intel Fortran adding a timestamp into the file...

    Addendum 2022-12-02 03:47: I'm ranting I guess :/

  • nedalic142 (unregistered)
    Comment held for moderation.
  • AdH (unregistered)

    I'm surprised no one has mentioned that declaring your inner loop variables first with short names was a real performance win on Microsoft Basic (e.g Commodore 64, and Apple II)

    In that world all variables were stored as unsorted(?) tagged data in the variable space and the linear search time for the storage was important.

    I don't remember a COMMON keyword in that BASIC though.

  • Naveed (unregistered) in reply to Nutster

    Most BASIC was interpreted not compiled. I don't know which one this was.

  • Argle (unregistered)
    Comment held for moderation.
  • Grunthos the Flatulent (unregistered) in reply to AdH

    Commodore BASIC only supported 2 character variables (any other characters were ignored), so a variable called AA$ would be the same instance as AARDVARK$. With BASIC being interpreted the only (speed-) performance would be in the parsing of the BASIC code which was stored as text - although I as I remember keywords were tokenised. Using short (1 or 2 character) variable names was typically used to save memory rather than performance.

  • (nodebb)

    My solution depends on using the variable MAT90$.....

    ... oh noes!

Leave a comment on “Common Variables”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article