General Programming Advice Declarations

[paulthepaddy]

Hi Guys, this might seem a simple question, but its one that google isn't giving me much help with.

im looking to know what is the best way to use declarations.

what is the diffrence between dim and private?
is their any scenarios that i should use private over dim or dim over private.

but mainly properties. i understand properties are useful because of their 'get' & 'set'

EXAMPLE

Public Class Invoices
    Dim _InvoiceNumber As String
    Public Property InvoiceNumber As String
        Get
            Return _InvoiceNumber
        End Get
        Set(value As String)

        End Set
    End Property

    Public paid As Boolean 
End Class

The 'InvoiceNumber' needs to be uppercase contains a few letters and mainly numbers, so the 'set' will be useful for making sure that its is in uppercase and that its in the right format of our invoice number. but the 'DIM _InvoiceNumber' should i use dim or private or does it not matter.

AND

'Paid' doesn't need a 'set' or 'get' so a property doesn't give any advantages over Public as far as im concerned, but it is a property of an invoice object.
is it a case of i can do what i want and it doesn't really matter as long as it works. or is their a general GOOD programming rule to follow as such?

thanks guys, i know this isn't a help me kinda of question, but since i am re writing my app again.. would like to know peoples advice

 

[jmcilhinney]

'Dim' is the keyword that declares a variable, just as 'Property' declares a property, 'Sub' declares a subroutine and 'Function' declares a function. 'Dim' is the only way to declare a variable.

'Private' is an access modifier, like 'Public', etc. Access modifiers are added to member declarations to specify how that member can be accessed. They apply to all members, i.e. variables, properties, methods and events as well as types themselves.

When you declare a local variable, i.e. one inside a method, you obviously don't specify an access modifier because a local variable is not a member. When you declare any member, be it property, variable or otherwise, you can omit the access modifier and that member will take on the default access level, which depends on the member and the type it's declared in. For instance, variables are Private by default in a class and Public by default in structures. It is bad practice to omit access modifiers though. You should always specify the access level explicitly on every type and every member.

So, when you declare a local variable, you have no choice but to use 'Dim' alone. When you declare a member variable you should always specify an access modifier, which should pretty much always be 'Private' for variables. A full member variable declaration actually looks like this:

Private Dim someVariable As SomeType

As you can see, strictly speaking, you're using bot the access modifier and the variable declaration keyword. The VB compiler will remove the 'Dim' keyword if you have "pretty listing" turned on in the IDE options though, which is the default. In essence, a variable is the default member type, i.e. if you don't specify 'Property', 'Sub', 'Function', 'Event' or whatever then 'Dim' is assumed and the member is assumed to be a variable.

So, to sum up, use 'Dim' for local variables and use 'Private' for member variables. If you have a specific reason for a member variable being other than Private, which should be rare, then use the appropriate access modifier in place of 'Private'.

With regards to properties vs variables, as I've already said, variables should pretty much ALWAYS be Private unless you have a specific reason for doing otherwise. The fact that there doesn't seem to be an advantage to using a property is NOT a valid reason not to use one. It wasn't the case originally but VB now supports what's called "auto-implemented properties". This reduces the amount of code you need to write when you don't need any additional code in your property getter or setter. Instead of this:

Private _paid As Boolean

Public Property Paid() As Boolean
    Get
        Return _paid
    End Get
    Set(value As Boolean)
        _paid = value
    End Set
End Property

you can now do this:

Public Property Paid() As Boolean

Using a property then takes barely more code than using a variable and you still get the advantages of a property, e.g. it can participate in data-binding. If you need any additional code, e.g. validation or raising events, then you do need the full getter and setter.

 

[paulthepaddy]

Hi jmcilhinney, thanks for the reply, that sumed everything up in a nut shell, thanks, very helpful as always

 

[JohnH]

VB now supports what's called "auto-implemented properties". This reduces the amount of code you need to write

At least it reduces the amount of code you need to read, for a long time snippets has been available and all you need to write is "property" and press TAB to generate the standard property snippet. Intellisense auto-complete will actually reduce that so in most cases you can write "pro" press TAB to complete the word "property" then TAB again to invoke the snippet.

 

[paulthepaddy]

wow, thanks john, heard of snippits but never knew Exactly what they where or how to use them lol. that is easy .... as borat would say 'I LIKEEEE'