Added note about how attributes should be declared for instances.

docs/source/development/coding_guide.txt

@@ -1,78 +1,112 b''
 ============
 Coding guide
 ============
 
 General coding conventions
 ==========================
 
 In general, we'll try to follow the standard Python style conventions as
 described in Python's PEP 8 [PEP8]_, the official Python Style Guide.
 
 Other general comments:
 
 * In a large file, top level classes and functions should be separated by 2
   lines to make it easier to separate them visually.
 
 * Use 4 spaces for indentation, **never** use hard tabs.
 
 * Keep the ordering of methods the same in classes that have the same methods.
   This is particularly true for classes that implement similar interfaces and
   for interfaces that are similar.
 
 Naming conventions
 ==================
 
 In terms of naming conventions, we'll follow the guidelines of PEP 8 [PEP8]_.
 Some of the existing code doesn't honor this perfectly, but for all new
 IPython code (and much existing code is being refactored), we'll use:
 
 * All ``lowercase`` module names.
 
 * ``CamelCase`` for class names.
 
 * ``lowercase_with_underscores`` for methods, functions, variables and
   attributes.
 
 This may be confusing as some of the existing codebase uses a different
 convention (``lowerCamelCase`` for methods and attributes).  Slowly, we will
 move IPython over to the new convention, providing shadow names for backward
 compatibility in public interfaces.
 
 There are, however, some important exceptions to these rules.  In some cases,
 IPython code will interface with packages (Twisted, Wx, Qt) that use other
 conventions.  At some level this makes it impossible to adhere to our own
 standards at all times.  In particular, when subclassing classes that use other
 naming conventions, you must follow their naming conventions.  To deal with
 cases like this, we propose the following policy:
 
 * If you are subclassing a class that uses different conventions, use its
   naming conventions throughout your subclass.  Thus, if you are creating a
   Twisted Protocol class, used Twisted's
   ``namingSchemeForMethodsAndAttributes.``
 
 * All IPython's official interfaces should use our conventions.  In some cases
   this will mean that you need to provide shadow names (first implement
   ``fooBar`` and then ``foo_bar = fooBar``).  We want to avoid this at all
   costs, but it will probably be necessary at times.  But, please use this
   sparingly!
 
 Implementation-specific *private* methods will use
 ``_single_underscore_prefix``.  Names with a leading double underscore will
 *only* be used in special cases, as they makes subclassing difficult (such
 names are not easily seen by child classes).
 
 Occasionally some run-in lowercase names are used, but mostly for very short
 names or where we are implementing methods very similar to existing ones in a
 base class (like ``runlines()`` where ``runsource()`` and ``runcode()`` had
 established precedent).
 
 The old IPython codebase has a big mix of classes and modules prefixed with an
 explicit ``IP``. In Python this is mostly unnecessary, redundant and frowned
 upon, as namespaces offer cleaner prefixing. The only case where this approach
 is justified is for classes which are expected to be imported into external
 namespaces and a very generic name (like Shell) is too likely to clash with
 something else.  However, if a prefix seems absolutely necessary the more
 specific ``IPY`` or ``ipy`` are preferred.
 
 .. [PEP8] Python Enhancement Proposal 8.  http://www.python.org/peps/pep-0008.html
 
+Attribute declarations for objects
+==================================
+
+In general, objects should declare in their *class* all attributes the object
+is meant to hold throughout its life.  While Python allows you to add an
+attribute to an instance at any point in time, this makes the code harder to
+read and requires methods to constantly use checks with hasattr() or try/except
+calls.  By declaring all attributes of the object in the class header, there is
+a single place one can refer to for understanding the object's data interface,
+where comments can explain the role of each variable and when possible,
+sensible deafaults can be assigned.
+
+.. Warning::
+    
+    If an attribute is meant to contain a mutable object, it should be set to
+    ``None`` in the class and its mutable value should be set in the object's
+    constructor.  Since class attributes are shared by all instances, failure
+    to do this can lead to difficult to track bugs.  But you should still set
+    it in the class declaration so the interface specification is complete and
+    documdented in one place.
+
+A simple example::
+
+    class foo:
+        # X does..., sensible default given:
+        x = 1
+        # y does..., default will be set by constructor
+        y = None
+        # z starts as an empty list, must be set in constructor
+        z = None
+        
+        def __init__(self, y):
+            self.y = y
+            self.z = []