What is the naming convention in Python for variable and function?
Question:
Coming from a C# background the naming convention for variables and method names are usually either camelCase or PascalCase:
// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()
In Python, I have seen the above but I have also seen underscores being used:
# python example
this_is_my_variable = 'a'
def this_is_my_function():
Is there a more preferable, definitive coding style for Python?
Answers:
See Python PEP 8: Function and Variable Names:
Function names should be lowercase, with words separated by underscores as necessary to improve readability.
Variable names follow the same convention as function names.
mixedCase is allowed only in contexts where that’s already the prevailing style (e.g. threading.py), to retain backwards compatibility.
The coding style is usually part of an organization’s internal policy/convention standards, but I think in general, the all_lower_case_underscore_separator style (also called snake_case) is most common in python.
There is PEP 8, as other answers show, but PEP 8 is only the styleguide for the standard library, and it’s only taken as gospel therein. One of the most frequent deviations of PEP 8 for other pieces of code is the variable naming, specifically for methods. There is no single predominate style, although considering the volume of code that uses mixedCase, if one were to make a strict census one would probably end up with a version of PEP 8 with mixedCase. There is little other deviation from PEP 8 that is quite as common.
Most python people prefer underscores, but even I am using python since more than 5 years right now, I still do not like them. They just look ugly to me, but maybe that’s all the Java in my head.
I simply like CamelCase better since it fits better with the way classes are named, It feels more logical to have SomeClass.doSomething() than SomeClass.do_something(). If you look around in the global module index in python, you will find both, which is due to the fact that it’s a collection of libraries from various sources that grew overtime and not something that was developed by one company like Sun with strict coding rules. I would say the bottom line is: Use whatever you like better, it’s just a question of personal taste.
Personally I try to use CamelCase for classes, mixedCase methods and functions. Variables are usually underscore separated (when I can remember). This way I can tell at a glance what exactly I’m calling, rather than everything looking the same.
David Goodger (in “Code Like a Pythonista” here) describes the PEP 8 recommendations as follows:
-
joined_lower for functions, methods,
attributes, variables
-
joined_lower or ALL_CAPS for
constants
-
StudlyCaps for classes
-
camelCase only to conform to
pre-existing conventions
Typically, one follow the conventions used in the language’s standard library.
As mentioned, PEP 8 says to use lower_case_with_underscores for variables, methods and functions.
I prefer using lower_case_with_underscores for variables and mixedCase for methods and functions makes the code more explicit and readable. Thus following the Zen of Python’s “explicit is better than implicit” and “Readability counts”
As the Style Guide for Python Code admits,
The naming conventions of Python’s
library are a bit of a mess, so we’ll
never get this completely consistent
Note that this refers just to Python’s standard library. If they can’t get that consistent, then there hardly is much hope of having a generally-adhered-to convention for all Python code, is there?
From that, and the discussion here, I would deduce that it’s not a horrible sin if one keeps using e.g. Java’s or C#’s (clear and well-established) naming conventions for variables and functions when crossing over to Python. Keeping in mind, of course, that it is best to abide with whatever the prevailing style for a codebase / project / team happens to be. As the Python Style Guide points out, internal consistency matters most.
Feel free to dismiss me as a heretic. 🙂 Like the OP, I’m not a “Pythonista”, not yet anyway.
The Google Python Style Guide has the following convention:
module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name, local_var_name.
A similar naming scheme should be applied to a CLASS_CONSTANT_NAME
There is a paper about this: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
TL;DR It says that snake_case is more readable than camelCase. That’s why modern languages use (or should use) snake wherever they can.
further to what @JohnTESlade has answered. Google’s python style guide has some pretty neat recommendations,
Names to Avoid
- single character names except for counters or iterators
- dashes (-) in any package/module name
__double_leading_and_trailing_underscore__ names (reserved by Python)
Naming Convention
- “Internal” means internal to a module or protected or private within a class.
- Prepending a single underscore (_) has some support for protecting module variables and functions (not included with import * from). Prepending a double underscore (__) to an instance variable or method effectively serves to make the variable or method private to its class (using name mangling).
- Place related classes and top-level functions together in a module. Unlike Java, there is no need to limit yourself to one class per module.
- Use
CapWords for class names, but lower_with_under.py for module names. Although there are many existing modules named CapWords.py, this is now discouraged because it’s confusing when the module happens to be named after a class. (“wait — did I write import StringIO or from StringIO import StringIO?”)
Guidelines derived from Guido’s Recommendations
I personally use Java’s naming conventions when developing in other programming languages as it is consistent and easy to follow. That way I am not continuously struggling over what conventions to use which shouldn’t be the hardest part of my project!
Lenin has told… I’m from Java/C# world too. And SQL as well.
Scrutinized myself in attempts to find first sight understandable examples of complex constructions like list in the dictionary of lists where everything is an object.
As for me – camelCase or their variants should become standard for any language. Underscores should be preserved for complex sentences.
Whether or not being in class or out of class:
A variable and function are lowercase as shown below:
name = "John"
def display(name):
print("John")
And if they’re more than one word, they’re separated with underscore "_" as shown below:
first_name = "John"
def display_first_name(first_name):
print(first_name)
And, if a variable is a constant, it’s uppercase as shown below:
FIRST_NAME = "John"
a_real_python_is_a_snake. just_use_snake_case!
Coming from a C# background the naming convention for variables and method names are usually either camelCase or PascalCase:
// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()
In Python, I have seen the above but I have also seen underscores being used:
# python example
this_is_my_variable = 'a'
def this_is_my_function():
Is there a more preferable, definitive coding style for Python?
See Python PEP 8: Function and Variable Names:
Function names should be lowercase, with words separated by underscores as necessary to improve readability.
Variable names follow the same convention as function names.
mixedCase is allowed only in contexts where that’s already the prevailing style (e.g. threading.py), to retain backwards compatibility.
The coding style is usually part of an organization’s internal policy/convention standards, but I think in general, the all_lower_case_underscore_separator style (also called snake_case) is most common in python.
There is PEP 8, as other answers show, but PEP 8 is only the styleguide for the standard library, and it’s only taken as gospel therein. One of the most frequent deviations of PEP 8 for other pieces of code is the variable naming, specifically for methods. There is no single predominate style, although considering the volume of code that uses mixedCase, if one were to make a strict census one would probably end up with a version of PEP 8 with mixedCase. There is little other deviation from PEP 8 that is quite as common.
Most python people prefer underscores, but even I am using python since more than 5 years right now, I still do not like them. They just look ugly to me, but maybe that’s all the Java in my head.
I simply like CamelCase better since it fits better with the way classes are named, It feels more logical to have SomeClass.doSomething() than SomeClass.do_something(). If you look around in the global module index in python, you will find both, which is due to the fact that it’s a collection of libraries from various sources that grew overtime and not something that was developed by one company like Sun with strict coding rules. I would say the bottom line is: Use whatever you like better, it’s just a question of personal taste.
Personally I try to use CamelCase for classes, mixedCase methods and functions. Variables are usually underscore separated (when I can remember). This way I can tell at a glance what exactly I’m calling, rather than everything looking the same.
David Goodger (in “Code Like a Pythonista” here) describes the PEP 8 recommendations as follows:
-
joined_lowerfor functions, methods,
attributes, variables -
joined_lowerorALL_CAPSfor
constants -
StudlyCapsfor classes -
camelCaseonly to conform to
pre-existing conventions
Typically, one follow the conventions used in the language’s standard library.
As mentioned, PEP 8 says to use lower_case_with_underscores for variables, methods and functions.
I prefer using lower_case_with_underscores for variables and mixedCase for methods and functions makes the code more explicit and readable. Thus following the Zen of Python’s “explicit is better than implicit” and “Readability counts”
As the Style Guide for Python Code admits,
The naming conventions of Python’s
library are a bit of a mess, so we’ll
never get this completely consistent
Note that this refers just to Python’s standard library. If they can’t get that consistent, then there hardly is much hope of having a generally-adhered-to convention for all Python code, is there?
From that, and the discussion here, I would deduce that it’s not a horrible sin if one keeps using e.g. Java’s or C#’s (clear and well-established) naming conventions for variables and functions when crossing over to Python. Keeping in mind, of course, that it is best to abide with whatever the prevailing style for a codebase / project / team happens to be. As the Python Style Guide points out, internal consistency matters most.
Feel free to dismiss me as a heretic. 🙂 Like the OP, I’m not a “Pythonista”, not yet anyway.
The Google Python Style Guide has the following convention:
module_name,package_name,ClassName,method_name,ExceptionName,function_name,GLOBAL_CONSTANT_NAME,global_var_name,instance_var_name,function_parameter_name,local_var_name.
A similar naming scheme should be applied to a CLASS_CONSTANT_NAME
There is a paper about this: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
TL;DR It says that snake_case is more readable than camelCase. That’s why modern languages use (or should use) snake wherever they can.
further to what @JohnTESlade has answered. Google’s python style guide has some pretty neat recommendations,
Names to Avoid
- single character names except for counters or iterators
- dashes (-) in any package/module name
__double_leading_and_trailing_underscore__ names(reserved by Python)
Naming Convention
- “Internal” means internal to a module or protected or private within a class.
- Prepending a single underscore (_) has some support for protecting module variables and functions (not included with import * from). Prepending a double underscore (__) to an instance variable or method effectively serves to make the variable or method private to its class (using name mangling).
- Place related classes and top-level functions together in a module. Unlike Java, there is no need to limit yourself to one class per module.
- Use
CapWordsfor class names, butlower_with_under.pyfor module names. Although there are many existing modules namedCapWords.py, this is now discouraged because it’s confusing when the module happens to be named after a class. (“wait — did I writeimport StringIOorfrom StringIO import StringIO?”)
Guidelines derived from Guido’s Recommendations
I personally use Java’s naming conventions when developing in other programming languages as it is consistent and easy to follow. That way I am not continuously struggling over what conventions to use which shouldn’t be the hardest part of my project!
Lenin has told… I’m from Java/C# world too. And SQL as well.
Scrutinized myself in attempts to find first sight understandable examples of complex constructions like list in the dictionary of lists where everything is an object.
As for me – camelCase or their variants should become standard for any language. Underscores should be preserved for complex sentences.
Whether or not being in class or out of class:
A variable and function are lowercase as shown below:
name = "John"
def display(name):
print("John")
And if they’re more than one word, they’re separated with underscore "_" as shown below:
first_name = "John"
def display_first_name(first_name):
print(first_name)
And, if a variable is a constant, it’s uppercase as shown below:
FIRST_NAME = "John"
a_real_python_is_a_snake. just_use_snake_case!