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
<[EMAIL PROTECTED]>
--
http://mail.python.org/mailman/listinfo/python-list
