Naming Conventions - Visual Basic 2005

Naming Conventions - Visual Basic 2005

• Jack Logan

  I recommend you check out the .Net Framework help for "General Naming Conventions" (see ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.NETDEVFX.v20.en/dv_fxdesignguide/html/d3a77ea1-75d2-4969-a8c3-3e1e3e1aaedc.htm)

  In this document, one of the items in large bold type is , "Do not use Hungarian notation." This has been Microsoft's guidance since DotNet first came on the scene. The main reasoning is, since everthing is an object, don't embed the data type in the object's name. Make the object name reflect the business entity instead.

  In my experience, I still use a form of hungarian in some cases, but this is primarily to keep related items together when sorted alphabetically. Old habits are hard to break.

  Jim Wooley
  http://devauthority.com/blogs/jwooley

  
  
  

• Fernando Velásquez

  Call it what it is.

  if the textbox displays first name, call it 'firstName'

  if the button saves the data call it 'save'

  if the date time picker displays Hire Date, call it 'hireDate'

  
  
  

• shosholoza

  So in VBA would you go for

  Dim rstCustomers As ADODB.Recordset

  or

  Dim CustomersRecordset As ADODB.Recordset

  
  

• WaseemA

  I have had trouble with this myself. In my college classes (VBA/VB6.0) we were told to use Hungarian notation as nightwish shows, but, at least from what I've seen, a lot of the documentation just uses really long, descriptive varible names.
  
  Like, for instance, I was watching a video where a guy was creating a button for Print and a button for Print Preview, so he named them PrintButton and PrintPreviewButton which is fine with me (maybe printButton and printPreviewButton), but then he named the PrintDocument pd!! That just kind of felt inconsistent to me
  
  For my last few projects I have been trying to use my version of camelCase (printPreviewButton, etc), it's just hard to get away from Hungarian when it's been drilled into your head so much.
  
  

• Ponkan

  I had a link, but now I can't find it! However, it was quite old...so won't cover thing slike the SerialPort (spt) ColorDialog (cdlg).

  However, if you come up with reasonable names, it won't matter. The absolutely most important thing is to be consistent!

  The hungarin notation is a bit stale, now, with the vast array of objects it can be a bit confusing at times. The second most important thing is to use descriptive names that describes the objects function - and be consistent with them.

  If you want to use the prefixes in this way, then just use common sense. If you do this, and are consistent, and use descriptive names then anyone will be able to read your code (including yourself, 3 weeks later). The description of the name often indicates the type, anyway.

  Oh, and use comments: more comments are better than less comments (I personally like to see between 30% and 50% of lines in a program be comments).

  Such as:

  Dim i as Integer ' General looper variable
  ' Count of all the people with silly last names in the company
  ' from the employees database
  Dim PeopleRecordCount as Integer

  Just my 2 cents (pence, francs, euro-cents, etc.) on the subject.

  
  
  

• Chaxtor

  jwooley wrote:

  In my experience, I still use a form of hungarian in some cases, but this is primarily to keep related items together when sorted alphabetically.

  I thought this was the argument against hungarian notation.

  If you use hungarian, all your items get grouped by object type and not by functionality.

  To paraphrase Coad, 'if your object presents "Value" then thats what it is - Value. Call it that!'

  the reason being - next week, you might decide to use a different presentation object. what are you going to do rename the object

  Hungarian notation was always bad form. It was a total pain when it came to intellisense. I have 10 buttons on a form one of which is "Send" I want to type "SE" [ctrl]+[space] and see everything related to sending.

  
  
  

• Dave Mehl

  Yes, i inderstand your view on this. Even if i am not going to use the hungarian notation i would still prefer to use a standard coding method. I think that commenting and explanations would then be the best to describe the coding at hand and use a standard coding naming convention that suits you best.

  This maybe meaning that avoiding the old type of notation at all costs.

  I just think that using a standard is the most easy way to stay on top of the software that you are developing. Hence this being on VB, C# or C++ or any other software. Maybe just by making it simple and readable will be the best way to do it.

  
  
  

• Dan Suceava

  I've been coding in BASIC and VB since... well, before Bill (the other one) went to kindergarden. I've programmed in lots of languages and managed a number of development teams. I like hungarian notation because everything ISN'T an object once you assign a datatype to it. It helps keep my objects straight. However, there is the overriding principle here--be flexible with your development but be consistent. Hungarian notation is not that hard to read, but it's different for some (thus some of the resistance). It really makes no difference really. It's the human side of programming--a technique that makes code easier to read and understand. There are as many "standards" as there are types of Diet soda... choose one that works for you and your team and stick with it--until you (all) find something better.

  
  
  

• Mozylon

  On the other hand, there should be very little functionality in a form. A form's purpose is to present data and respond to events. Bind your controls to objects for presentation, call methods on your objects in response to events. Typically, if your methods are longer thatn 3 to 5 lines of code you are doing something backwards. If it appears that hungarian notation will make it more apparent what a method does, the method needs to be refactored. and the functionality probably needs to be delegated to the object that the form is presenting.

  In short, you shouldn't be looking at form code to understand the functionality of a program.

  Good code does not care what type something is. Neither does good process engineering. If you were telling someone how to fill out a deposit slip at a bank (a form) you wouldnt say:

  "Fill in the characters that are your name in the character box for name. Fill in the characters that are your account number in the character box for your account. List the floating point numbers that are your deposit items amounts in the floating point grid. write the floating point total in the character box labeled total." Do you see how unclear that is

  If I am in the state of hanging drywall and I ask for a nail, my assistant should hand me a drywall nail. I shouldnt have to ask for a drywall nail as the state of the environment should contain only an open box of drywall nails. If we change state to the roof for hanging shingles, again, all I should ask for is a nail, and now I should get a shingle brad, as the box of shingle brads should be open and the drywall nails should be put away as a result of the state change.

  The process of a nail request is the same and independent of the type!

  Again show me code that is more clear in hungarian, and I will show you how that code should be refactored. It detracts from the functionality of the code. Do you care what something is or do you care what something does That is the essence of Object Oriented Programming.

  Avoid wedding the name a variable to its type. The type may change. Yes the chances may be remote, but why risk that chance Avoid it at all costs.

  
  
  

• Svitlana

  But then in my opinion should there not be a standard for this sort of thing.

  I dont mind using either one of the Naming Convensions, but if you are working on a project and more than one person is working on it bith should try and keep the same sort of naming conventions.

  In my view I like to keep it short but not so that no one knows what it means. If you have a huge project with 10+ forms you start getting confused with all the commands etc naming. Using the default naming provided by the programming software is just way to long!

  Then you still have to ad your personel touch to it.

  Should someone, maybe the comunity come up with a stand naming convention

  Is there any views on these topics

  Ta

  
  
  

• mah_

  jwooley,
  
  Good link, thanks. I think this will help my code be a little more readable at least.
  
  
• Naming Conventions - Visual Basic 2005