[Zope3-dev] Re: Code cleanup day

[Philipp von Weitershausen]

Stephan,

short answer: good idea. If I may add to the list of cosmetic surgeries 
to be done:

1. Use new-style classes whereever possible. Need to decide whether to 
subclass object or use __metaclass__ = type or both

2. Enforce http://dev.zope.org/Zope3/ZCMLStyleGuide. According to what 
I've seen in checkins, people seem to have different taste with how ZCML 
should be formatted, and seldomly look at the before mentioned style 
guide. I've actually seen correct format being "beaufified" incorrectly.

3. Schema fields accept both a pair of title/description OR __doc__ (as 
  keyword argument). The former is used throughout the whole Zope3 
source, except when Jim edited it... then it's using __doc__ ;)

I can see why people would prefer __doc__, but using title/description 
is much better for schemas that are going to be used as a basis for Web 
forms later (think: i18n, explicit message ids, etc.).

If people would *still* like to use the __doc__ facility, we should at 
least make this a non-keyword argument... Field(__doc__="Foo") is just ugly.

4. Revalidate all ZPTs against the XHTML DTDs and review them for known 
browser issues (<br/> ==> <br />). I've done this last year already, but 
there were a lot of checkins since, a few of them in which I already 
noticed incorrect XHTML.

5. Make the commonly long list of imports more scrutable. I haven't 
found anything in the coding style, but I usually follow this order::

   1. Import modules from standard python library/global ackages
   2. Import modules from the 'zope' package
   3. Import modules from the 'zope.app' package

while "import XYZ" goes before "from XYZ import ABC".

E.g.::

   import os
   from smtplib import SMTP

   from zope.configuration import xmlconfig
   from zope.security import getProxy

   from zope.app.tests import PeacefulSetup
   from zope.app.browser.form.widget import ListWidget

IMHO, this visual aid will make it a lot easier when we will have to 
determine package dependencies. While we will probably have a tool to 
extract those at some point, the developer still needs to be aware of 
the what he/she's importing. Give you an example: a 'zope' package 
should hardly ever import something from 'zope.app'. Sadly, some do :(

> To make a better release of Zope X3.0 possible, I would suggest that
> we have a code cleanup day after Zope X3.0 beta 1 somewhen in April.

The idea of a "spring cleaning day" is kinda cool. We could make this an 
annual thing; I'm sure we'll have something to do *every* year.

Philipp