When you work across multiple programming languages, there is a problem you encounter...

A valid name (identifier) in one language is invalid in another. For example...

var new function this are a keywords in JavaScript, but you can use them freely in Python. Similarly list dict def can be used in JavaScript without problems.

This is a very common and something programmers generally quickly become acquainted with when they program in multiple languages.

However, when you're working in collaboration, you have to lay out some rules/guidelines for your team members to ensure consistency and uniformity in the code. With teams, this issue becomes more important than simply remembering what's valid and what's not while you program.

So, my question is, what strategies you adopt...

  • simply take a union of all the reserved words present in all the languages you use, hand out a list to everybody and abstain their use?
  • accept the diversity and take extra pains when "context switching"
  • adopt an intermediate ground where one language can use the other's, but not vice-versa

(Note: i am only talking about Python and JavaScript in this question ... but please answer the question more broadly)

-- UPDATE --

Thanks for all the answers. So the general consensus i see emerging is to let programmers use any name regardless of what they do other languages -- as long as names are descriptive, it doesn't hurt.

  • 1
    Or just require that every variable name start with a $. It works in PHP, JavaScript, and some C/C++ compilers. In all seriousness, this is one thing PHP got right IMHO.
    – Joey Adams
    Commented Aug 11, 2011 at 0:16

9 Answers 9


Having programmed in quite a few languages over the 30+ years of my experience, I would say that trying to find naming standards that will work in any language is probably a pie in the sky idea.

Early on in my experience, I tried to use #define macros in C to create things that would make my C code look like the Pascal code that I was using before that. I was so used to programming in Pascal that I figured if I could just make C work like Pascal it would make me more productive. I soon discovered that I was wrong.

What made me more productive was to learn C and to not try to leverage Pascal syntax into another language just because it made me more comfortable.

I think you will be potentially constraining your programmers by prevent them from doing something in one language, just because it is wrong to do it in another language you are using.

If you limit your naming conventions to things that make sense to explain the variable use, then you will probably create good code, in whatever language.

  • 3
    Names that make sense is all the reason you need.
    – JeffO
    Commented Aug 10, 2011 at 18:36

You shouldn't be naming things "list", "new", "var", "this" in the first place, as they aren't descriptive enough in any language.

  • 2
    Ditto "function". If it's not a keyword, it's just not meant to be.
    – MPelletier
    Commented Aug 10, 2011 at 19:21

Switching from, say, javascript to python already is a context switch. I don't think it is bad if variable names shift, especially if the changes in name is idiomatic with the language. One could even argue harder context switches can help in this case as it helps reinforce "dude, you are writing javascript not python now."


I think that if you're using descriptive variable naming the problem you describe should be minimal. With that said, if it is minimal, then accepting the context shifting caused by variable naming between languages also becomes minimal.


Most reserved words (in any language) are pretty general. I prefer variable/function names that are more descriptive and that means I almost never encounter this problem. I should admit to having been infected by Charles Simonyi with his original naming scheme -- this was at Xerox in the late 70's, before it was even called Hungarian Notation -- and that also tends to mean that the names are something than no sane human would ever use as reserved words.


You shouldn't waste your time on writing guidelines until you discover this is an actual, not hypothetic problem.

One situation I can think of where this can become a problem is when you share data structures between programming languages. For example, if you have a Javascript object on the client side that is reflected in a Python object on the server side, and you naturally want them to have the same names for their members. In that case the rule is simple: Don't use names that are reserved words in any of the languages. That's it. Write that in the guidelines if you want to. Now move on to more important tasks.

BTW, neither list nor dict is a reserved word in Python. They can be used as variable names, though pretty lousy ones.


In my experience, the fix for this is to have broad naming conventions that apply to all languages. Whether it be JavaScript, C#, or some other funky language, the way variables and classes are named can become a standard within a code base which is how I'd generally see resolving this issue. The conventions can be agreed by consensus of everyone, simply a majority wanting a guideline, management saying, "This is how we do it," or a few other possibilities I'd imagine.

I rarely see the identifier problem you describe because most of the time my class or variable name is descriptive enough to not conflict so easily. At the same time, if one is working with others than having clarity on how does the team want to handle this is the important point.


I can't see how this could ever be a problem, unless you plan on moving code from one language to another. If you personally tend to forget what variable names are valid, then don't use a variable name unless you are personally sure it's valid. But if other people use invalid variable names, their code won't compile or run. So if you're working on someone else's code, and they called something 'var', you can be pretty sure it's a valid name on whatever language they're using.

If you might plan on moving code from one language to another, then you may need a list of prohibited names. For example, my C coding practices document prohibits using new or class as a variable because that makes the code harder to port to C++. In that case, it's reasonable to set rules that ease that job, should it become necessary,


Just stick to lower-case-leading CamelCase. It works everywhere. This is called looking for the lowest common denominator between incompatible systems, and you will find yourself doing this often!

  • 5
    Except in some languages the case of the first letter is significant syntax-wise. Commented Aug 10, 2011 at 19:54
  • 1
    ...and it violates the cultural quasi-standard established in many languages.
    – tdammers
    Commented Aug 10, 2011 at 21:45
  • Hungarian Notation is far more obfuscating that CamelCase...;-) Commented Aug 11, 2011 at 18:31
  • @Karl: obviously the suggestion is limited to the confines of the language. Did you know that Java can start variable names with a dollar sign? I've seen Java code that looks like PHP, it was obvious where the previous programmer learned to program!
    – dotancohen
    Commented Aug 28, 2011 at 15:58
  • @dotancohen: I remember looking at a pascal program in a hobby magazine many years ago, when pascal was just making the scene. It was glaringly obvious from the structure of the code (and the fact that they used global variables to pass values to subroutines and functions) that the program was one of the best basic programs I've ever seen written Pascal. ;-) Commented Nov 23, 2011 at 3:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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