Which abbreviations should we use for python variable names?

Question

In generally I\'m using the standard naming stated in PEP-8 for variables. Like:

delete_projects
connect_server

However sometimes I can\'t find

Answer 1

In your example, you have a function called delete_project. Wondering what to call the variable that stores the project to be deleted? Just 'project'!

def delete_project(self, project):
    del self.projects[project]

Simple.

Variable names don't have to be fully descriptive. Context can lend a lot to how we understand a particular name at a particular point in time. No need to say "this is the project to be deleted" when discussing a function that deletes project.

If you find function names are too long, they're probably doing too much. If you find variable names are becoming too long, think about their purpose in the current context, and see if part of the name can be implied.

Answer 2

This is a problem that kind of solves itself when you're doing OOP. The subject (project, configuration) is the class and the verb (delete, etc) is the method name ie:

class Workspace(object):

   def delete_project(self, project):
       log.info("Deleting", project.name)
       ...

Answer 3

I think long names are acceptable provided that they are descriptive. With a good editor/IDE, short names cannot save typing, while long but descriptive names can save the time of reading your code. So the length of the reading time of the name is much more important than the actual length of the name.

As for your example, project_name_to_be_deleted is fine. If you want to shorten it, I will suggest using project_name_to_del since del is a well-known abbreviation for delete (you can even find this in your keyboard). And the use conf as configuration is also popular. But don't go further. For example, proj2del is not a good idea.

Also, for internal/local things, it's fine to use short-not-so-descriptive names.

Answer 4

Very few names have "standard" abbreviations. What you think is "common" or "standard" is not the same for someone else. The time spent setting a good name is well invested, as code is read much more often than it is written. As an example, I've seen "configuration" abbreviated as "config" "cnfg" "cfg" "cnf" ...so the lesson is - don't abbreviate unless there is a very well known abbreviation of it!

Answer 5

pr_nm_del? You might as well let a cat name it. I believe abbreviations should be avoided at all cost, except well-known/obvious ones (like del, as mentioned in the comments - that one's even a language keyword!) that save a whole lot of typing.

But that doesn't mean overly verbose identifiers. Just as context is important to understand statements in natural languages, identifiers can often be kept much shorter (and just as understandable) by referring to context. In your example, project_name is perfectly fine - the procedure is already called delete_project, so project_name obviously refers to the name of the project to be deleted. Even name alone might be fine. No need to state that again by appending _to_be_deleted.