Naming Conventions	General Remarks	Coordinate Systems

Coding Guidelines

This not a `coding style' or something similar you are required to adhere to, just some remarks on writing maintainable and readable Python code (IMHO).

Import statements

Don't use from module import *

It is difficult to find out whether the code really depends on objects exported by the module. Editing the source or moving some parts of the code to other modules may result in code that doesn't need that module any more, so the import statement should be removed.

Using `import module' or `from module import foo, bar' makes this easier.

Multiple assignments

Don't use multiple assignments.

Multiple assignments are assignments like this:

	a, b = 0, 1

I think this is harder to read than

	a = 0
	b = 1

or, if you really want only one line,

	a = 0; b = 1

In the current interpreter (Python 1.5.1) the multiple assignment is even slower than two single assignments (for local variables; the interpreter actually builds a tuple and unpacks it immediately)

Multiple assignments are convenient, though, if the first assignment has side effects influencing the second assignment. If you want to swap the values of the variables a and b you may write

	a, b = b, a

Note that even in this case the traditional idiom for swapping variables, temp = a; a = b; b = temp is faster than multiple assignment (see Tools/swapbench.py).

Truth Values, __getattr__ and __len__

In various places, instance or class attributes have the value None to indictate that the attribute has no particular value, while, if the attribute is set, its value is an instance object (one such attribute is HierarchyNode's attribute parent). Functions and methods often return None instead of an instance object for similar reasons.

There are more cases, and, indeed, the following applies whenever you have an object that may be None or an instance object.

In all these cases, you have to test whether the object you have is None or not. It is tempting to write e.g.

	if self.parent:
		self.parent.SomePublicMethod()

Don't do that. Test whether the object is None:

	if self.parent is not None:
		self.parent.SomePublicMethod()

There are two reasons for this:

Firstly, if the object is an instance object, Python tries to determine if it is true or false by calling its __nonzero__ method and, if it doesn't have that method, its __len__ method. Now, most objects in Sketch don't have these methods, so Python tries to call the __getattr__ method, which many objects, including all graphics objects, have, twice, for __nonzero__ and __len__. This overhead can be avoided by testing for identity with None.

Secondly, even if you know that the object has no __len__ or __nonzero__ methods (and, hence, is always considered `true'), it may have them in future versions (the compound graphics objects might implement the Python sequence protocol and, accordingly, the __len__ method). In that case, code that simply tests whether the object is true would break, as the object might be false even though it is not None.

Naming Conventions	General Remarks	Coordinate Systems