Take the 2-minute tour ×

Is there a list of items on the web that you should not use when creating a model or variable?

For example, if I wanted to create apartment listings, naming a model something like Property would be problematic in the future and also confusing since property is a built-in Python function.

I did try Googling this, but couldn't come up with anything.


share|improve this question
Google for the specific language + reserved words. Searching for available operators can also be prudent as more languages are adopting specail use operators. –  rlemon Jun 24 '12 at 0:13
Very generic terms like property, context, description, info, attribute, are not necessary reserved but used frequently in API/framework. Try to stick names coming from the business domain of the app. –  ewernli Jun 25 '12 at 6:34
You might be interested to look at Variable Shadowing (en.wikipedia.org/wiki/Variable_shadowing), and Method Overloading (en.wikipedia.org/wiki/Function_overloading). Both should be avoided to avoid confusions. –  ewernli Jun 25 '12 at 11:44
@ewernli, Would you like to edit your comment and add your last comment as answer? That's actually what I'm looking for. Thank you for providing this and not an explanation for why I don't need a list of confusions. I'm actually writing an app that will be passed from Python to Javascript in the views, so one function in Python may not be a function in Javascript and vice versa. I don't know why the answerers assumed I'd be writing something in one language. –  AAA Jun 25 '12 at 23:16
@AAA Glad to hear it helped. I've added it as an answer. –  ewernli Jun 26 '12 at 7:33
add comment

3 Answers

up vote 1 down vote accepted

Rules and constraints about naming depend on the programming language. How an identifier/name is bound depends on the language semantics and its scoping rules: an identifer/name will be bound to different element depending on the scope. Scoping is usally lexical (i.e. static) but some language have dynamic scoping (some variant of lisp).

If names are different, there is no confusion in scoping. If identifiers/names are reused accrossed scopes, an identifier/name might mask another one. This is referred as Shadowing. This is a source of confusion.

Certain reserved names (i.e. keywords) have special meaning. Such keyword can simply be forbidden as names of other elements, or not.

For instance, in Smallatalk self is a keyword. It is still possible to declare a temporary variable self, though. In the scope where the temporary variable is visible, self resolves to the temporary variable, not the usual self that is receiver of the message.

Of course, shadowing can happen between regular names.

Scoping rules take types into consideration as well, and inheritance might introduce shadows.

Another source of confusion related to binding is Method Overloading. In statically typed languages, which method is executed depends on the static types at the call site. In certain cases, overloading makes it confusing to know which method is selected. Both Shadowing and Overloading should avoided to avoid confusions.

If your goal is to translate Python to Javascript, and vice versa, I guess you need to check the scoping rules and keywords of both languages to make sure your translation is not only syntactically correct, but also semantically correct.

share|improve this answer
add comment

Generally, programming languages have 'reserved words' or 'keywords' that you're either not able to use or in some cases are but should stay away from. For Python, you can find that list here.

share|improve this answer
I was looking more for a version that a programmer came up with that isn't "official" but is suggested. While I could name a model something like Property, it would not be recommended since the lowercased property is a Python function. –  AAA Jun 24 '12 at 0:25
@AAA: I am not sure what exactly you are asking about. What is your actual problem? Is it just conflicts with reserved words? Or something more than that? –  thkala Jun 24 '12 at 0:28
@AAA: As thkala mentioned, I'd just focus on naming things in a clear and sensible way that makes sense in the context of the project. –  gusp Jun 24 '12 at 0:40
I understand what all of you mean and that naming conflicting things already comes up with errors, but I just wanted a simple list -- something that maybe a blogger posted -- not an explanation for why I don't need a list. @thkala, I'm not sure I understand what you don't understand. Say, I personally would not name an application in Django called 'property' because property is a Python function -- and as it stands, you can name an application called property in Django. It's sort of like how you can name a variable with something like xyz, but a variable like that lacks clarity. –  AAA Jun 25 '12 at 0:44
add comment

Most words in most natural languages can have different meanings, according to the context. That's why we use specifiers to make the meaning of a word clear. If in any case you think that some particular identifier may be confusing, you can just add a specifier to make it clear. For example ObjectProperty has probably nothing to do with real estate, even in an application that deals with real estate.

The case you present is no different than using generic identifiers with no attached context. For example a variable named limit or length may have completely different meanings in different programs. Just use identifiers that make sense and document their meaning extensively. Being consistent within your own code base would also be preferable. Do not complicate your life with banned term lists that will never be complete and will only make programming more difficult.

The obvious exceptions are words reserved by your programming language of choice - but then again no decent compiler would allow you to use them anyway...

share|improve this answer
add comment

Your Answer


