"As" Naming Convention [closed]

Question

I'm experimenting with a naming convention I've devised and am seeking opinion. It involves the use of an "As" infix, and at this point I am envisioning it in the context of JavaScript, C# and C++ coding to assist with clarity of data format/contract when dealing with conversions or multiple representations of the same inherent data or object.

Examples:

// ex 1. receive and convert user input.
string userInput = "123";
float userInputAsFloat = float.Parse(userInput);
int userInputAsInt = (int)Math.Round(userInputAsFloat);

// ex 2. prepare an object for json transport.
Dictionary<string,object> packet = new Dictionary<string,object>();
string packetAsJson = packet.ToJson();

// ex 3. interface with a component from various angles.
IUnknown foo = MyObjectFactory.CreateFoo();
IVisualizer fooAsVisualizer = (IVisualizer)foo;
ILocator fooAsLocator = (ILocator)foo;

Thoughts for/against? Does this convention have a name?

Answer 1

While generally it looks nice, and definitely better than the awful Hungarian style, where you put prefixes everywhere, even in obvious and self-descriptive cases, nevertheless I'd say write your programs so that there is no need to have the same piece of data in different formats within the same context.

For example:

function buildXmlRequest(name, email)
{
    return toXml({'request':
        {'name': name, 'email': email}});
}

function registerUser(name, email)
{
    if (!sendRequest('http://allusers.com/xml',
        buildXmlRequest(name, email)))
            throw "User registration has failed";
}

There is a slight bend toward functional programming here: as you can see there are no variables at all. The benefit of this is that small stateless pieces of code are usually less error prone, especially in dynamic languages, where a mistyped variable name can go unnoticed for a long time.

Another advantage of this approach is data is not kept in memory when it is no longer needed. In your example you have packet AND packetAsJson at the same time in memory (and they can be huge!) whereas most likely you need only one at a time. In reference-counted environments (PHP) or languages with scope-based garbage collection (C++) bringing some functional style into your program may save you a lot of resources.

But again, yes, I'd use this style whereever the functional approach doesn't help much.

Answer 2

Personally, I dislike this style. You already know that a float is a float (etc.) because you defined it as such, you don't need to have it in the name of the variable. It lengthens the variable names, without giving any new or useful information.

Answer 3

I think this naming convention can be useful, but I don't see as a convention to aim for, more as last resort if you can't name the variables in a more meaningful way. It seems to me that 2 of your examples are just a more long winded version of Hungarian notation.

The variable name should be about what the variable represents in your design. In your first example if the user input is parsed and converted to an int, what do you do with it next - maybe it's an ID, or a phone number, or a zip code. Whatever it is, the variable name should reflect that and there is no need to encode the type in the name.

I do understand that you may end up converting a type and both variables could equally justify using the same name - your second example might be a good example of this. In this case I do tend to agree with you and actually this isn't encoding the type in the variable name so I think it's not too bad. I think packetAsJson is a good name in this context.

Answer 4

What happens if you decided you need to change types? For instance, a float no longer has enough precision and you need to bump it up to a double. Now you have to refactor all of your variable names to use Double instead. While your IDE might have great refactoring tools, I think you'll find it difficult to maintain after a while.

Answer 5

In certain languages, this naming convention may be overkill, such as in Java:

List<String> inputsAsList = new LinkedList<String>(....)

Whoever must read this will soon be tired. However, in unityped languages it may be a good idea to remind oneself of the type the variable is used as, so that misuses like

inputsAsList = "foo"

will be exposed, if only to human readers.

Answer 6

When I have these kind of statements in my code, I usually do nothing more than append a simple i or f or just use the name of the class.

With the common usage of IDEs and, being C#, Intellisense, it doesn't really make sense to add these to your identifiers. It wastes time typing them and makes identifier too long.

Everything should be named in accordance to its context. If it's just a simple local variable, make it obvious but not cumbersome. You want to make a program, not write code for hours.

string input = "123.4";
float fval = float.Parse(input); // I understand what fval is.
int ival = int.Parse(input);

IUnknown foo = MyObjectFactory.CreateFoo();
IVisualizer visualiser = (IVisualizer)foo;
ILocator locator = (ILocator)foo;

Dictionary<string, object> packets = new Dictionary<string, object>();
string json = packets.ToJSON(); // it's obviously the JSON output of packets since that the only context 'json' could be for.

If you have multiple instances, just be a little bit more specific:

IUnknown srcFoo, destFoo;
IVisualiser srcVisualiser, destVisualiser;
ILocator srcLocator, dstLocator;

For objects like arrays:

string inputString = "1,2,3";
string[] separatedInputs = inputString.Split(',');
List<int> inputs = new List(separatedInputs.Length);
foreach(var input in separatedInputs)
    inputs.Add(int.Parse(input));