[sugar] Python coding conventions
Wed Sep 27 23:54:44 EDT 2006
Looking at the code some there's really only two things that are not the
norm in Python coding these days:
* Tabs for indentation. I know some people feel really strongly that
tabs are right. Personally I feel the opposite. It was a topic of much
discussion at one time, but now spaces are the norm in all Python code.
I don't think consistency with non-Python code is important here, it's
not like you can copy and paste between languages.
* Module names. Specifically something like
sugar.presence.PresenceService -- the convention is now all lower case
for modules, with no underscores. The reason for this is that it makes
modules distinct from both functions and classes.
In this case when you see "PresenceService" in some code you don't know
if it is a class or a module. You have to scan back up to the import
statement to figure that out. And some places in the code it will be
spelled PresenceService.PresenceService (which always looks ugly),
others just PresenceService.
Otherwise there's distutils -- discussed separately.
Well, another pet peeve of mine is __ (double underscore). Double
underscore means class private -- as in subclasses won't have access to
it, not just external code. Unless they learn the not-very-secret trick
about how the name mangling works. Oh, and if the subclass has the same
name as the superclass (not unlikely) then it won't be private. I find
the whole thing really silly, and I think single underscore is Private
Enough For Anyone.
I guess the only other issue might be with the file layout, a little
related to distutils. For instance, why is there
source/sugar/services/presence and source/sugar/sugar/presence ?
On the subject of capitalization, in my own setups I'll often capitalize
the "distribution", i.e., the directory that contains the files that
make up the package (but not the package itself). So
source/Sugar/sugar, since source/Sugar isn't a Python package (and due
to capitalization looks less like one). And often any other directory
that might look like a Python package but isn't, I'll try to name in a
way that makes it obvious (e.g., by putting a "-" in the directory name
it clearly can't be a package).
Anyway, I think that's it for all the layout issues that have come to
mind. Now I have to go and digest the actual code ;)
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Sugar-devel