Well written open source Python apps

[Micah Elliott]

On Oct 13, Grig Gheorghiu wrote:
> This is really synchronicity in action! I started to think yesterday
> about putting together a project that measures the 'goodness' of Python
> packages in the PyPI Cheese Shop repository. I call it the "Cheesecake"
> project. I took the liberty of citing Micah's post in a blog entry that
> I just posted:
> <http://agiletesting.blogspot.com/2005/10/cheesecake-how-tasty-is-your-code.html>

Grig, I think you're onto something here; good idea.  I have no
experience with CPANTS, and I'm not sure how many of my ideals could be
checked programmatically.  But if your Cheesecake tool comes into
fruition, here are some things that I would personally find useful:

* A command-line version that I could easily run on my projects.

* An output that gives more than just an index/score; maybe a bunch of
  stats/indicators like pylint.  I.e., it would be say "pypkglint" or
  "pydistchecker", a higher level lint that operates on packages instead
  of just source files.

* Some checks that might be useful

   - Module and package naming conventions. (PEP-8 describes
     module-naming, but I see this broken more often than followed in
     practice.  And it is silent on package names, but the tutorial uses
     capitalized names.)  Some consistency here would be nice.

   - Existence of standard files.  ESR goes into detail on this in his
     "Art of UNIX Programming" book (pp 452).

   - Existence of standard directories (those I mentioned before).

   - Output of checkee "--help" should satisfy some standards.  I presently
     check my own tools by running "help2man" which forces me to setup
     optparse to follow a strict format.  I have some active RFEs on
     optik (optparse) to address this.

   - Use of distutils.  Maybe just a check for setup.py ?

   - Consistency of module length.  Not sure about this one, but you
     might lower the score if some package modules are 10 lines while
     others are 10KLOC.

   - Number of modules per package.  Maybe 4..20 is a good amount?

   - Extra points for existence of something like "api.html", which
     indicates that epydoc/pydoc generated API info.

   - Extra points for .svn/CVS/RCS directories indicating that version
     control is in place.  Maybe even glarking of version numbers where
     high numbers indicate that code is checked in frequently.

   - Use of ReST in documentation, or even in docstrings.

   - Count of unit tests.  Do module names map to test_<modulename> in
     test directory?  How many testXXX functions exist?

   - A summary calculation of pylint/pychecker scores for each module.

   - Point deduction (or fail!) if any .doc/.xls, etc. files included in
     distribution.

   - Extra points for use of modules that indicate extra usability was
     incorporated, such as: gettext (multi-language), optparse (clean
     UI), configparser (fine control), etc.

* A PEP describing the conventions (though some will argue that PEPs
  should be enforcable by the compiler, so maybe just a "Cheesecake
  Convention" document).

* And of course anything that CPANTS offers :-)

I'm sure people here have more ideas for quality indicators...

-- 
Micah Elliott
<mde at micah.elliott.name>