Steve!
SL>Oh well.  I've learned something from it, and there's something to be
SL>said for every lesson, however learned. :)
        I don't know how many of the things I know are the result of
        experimentation, pluck, and sheer stupidity on my part. 
SL>I understand.  On your recommendation some months ago, I did purchase a
SL>copy of Steve McConnell's book "Code Complete".  I've been going through
SL>it, a little at a time, and trying to put some of the things I've
SL>learned there into practice.  I struggled through some of the
SL>concepts re. information hiding, etc., but I've learned a lot.  It's
SL>been a good exercise, and I think I've really improved some of my code as
SL>a result.
        McConnel's book is the best there is, in my opinion.  Every time
        I read it, I pick up something new.
SL>Anyway, I've finally gotten the nerve to try some of the
SL>other things you suggested re. declaring everything and giving the
SL>compiler an opportunity to catch "spelling problems", and I think there's
SL>been some benefit there too.
        Spelling errors can kill a BASIC program, if the default
        behavior of automatic variable declaration is not used wisely.
SL>That said, I've gotten used to the idea of trying to make sure
SL>anyone else who might look at what I've done can understand what I
SL>was up to.  To this end, declaring even the default type/scope seems to
SL>enhance readability for anyone who understands what it will do.
        I tend to agree with you.  The default scope/life in PowerBASIC
        is PRIVATE LOCAL, but, heh, if you're gonna hafta declare data
        types anyway, why not have a compiler option that forces
        scope/life declarations.  (I say "life" to mean LOCAL, SHARED,
        or STATIC.)
JK>You cannot, with declaration mode on, have two variables WITHIN THE SAME
JK>SCOPE with the same base name.  This is how C programmers have always
JK>had it.  I prefer DIM a AS STRING and SUB MySub (A AS INTEGER, etc.)
SL>Me too now!  When I'm doing this I can usually find room to fit a
SL>concise description of the variable's use within 80 characters.
        A variable's name should reflect its semantic purpose.  If we
        can't find a good name for our variable, often times it is
        because we are not sure ourselves exactly why the variable is
        there.  By forcing declarations, we are forced to think about
        what we call our variables.  Death to all "temp"s.
JK>The old-style suffixes are very nasty to parse with preprocessors.
SL>What does a preprocessor do, and why might you use one?
        In my case, I'm programming a Fermat to PowerBASIC preprocessor.
        (Fermat is an object oriented superset of BASIC.)  It is
        necessary, as I pass the code, that I know what each token is in
        a given scope.  Syntax can only be checked if we know the
        purpose of each token.  Consider the following chunk of Fermat
        code:
                CLASS MyClass
                        Attr1 AS INTEGER
                        Sub1 AS SUB (x AS INTEGER, y AS INTEGER)
                END CLASS
                DIM this AS MyClass
                This.Sub1 1, 2
        Okay... How do we know, as we preprocess, that the statement
        "This.Sub1 1, 2" is legal?
        To get to that line, we have already passed two declarations.
        The CLASS and DIM are declarations of the tokens MyClass and
        This.  We know that This is of class MyClass, and that MyClass
        has the method Sub1, and that  Sub1 accepts two integer
        parameters.  The preprocess then spits out the following
        PowerBASIC code:
                TYPE MyClass
                        Attr1 AS INTEGER
                END TYPE
                DECLARE SUB MyClass__Sub1 (x AS INTEGER, y AS INTEGER)
                DIM This AS MyClass
                CALL MyClass__DIM (This)
                MyClass__Sub1 This, 1, 1
        The job of the Fermat preprocess becomes considerably less if we
        force declarations and don't allow suffixes like $, %, &, etc.
JK>Constants are preceded by %, not the type, and may only be numeric.  I'd
JK>like to see string constants.  TRUE and %TRUE are not one and the same.
JK>%TRUE is a global constant, whereas TRUE is an identifier that may be of
SL>Ahh!  That's the distinction.  I've been working with Scriptmaker
SL>lately, a BASIC implementation for Windows that comes with Norton
SL>Desktop for Windows.  It uses the Microsoft CONST declaration for all its
SL>constants, and a constant takes the type of its first assigned value.  I
SL>think I like that better.
        CONSTs and %s aren't strictly the same in QB and PB.  I don't
        know which I like better, myself, but I do prefer to see in the
        code a clear %XXXX so that I know it cannot be altered.  QB
        style constants look just like variables until compile time.
SL>This "recognition" is the purpose for some of the variable naming
SL>conventions (notably Hungarian) as well isn't it?
        I hate Hungarian notation from an aesthetic point of view, but
        it does the job of the $, %, @, !, & symbols well enough, I
        suppose.  I personally feel that variables should be so aptly
        named as to eliminate the need for reminders.
SL>Thanks for your comments Jamshid!  A little inspiration goes a long
SL>way.  All the best.
        All the best to you, too.
Jamshid
--- Maximus/2 2.01wb
---------------