Results 1 to 13 of 13
  1. #1
    Join Date
    Feb 2007
    Posts
    348

    Unanswered: Declaring variables and setting variables

    I don't have nearly the experience maintaining code as you all. Based on your experience, if you are declaring a whole rack of variables and then setting a bunch of them right away; would you prefer that they all get declared then all set or declare and set, next variable, declare and set?

    a rough example
    Code:
    Dim Facility as string
    Dim StreetAddress as string
    Dim MyPhone as string
    Dim User as string
    
    Facility = "Microsoft Corp Secret Headquarters"
    StreetAddress = "123 Hidden Road, New Hampsire"
    MyPhone = "1-800-555-1212"
    
    'Do some stuff here with each user
    '.....................
    
    'Output to a closing block
    "If you have any further questions contact me at" & Facility &" "&StreetAddress&" or call me at " & MyPhone"."
    versus
    Code:
    Dim Facility as string
    Facility = "Microsoft Corp Secret Headquarters"
    Dim StreetAddress as string
    StreetAddress = "123 Hidden Road, New Hampsire"
    Dim MyPhone as string
    MyPhone = "1-800-555-1212"
    Dim User as string
    
    'Do some stuff here with each user
    '.....................
    
    'Output to a closing block
    "If you have any further questions contact me at" & Facility &" "&StreetAddress&" or call me at " & MyPhone"."
    So in the example, the facility, street address and phone are obviously constants that could be changed some day and you might drop them in a variable just for ease of clean up later. Obviously four isn't a lot of variable but it was off the cuff, imaging having 20 or more.

  2. #2
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Are you familiar with this syntax as this would be my pref for constants:
    Code:
    Private Const MyPhone as string = "1-800-555-1212"
    Or public if it is available everywhere.

    For dynamically set variables, declare them all then set them as apprpriate in the code. I am more likely to mix stuff around in .NET as you can set a value and declare in a single statement and there are also more scoping options but for Access - keep all the declarations in one place, first thing you write (IMHO of course )
    Testimonial:
    pootle flump
    ur codings are working excelent.

  3. #3
    Join Date
    Feb 2007
    Posts
    348
    Pootle,

    I have never seen a Const declared like that. I'll have to use that. Thanks.

  4. #4
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Oh - another thing. I typically name my constants in UPPERCASE
    Testimonial:
    pootle flump
    ur codings are working excelent.

  5. #5
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by starkmann
    Pootle,

    I have never seen a Const declared like that. I'll have to use that. Thanks.
    The thing to be careful of is that you can miss off the datatype even with option explicit on. So always remember to put in the datatype or they will be variants and we all know how naughty that is
    Testimonial:
    pootle flump
    ur codings are working excelent.

  6. #6
    Join Date
    Feb 2007
    Posts
    348
    I didn't, no. I'll have to read up on exactly what variants are. I've used them before but can't say I know exactly what they are. They're variant afterall.

  7. #7
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by starkmann
    can't say I know exactly what they are. They're variant afterall.
    Exactly. They are every datatype at once. You can stick a string in there, number, date - anything. This means they are big and inefficient.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  8. #8
    Join Date
    Feb 2007
    Posts
    348
    I could see how that could do some nasty things to a variable if you start slinging it about with total disregard to what it really is.

  9. #9
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    I like everything declared up front, that way I have sort of "dictionary" section to look at if I need to reference a particular variable/object to figure out what it is. It's also handy to comment those objects if they're going to be used for a non-obvious or bespoke purpose.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  10. #10
    Join Date
    Feb 2004
    Location
    Chicago, IL
    Posts
    1,312
    I agree with Teddy have all your Dims and Const together. I will typically start with objects (recordsets, connections, etc). I also try to group variables together. If the first part of the procedure uses two or three variables then I will list them followed by a blank line then more variables.

    Also, keep in mind the number of variables you use. I read somewhere that most people can only juggle about 7 things in their heads at once. So to help when debugging I generally try to keep the number of variables to around that many. If you find yourself using more than that then you might consider putting code in another procedure. This keeps my procedures to about a screen and a half. Much easier to debug than one procedrue with 100 variables and many lines of code.

  11. #11
    Join Date
    Feb 2007
    Posts
    348
    That makes sense, the catalog concept. That's how I first started doing it but then I started playing with the idea of dim-ing and setting my connection and recordset then dim-ing my strings and ints. It made sense to me but it seemed like it could be challening to others.
    One thing DC said struck me, the idea of a page and a half of code. I think that is one thing I am still trying to get my head around. When I think of code, in a nebulous way, I imaging thousands of lines of words just running on and on. I think I'm still having trouble breaking from that into the object oriented ideas of writing concise functions and objects and calling them as needed. The code may still be long but it's broken into bite sized pieces. So the need for tens of variables is limited.
    I also think I tend to use too many variables. I tend to think of what I am writing for write now rather than getting the big picture of writing a modular component in my head. I'm sure it's a sign of my newness.

  12. #12
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by starkmann
    I think I'm still having trouble breaking from that into the object oriented ideas of writing concise functions and objects and calling them as needed. The code may still be long but it's broken into bite sized pieces. So the need for tens of variables is limited.
    I don't think that is an OO concept but more procedural programming (versus monolithic programs like in BASIC).

    I like the grouped together dimming too (most commonly objects from a particular library - this is often the case with ADO).

    I don't have a page limit but if I ever find myself writing code again and again it sets off an alarm that I should be thinking of creating a sub\ function. For example (again with ADO) I have functions that return opened connections and populated recordsets. These are the sorts of things that slim your procedures down. Sometimes you might break things off into logical chunks that aren't necessarily reused but help you see the wood for the trees (a bit like what DC has said really).
    Testimonial:
    pootle flump
    ur codings are working excelent.

  13. #13
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Quote Originally Posted by pootle flump
    I don't have a page limit but if I ever find myself writing code again and again it sets off an alarm that I should be thinking of creating a sub\ function. For example (again with ADO) I have functions that return opened connections and populated recordsets. These are the sorts of things that slim your procedures down. Sometimes you might break things off into logical chunks that aren't necessarily reused but help you see the wood for the trees (a bit like what DC has said really).
    What you're talking about here is a basic provider model. There are numerous reasons to get used to that pattern, not the least of which is completely abstracting your data layer from your application.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •