Page 1 of 2 12 LastLast
Results 1 to 15 of 18
  1. #1
    3 Star Lounger
    Join Date
    Aug 2001
    Location
    Cape Town, South Africa, South Africa
    Posts
    399
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Standard Code (VBA)

    Can any one tell me what is the standard code for the more common controls?

    Label = LB_Name
    Textbox = Tx_number
    ComboBox
    ListBox
    Optionbutton

    Thanks

    Mario

  2. #2
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Standard Code (VBA)

    Mario,

    Standards for prefixes differ somewhat, but these are pretty usual:

    lblName
    txtName
    cboName
    lstName
    optName

    - note there's no underscore used in these. Capitalize the first letter if there's more than one word: txtClientName.

    Gary

  3. #3
    New Lounger
    Join Date
    Jan 2001
    Location
    Chicago, Illinois, USA
    Posts
    23
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Standard Code (VBA)

    Mario,

    Gary's right on with the abbreviations he lists. If you're interested in standards in VB, may I suggest James Foxall's Practical Standards for Visual Basic. It provides a host of good programming practices.

    Cheers,
    Rex

  4. #4
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Standard Code (VBA)

    Rex,

    Thanks for the lead to that book - haven't read it but it's gotten good reviews at Amazon - click <A target="_blank" HREF=http://www.amazon.com/exec/obidos/ASIN/0735607338/qid=1011317219/sr=1-1/ref=sr_1_10_2/103-9554178-0340618>here</A> to have a look - there are used copies starting a US$12.00.

    Coding standards when working in a team (or when producing code that will be maintained by another person) are an important and sometimes contentious issue.

    Everyone can (should be able to anyway) agree on simple things like standard naming conventions, prefixes etc.
    What can get a little contentious are issues like: do you code for the 'lowest common denominator' so that newer members of the team will be better able to understand what they're seeing and be more productive (for example "If bExists = True" rather than "If bExists"). There's a tug of war between more streamlined and efficient code vs. more easily understood code. Working with a team, I tend to vote for more understandable code, but sometimes it's painful - which do you prefer?:

    <pre> If ActiveDocument.ActiveWindow.View.ShowAll = True Then
    bFormat = True
    Else
    bFormat = False
    End If
    </pre>

    Or:

    <pre>bFormat = ActiveDocument.ActiveWindow.View.ShowAll</pre>

    Gary

  5. #5
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Standard Code (VBA)

    <hr>which do you prefer?:<hr>
    I prefer the tag bln or bool for booleans. <img src=/S/grin.gif border=0 alt=grin width=15 height=15>

    Seriously, good naming conventions take a lot of the guesswork out of things even for new members of a team. If everyone agrees that fSomething stands for a flag (boolean) rather than a function, then anyone can read the code. I prefer the more obvious tags to take any ambiguity out of the thing. However, once you've named variables so that you can see they're a boolean value, then I don't see much purpose in saying the equivalent of "If boolenvalue = True then ...." If the thing being evaluated is a control that *holds* a boolean value, that's a whole different story, since there are a few *larvae* (little bitty bugs <img src=/S/evilgrin.gif border=0 alt=evilgrin width=15 height=15>) in VBA that can cause you grief if you try to evaluate a control as a true or false value without completing the expression.
    Charlotte

  6. #6
    New Lounger
    Join Date
    Jan 2001
    Location
    Chicago, Illinois, USA
    Posts
    23
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Standard Code (VBA)

    Gary,

    Taking a hint from Foxall, and currently working in a collaborative environment with developers of widely different skill levels, I try to write code as self commenting as possible. Still, I didn't find the latter example that complex, and would be more likely to go with it. Like Charlotte, I prefer the bln prefix for boolean values, though. <img src=/S/wink.gif border=0 alt=wink width=15 height=15>

    Rex

  7. #7
    Silver Lounger
    Join Date
    Mar 2001
    Location
    Springfield, Ohio, USA
    Posts
    2,136
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Standard Code (VBA)

    For boolean variables, I prefer to construct a name in the form of a question:
    <pre>FormatMarksAreDisplayed = ActiveDocument.ActiveWindow.View.ShowAll</pre>

    I know that this will leave me open for <img src=/S/bash.gif border=0 alt=bash width=35 height=39>, but I use prefixes everywhere else and this way my if statements are more self documenting:
    <pre>If FormatMarksAreDisplayed Then</pre>

    <font face="Comic Sans MS">Sam Barrett, CACI </font face=comic>
    <small>And the things that you have heard... commit these to faithful men who will be able to teach others also. 2 Timothy 2:2</small>

  8. #8
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Standard Code (VBA)

    I think the rest of us do much the same, but we prefix the variable name with a tag to make it absolutely clear what datatype it holds. It could be an integer and still work--most of the time. The tags save a lot of time and pain when everything looks right but errors out. Otherwise you have to backtrack through the code to discover that the variable is a boolean and you're trying to assign a string or a double to it. <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15>

    I've learned to think "maintenance" all the time! <img src=/S/grin.gif border=0 alt=grin width=15 height=15>
    Charlotte

  9. #9
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Standard Code (VBA)

    I agree with your and Sam's comments.
    As far as the "b", the team I work with has a standard to only use one-letter prefixes for data types; something I can't change, so I've gotten used to it.
    (The one that bugs me more than "b" though, is having to use "n" for every kind of numeric data type - I think that's dumb. <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15>).

    Gary

  10. #10
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Standard Code (VBA)

    > Everyone can (should be able to anyway) agree on simple things like standard naming conventions,

    I luvs ya, Gary, but .......

    Experience shows that not everyone can agree on any one naming convention. I don't think that naming conventions are simple, if only because they are designed to simplify understanding between different people (or between the same person after a gap of several years.

    I've worked on massive projects with team members drawn from all walks of life, all ages etc.

    There will always be a debate (no matter how much you and I deplore it) between bln and bool, between int and i, and so on, or etc. if you prefer.

    I'd love it if there were a universal standard; it would make translation so much easier.



    What everyone ought to agree on is that there should be naming conventions and that any convention in force ought to be continued.

    When I approach a programming project, one of my first questions is "What are your programming standards?", let alone "What are your naming conventions?". If there are none, then I feel justified in implementing my own, which really means selecting on of the existing publicised conventions (e.g. Reddick) and using it.

    Very rarely do I find a situation where no convention exists.




    > I tend to vote for more understandable code, but sometimes it's painful - which do you prefer?:

    Trick question, right?

    I don't really mind either. Both are good, each for their own reasons. I agree with you that one suits the novice programmer (and there's not many of us left!) and the other the professional programmer.

    That one is an acceptable standard (and white-space layout) for the novice makes it a good standard. That the other is an acceptable concise method for the professional makes it an acceptable standard.

    They are both good; I'd ask only that the same style of code be used throughout that module, nit just for the procedure being coded. If at all possible, the same style of code be used throughout the enire project/template.

  11. #11
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Standard Code (VBA)

    <hr>That one is an acceptable standard (and white-space layout) for the novice makes it a good standard. That the other is an acceptable concise method for the professional makes it an acceptable standard.<hr>
    The professional programmer had better remember that code maintenance is often done by the most junior member of the team! Brevity may be the soul of wit, but it makes code harder to debug and maintain, regardless of your level of proficiency. Yes, of course I can read the "concise" version, and I often use it where the longer form is completely unnecessary. But I also comment my code extensively so that even a novice should be able to see what the code is *supposed* to be doing. Long conditional statements without comments are really no more illuminating the concise, one-line code without comments. <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15>
    Charlotte

  12. #12
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Standard Code (VBA)

    Chris, Charlotte:

    Thanks for your comments, you're definitely right.

    My own transition from novice to pro is relatively recent, and when I learn of some new and more elegant way to do something, with the zealousness of the newly converted, I tend to get impatient with methods that until recently, were my way of doing it too! And I only have to look a bit further back to remember when that simpler method was also hard for me to comprehend!

    An example from the other end of the spectrum: we had a contractor come in and write a component for us (ADO - should have gotten you, Charlotte <img src=/S/grin.gif border=0 alt=grin width=15 height=15>). This code is so abstract that no one on our team can maintain it (maybe that was the intention? <img src=/S/devil.gif border=0 alt=devil width=15 height=15>).

    So there's always a balance to be struck.
    Charlotte, one aspect not covered in your comments: what if the junior developers in your team are writing code, and not just maintaining it?
    When I see code like this:

    Selection.GoTo What:=wdGoToBookmark, Name:="bmkTest"
    Selection.Delete Unit:=wdCharacter, Count:=1

    - I'm still going to <img src=/S/aflame.gif border=0 alt=aflame width=15 height=15> <img src=/S/laugh.gif border=0 alt=laugh width=15 height=15>

    Gary

  13. #13
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Standard Code (VBA)

    Well, the use of the named arguments at least helps keep it from being entirely obscure, but I would parboil anybody I discovered writing code like that without any comments to at least explain what the purpose of it was. When I've had junior programmers working for me, I have rather carefully reviewed their code to see whether they did, in fact, require parboiling. <img src=/S/cauldron.gif border=0 alt=cauldron width=20 height=20>

    Unfortunately, If-End If structures don't necessarily make code more comprehensible, even if they do sometimes make it easier to read. When I see a structure like this:

    If Me!ControlName = True Then
    blnFlag = True
    Else
    blnFlag = False
    End If

    I figure someone was trying for clarity but running on autopilot, since the same purpose could be accomplished more directly like this:

    blnFlag = (Me!ControlName = True)

    This is one of the places where I prefer concise code because to me the second construction is clearer than the first. <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15> In either case, I would comment the assignment to explain what it was for.
    Charlotte

  14. #14
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: Standard Code (VBA)

    This has helped me see the benefit of having worked alone the first year - I avoided the <img src=/S/cauldron.gif border=0 alt=cauldron width=20 height=20>, although not the <img src=/S/hairout.gif border=0 alt=hairout width=31 height=23>.

    It sounds like you promulgate a lot more commenting than I'm used to seeing (in the little team I work with). On the one hand simplest-common denominator coding methods are encouraged, but on the other, very minimal commenting is used (a la "'Set cover page formatting:', followed by 150 lines of code which achieve this).

    From the code samples that get posted here, it would seem that most people are doing very little commenting in their code.

    So while reasonable people are likely to differ widely on this, what's the correct degree of "granularity" for commenting code?
    Commenting every "phrase" (say 3-5 lines of code) makes the code easiest for another programmer to come in and work with, but could also make the code slower to read for a more advanced programmer. And lots of commenting also exacts a cost in simply all that typing of comments!
    Is there a happy medium and if so what is it?

    Gary

  15. #15
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Standard Code (VBA)

    I don't think you can go by what gets posted here, since that code may be written on the fly and without comments. Plus, comments are harder to read when they're the same color and font as the code and may be removed for brevity. However, I also think that most people rely on what they're doing being obvious rather than commenting to make sure it is.

    As for granularity, it depends on those same standards that may or may not be determined for your particular shop. I'm an extremely verbose commenter ( <img src=/S/hmmn.gif border=0 alt=hmmn width=15 height=15> no cracks, now, anyone!) and follow the principle of explaining :*everything*, even if it seems obvious. It was required when I was trained in VB and I got in the habit. Besides, what seems obvious when you write it may not be so obvious months or years down the road. I've inherited plenty of apps in the past that the author thought were obvious. Sometimes it takes hours to figure out not only what they were doing but *why*!

    So in my code, you tend to see comments every line or two (My VB instructor required every line to be commented). I write it as I go along, rather than going back later and adding it. I have to think through what I'm doing anyhow, so I don't feel it slows me down ... although maybe being a touch typist helps. <img src=/S/grin.gif border=0 alt=grin width=15 height=15> I think of it as pseudocode and it works much the same way. At any rate, I know that anyone who comes along and reads it won't have to wonder what I was doing or why because the comments explain it all. With VB/VBA code, the color difference for comments and code make it possible to skim over the comments, so I don't feel they make it any slower to read. If they do, I'll live with that in exchange for clarity. <img src=/S/yep.gif border=0 alt=yep width=15 height=15>
    Charlotte

Page 1 of 2 12 LastLast

Posting Permissions

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