Better use on the name of variables

Question

I have a method that looks like this:

Public Function NormalizeStreetAddress(country As Namespace.Country,
                                       streetAddress As Namespace.StreetAddress) _
                                   As Namespace.StreetAddress

        Dim _streetAddress As New Namespace.StreetAddress = streetAddress

        If My.Settings.Streeteable = True Then
            Dim _AddressCustom As New Namespace.AddressCustom
            _streetAddress = _AddressCustom.NormalizeStreetAddress(country, streetAddress)
        End If
        Return _streetAddress
End Function

I receive a streetAddress object, but inside the method I need to use another streetAddress object which I called _streetAddress — is that following the standard? A friend of mine told me that object names such as _yourNameObject are for global variables, but I can't find info about this and I want to make this method more readable.

According to this page: http://msdn.microsoft.com/en-us/library/aa240858%28v=vs.60%29.aspx globals should start with "g" not "_". I believe that the "_" prefix is for private members. In your case, why not call it `resultStreetAddress`? — FrustratedWithFormsDesigner, May 18 '12 at 21:01
Those standards are for Visual Studio 6.0, those it apply for now days? — Luis, May 18 '12 at 21:05
Some languages get pretty pissed off when you use '_' as the starting character in a variable name. — Edward Strange, May 18 '12 at 22:37

Arseni Mourzenko · Accepted Answer · 2012-05-18T21:06:18.157

6

The names of the variables must be explicit, i.e., when possible, the reader must know what is the variable just by looking at its name.

If you have both streetAddress and _streetAddress in the same code, there is a huge problem. Since the two variables are referring to something different, they should have different names.

Keeping both names is not only confusing, but extremely error prone. Would you be able to immediately make the difference between those two variables in six months when modifying some code in the middle of the method? If you type the wrong name and the program fails, would you be able to immediately see in the debugger where the error comes from?

What about:

Public Function NormalizeStreetAddress(country As Namespace.Country,
                                       streetAddress As Namespace.StreetAddress) _
                                       As Namespace.StreetAddress

    If My.Settings.Streeteable = True Then
        Dim _AddressCustom As New Namespace.AddressCustom
        Return _AddressCustom.NormalizeStreetAddress(country, streetAddress)
    Else
        Return streetAddress
    End If
End Function

edited May 18 '12 at 21:06

answered May 18 '12 at 21:01

Arseni Mourzenko

134,780
31
343
513

You're right, it's even optimized, sorry I can't give you +1, I'll do it as soon I reach 15 rep. – Luis May 18 '12 at 21:13
@Cuartico - Actually it's not optimized. In fact, not knowing VB this code either does exactly the same operations or is vastly different in behavior and cannot be used to replace the original. The VB docs aren't clear enough for me to immediately know whether class instances are "references" in VB. – Edward Strange May 18 '12 at 22:42
@Crazy Eddie: very probably the code will compile to the same IL (intermediary language code, executed by the virtual machine). So no, my version is not more optimized that the original one. – Arseni Mourzenko May 19 '12 at 00:32
@MainMa In your code, you're using 1 less variable, which means less memory space used, for that reason I'm assuming it has a better performance than the original one... – Luis May 19 '12 at 05:23
2

@Cuartico http://stackoverflow.com/questions/3411803/creating-temporary-variables-to-enhance-readability – Joel Sep 04 '12 at 12:21
Nitpick: if this is VB6 you can't use `Return streetAddress`, you have to say `Set NormalizeStreetAddress = streetAddress`. – Scott Whitlock Sep 04 '12 at 14:06
Also `Dim _AddressCustom As New Namespace.AddressCustom` is not a great way to do it if it's VB6. If you ever set `_AddressCustom` to `Nothing` then VB6 would instantly create a new instance of `Namespace.AddressCustom`. It's almost always better/safer to split it into 2 lines: `Dim _AddressCustom As AddressCustom` and then `Set _AddressCustom = New AddressCustom` – Scott Whitlock Sep 04 '12 at 14:08

score 1 · Answer 2 · answered Feb 05 '14 at 18:03

This is largely opinion, the only thing I care about when it comes to variable names is consistency. You want to have a flow from your project that is continued in all its facets.

I don't see why it would matter what it's named as long as it's not actively confusing it's function.

Furthermore, I'd really like to see people take on the modified-Hungarian notation.

Seriously, people too often name their variables like this

EXAMPLE OF BAD VARIABLE NAMES:

int statistic;
float statistics;
string stats;

What's wrong with that? Well, it is telling me that it's a statistic, but do I really need to dig through the code to find all these definitions? It would be good practice to do so, but it's also nice for a programmer to think ahead about others reading his code.

Example of good variable names:

int nStatistic; //n prefix for ints
float fStatistics; //f prefix for floats
string sStats; //s for strings

Of course, whatever you do the most important thing is CONSISTENCY. I don't want to get reading through your code, and half-way down you decided to start naming the variables after a different pattern.

That's a good point for variables, but when it comes to `objets`, how would you name it? Address or Car, for example. — Luis, Feb 05 '14 at 18:48
objects you get to choose, but once again, CONSISTENCY is key. Addresses? addrLocal addrHospital, etc. Car objects? carViper carSedan, etc. It's really not a set in stone thing for objects, but if you do it intelligently and consistently then it should make for readable code. — Mike, Feb 05 '14 at 19:39

Better use on the name of variables

2 Answers2