Some would argue that programming is an art, and so whatever technique works for the programmer should be fine. However, most don't feel that way, and so they decided to "enforce" some etiquette in programming. Obviously no one is going to force you to adopt one style over another, so it's up to you to decide. If you find these techniques to be helpful, by all means adopt it. The following techniques aren't standard, I don't believe there really is a standard (especially for the BASIC language), so feel free to adopt a convention that best suits you.

The BASIC language does not enforce a strict program structure that other languages like C or Pascal do. However, this does not mean you should go wild and declare variables in the middle of your FOR loop, or place an $INCLUDE directive somewhere in the middle of your program either. For matters of etiquette, here's a standard programming structure that you may want to adopt:

    Directives       ie. $INCLUDE "RAPIDQ.INC"
    Declarations     ie. CONST, TYPEs, DECLAREs, MACROs
    Global variables ie. DIM, CREATE, etc...
    Subroutines      ie. SUBs, FUNCTIONs
    Main program

Rapid-Q is not case sensitive, so you can define a variable named MYNAME and be able to change the case of the letters, for example MyName. For matters of etiquette, be consistent, so if you capitalize MYNAME then be sure you do that for all occurrences of MYNAME. It's also a good idea, if you choose to capitalize your variable names, that all your variables are capitalized as well. For example:

    DIM MYNAME AS STRING
    DIM MYPHONE AS LONG
    DIM myAddr AS STRING*25

    CONST FALSE = 0
    CONST TRUE = NOT FALSE

    TYPE TAddress
        name    AS STRING*35
        address AS STRING*255
    END TYPE

    DIM addressBook AS TAddress
    DIM myPhone     AS LONG
    DIM myName      AS STRING
    DIM dog         AS SHORT

    SUB mySub (x AS LONG)
    END SUB

There are times when grouping constants can help readability, especially if you maintain a lot of constants in your program. For example:

    CONST SPACE = 1
    CONST DIAMOND = 2
    CONST HEART = 4
    CONST CLUB = 8

    CONST CRD_SPACE = 1
    CONST CRD_DIAMOND = 2
    CONST CRD_HEART = 4
    CONST CRD_CLUB = 8

There's not much to be said about indentation, just two words, be consistent. Some prefer to indent with 4 spaces, while others prefer 2, 3, or 5+ spaces. Indentation naturally occurs in a block statement, without indentation your code may become very hard to read, for example:

    FOR i = 1 TO 10
    FOR j = 3 TO -90 STEP -3
    NEXT
    IF s$ = "what" THEN
    IF i = 3 THEN
    END IF
    ELSE
    PRINT "s <> what"
    END IF
    NEXT

    FOR i = 1 TO 10
        FOR j = 3 TO -90 STEP -3
        NEXT
        IF s$ = "what" THEN
            IF i = 3 THEN
            END IF
        ELSE
            PRINT "s <> what"
        END IF
    NEXT

Most BASIC languages these days don't require line numbers or labels. In fact, the only reason Rapid-Q supports these is to maintain compatibility with older BASIC code. Such code can usually be run in Rapid-Q with little to no modifications. Most people have blamed GOTOs and GOSUBs for all the "spaghetti code" you see for BASIC. Trying to follow the execution of GOTOs can be rather difficult especially if you use a lot of them. For matters of etiquette, please avoid using GOTOs and GOSUBs, there's always a better alternative.

Rapid-Q, like most BASIC languages, doesn't force you to declare your variables before you use them, but it is good practise to declare them anyway. This helps to avoid ambiguity and typographical errors. It's very easy to misspell a word, especially if you frantically code like I do. This is definitely not a requirement, but for good practise you should always turn typecheck on. It may seem like a hassle, but this can save you hours of debugging woes.