ASE Manual Release 3.6.1.2825 CAMd - CampOS Wiki

• Adding files or directories to version control:
svn add filename
ASE Manual, Release 3.6.1.2828
If filename is directory, also all the files within the directory are added. Note that svn commit is
required before the new files are actually included in version control.
• ASE documentation resides under doc directory, and is also under subversion control. See more at Writing
documentation.
11.1.5 Coding Conventions
Importing modules
In code, like the implementation of ASE, we must not use the import * syntax. Import everything explicitly
from exactly the place where it’s defined:
from ase.io import read, write
We distinguish between scripts and code. In your own scripts, it’s OK to use:
from ase.all import *
which will give you the most used symbols.
Python Coding Conventions
Please run pep8.py and pylint on your code before committing.
The rules for the Python part are almost identical to those used by the Docutils project:
Contributed code will not be refused merely because it does not strictly adhere to these conditions; as long as it’s
internally consistent, clean, and correct, it probably will be accepted. But don’t be surprised if the “offending”
code gets fiddled over time to conform to these conventions.
The project shall follow the generic coding conventions as specified in the Style Guide for Python Code and
Docstring Conventions PEPs, summarized, clarified, and extended as follows:
• 4 spaces per indentation level. No hard tabs.
• Very important: Read the Whitespace in Expressions and Statements section of PEP8.
• Avoid introducing trailing whitespaces.
• Try to use only 7-bit ASCII, no 8-bit strings.
• No one-liner compound statements (i.e., no if x: return: use two lines & indentation), except for
degenerate class or method definitions (i.e., class X: pass is OK.).
• Lines should be no more than 78 characters long.
• Use “StudlyCaps” for class names.
• Use “lowercase” or “lowercase_with_underscores” for function, method, and variable names. For short
names, maximum two words, joined lowercase may be used (e.g. “tagname”). For long names with three or
more words, or where it’s hard to parse the split between two words, use lowercase_with_underscores (e.g.,
“note_explicit_target”, “explicit_target”). If in doubt, use underscores.
• Avoid lambda expressions, which are inherently difficult to understand. Named functions are preferable
and superior: they’re faster (no run-time compilation), and well-chosen names serve to document and aid
understanding.
• Avoid functional constructs (filter, map, etc.). Use list comprehensions instead.
• Avoid from __future__ import constructs. They are inappropriate for production code.
11.1. Development topics 189