Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.


// 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?

share|improve this question
Reverse Hungarian Notation? –  njd Apr 8 '11 at 13:00
why not flt_userInput, int_userInput, str_userInput ? –  Imran Omar Bukhsh Apr 11 '11 at 8:31
@Imran Omar Bukhsh: because that tells you nothing of interest. Your prefixes should indicate why you've made your user input into a float or int or whatever. –  Matt Ellen Apr 11 '11 at 8:59
@Matt Ellen: an example and I could maybe understand better. Anyway a microsoft's book recommended using txt_username, btn_submit. Like that to denote the type of object –  Imran Omar Bukhsh Apr 11 '11 at 9:15
@Imran Omar Bukhsh: A good explanation is given here: joelonsoftware.com/articles/Wrong.html In the context of buttons and text boxes, you should already know what kind of control you are dealing with, calling a button submitSignupDetails is pretty self explanatory, I don't need btn in front of it. txt_username is sort of OK, but I would prefer just userNameInput, for full disambiguation. –  Matt Ellen Apr 11 '11 at 10:28

6 Answers 6

up vote 8 down vote accepted

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.

share|improve this answer
+1 for same context, same data, same type. Right on spot. –  back2dos Apr 8 '11 at 12:44
The Hungarian notation would good be a naming convention if Microsoft hadn't broken it. The notation should not state the type but the nature of the variable content. For string the microsoft way of doing it is prefix everything with a "s" so all the strings are the same, but if you use it to qualify a string as safe (from the system) and un-safe (from the user) you will have something clearer to work with like usName = fromFormElement and sName = fromDatabase. You can read more on that on joelonsoftware.com/articles/Wrong.html –  JF Dion Apr 8 '11 at 12:59
Nice way of putting it. I must say I have at times used the 'as' infix (example in struts where particular 'id' is string and then you want to convert it 'as' type) but also in the mean time extracted to a separate function to return or do something. Must admit never really thought about the slight bend to functional programming here though. Interesting! –  MalsR Apr 11 '11 at 9:22
Actually, the original Microsoft convention for a string was to prefix it with, for example, lpz if what you were actually dealing with was a long pointer to a null-terminated string, because Hungarian notation was invented to try to add a level of readability to C code, where C is a very loosely typed language and a pointer can point at pretty much anything, and you can easily change a string pointer to point at something that is not a string, and so on. Part of the reason Hungarian notation makes less sense today (in favor of semantic naming) is that modern languages are strongly typed. –  Craig Apr 18 '13 at 16:20
@JFDion: It would be a great naming convention if it were used to distinguish references to entities, references to values that may be changed but not shared, references to values that may be shared only with code that won't change them, and references to immutable values. It's generally impossible to write good and efficient code without knowing which references are of which of the above kinds, but the type system offers zero assistance. –  supercat Mar 3 at 21:13

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.

share|improve this answer
Thanks for the response. I updated my code example to be clearer. What would you do in example one where you need to store what is essentially the same data but in two different variables (and two different formats)? –  DuckMaestro Apr 8 '11 at 8:40
Why would you need to do that (convert it to both a float and an int and have them hanging around)? Generally I will label the user input "input", and the value parsed from that something context-dependent based on what it actually is. –  TZHX Apr 8 '11 at 8:52
The float and int in my example is a bit contrived, but the main point is that there is both a string and its value parsed as number. Your second point makes sense though. –  DuckMaestro Apr 8 '11 at 17:28

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.

share|improve this answer

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.

share|improve this answer
That's fair point in general, however in my case (I failed to specify) I treat "xxAsFloat" as referring to the inherent data having been stored as flointing point number of unspecified precision, and "xxAsInt" as referring to the inherent data having been stored as an integer of unspecified bounds. The example itself is contrived, but is it an example nonetheless of referring to the same inherent data but through multiple, different representations. –  DuckMaestro Apr 11 '11 at 2:26
@DuckMaestro - With your explanation, it makes sense...but would it be obvious to the next guy working on your code? –  Jordan Parmer Apr 11 '11 at 11:49

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.

share|improve this answer
In that case, I would ditch the conjunction as it slows the reading of the identifier. Something as simple as inputList = [ a, b, c ]. It's a "list" or "inputs". –  Nick Bedford Jan 31 '12 at 2:44

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)
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.