[Checkins] SVN: zope3docs/source/codingstyle/ Get rid of ReST warnings.
Christian Theune
ct at gocept.com
Thu Feb 19 04:24:19 EST 2009
Log message for revision 96727:
Get rid of ReST warnings.
Start consolidating text, mainly moving Python coding style issues into
the `python-style` document.
Start a glossary.
Changed:
U zope3docs/source/codingstyle/checkin-guidelines.rst
D zope3docs/source/codingstyle/classesattributesmethods.rst
U zope3docs/source/codingstyle/file-structure.rst
U zope3docs/source/codingstyle/glossary.rst
U zope3docs/source/codingstyle/index.rst
U zope3docs/source/codingstyle/interface-style.rst
D zope3docs/source/codingstyle/nameskeysids.rst
U zope3docs/source/codingstyle/optimizations.rst
D zope3docs/source/codingstyle/python-naming.rst
U zope3docs/source/codingstyle/python-style.rst
D zope3docs/source/codingstyle/servicesevents.rst
U zope3docs/source/codingstyle/todocomments.rst
U zope3docs/source/codingstyle/writingtests.rst
U zope3docs/source/codingstyle/zcml-style.rst
-=-
Modified: zope3docs/source/codingstyle/checkin-guidelines.rst
===================================================================
--- zope3docs/source/codingstyle/checkin-guidelines.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/checkin-guidelines.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,3 +1,6 @@
+Check-in guidelines
+===================
+
Please be careful before a check in to make sure:
- All the code you are about to check in has reasonable test coverage.
Deleted: zope3docs/source/codingstyle/classesattributesmethods.rst
===================================================================
--- zope3docs/source/codingstyle/classesattributesmethods.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/classesattributesmethods.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,78 +0,0 @@
-1. General
-
- For everything these pages are not mentioning, we are using the style
- specified by the Python Style Guide. Most of the code I have seen in Zope 3
- so far uses the "capatalize new words" instead of "separate words by _"
- style. Also, in general long names are more descriptive than short ones.
- For example "speedOfLight" is much better than simply "c".
-
-
-2. Classes
-
- Classes should *always* start with a capital letter.
- Examples::
-
- Folder
- HTTPRequest
- HTTPViewRegistry
- ThisIsAVeryLongClassName
-
-
-3. Attributes / Properties
-
- Attributes always start with a lower case letter. Boolean-type attributes
- should always form a true-false-question, typically using "has" or "is"
- as prefix.
- Examples::
-
- title
- cssClass
- isRequired (boolean)
-
-4. Methods
-
- Methods also should start with a lower case letter. The first word of a
- method should always be a verb that describes the action.
- Examples::
-
- executeCommand()
- save()
- convertValueToString()
-
-<hr solid id=comments_below>
-
-
-gvanrossum (Jan 28, 2002 12:25 pm; Comment #1) --
- An important guideline would be to explain when it is appropriate
- for a method or instance variable name to start with an underscore.
-
-bwarsaw (May 24, 2002 11:10 am; Comment #2) --
- Guido's right, it would be helpful to understand Jim's recommendations regarding leading underscores. Here's mine, FWIW:
-
- - no leading underscores on public methods or attributes
-
- - a double leading underscore for names which describe private methods or attributes.
-
- - a single leading underscore for names which are not part of the public interface, but which might be of interest to subclasses.
-
- Yes, this means you should design for inheritance! At the very least you need to decide what the contract is between subclasses and superclasses, and I typically represent these decisions with single-underscore names. However, when in doubt, use single underscores instead of double underscores, otherwise it's a real pain to subclass.
-
-klm (May 24, 2002 11:36 am; Comment #3) --
- <pre>
- > bwarsaw (May 24, 2002 11:10 am; Comment #2) --
- > [...]
- > - a double leading underscore for names which describe private methods
- > or attributes.
- >
- > - a single leading underscore for names which are not part of the public
- > interface, but which might be of interest to subclasses.
- </pre>
-
- I do **not** think it's a good idea to use a name-mangling double underscore except when you actually *expect* that subclasses will need distinct but identically named methods (and ones which will not directly call the superclass versions, of course). (Maybe double underscore is also useful to protect some critical class invariant that uninformed use of the method would betray, but even there a decent warning in the code should suffice.)
-
- Why the emphatic tone? I have had grief developing against code where the other developer had used double underscores because *they* weren't going to use the method in a subclass - preventing me when i legitimately needed to do so.
-
- Further, double underscores impede interactive debugging - arriving in a context where things are already going wrong, and needing to scramble to uncover the mangling rule so you can invoke an obscured method, compounds the pain of the moment - and breaks pdb-track, besides.
-
- Please, avoid idealistic use of double-underscores - a single underscore is sufficient to signal intent, and does not present obstacles that are often unnecessary and sometimes counterproductive.
-
Modified: zope3docs/source/codingstyle/file-structure.rst
===================================================================
--- zope3docs/source/codingstyle/file-structure.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/file-structure.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,76 +1,9 @@
-Here I would just like to look at Python Source Files. These files should always contain the most actual license comment at the top followed by the
-module documentation string. The doc string will contain a reference about
-its CVS status in the first line; then the documentation follows.
-Here is the template::
+Python Source File structure
+============================
- ##############################################################################
- #
- # Copyright (c) 2002 Zope Corporation and Contributors.
- # All Rights Reserved.
- #
- # This software is subject to the provisions of the Zope Public License,
- # Version 2.0 (ZPL). A copy of the ZPL should accompany this distribution.
- # THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
- # WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
- # WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
- # FOR A PARTICULAR PURPOSE
- #
- ##############################################################################
- """One-line summary goes here.
- Module documentation goes here.
-
- $Id$
- """
-
Notes:
- - Doc strings:
-
- o The first line of the doc string should include a one-line
- description of the module (or class or function).
-
- o The first line may be followed by additional documentation
- paragraphs, if needed. The additional paragraphs must be separated
- from surrounding text and from each other by blank lines.
-
- o The revision id should come last.
-
- Here's an example::
-
- """Implement foo interfaces
-
- Blah blah
-
- blah some more
-
- $Id$
- """
-
- - Imports
-
- o All imports should be at the top of the module, after the module
- docstring and/or comments, but before module globals.
-
- It is sometimes necessary to violate this to address circular
- import pronlems. If this is the case, add a comment to the
- import section at the top of the file to flag that this was done.
-
- o Ordering
-
- - Start with imports for standard Python library modules
-
- - Next come imports from other parts of the Zope library
-
- - Next come imports from other parts of the current superpackage
-
- - Last come imports from the current package
-
- Leave a blank line between each group of imports
-
-
-<hr>
-
Some questions and suggestions (Guido):
Should the copyright years be exactly those years where this specific
Modified: zope3docs/source/codingstyle/glossary.rst
===================================================================
--- zope3docs/source/codingstyle/glossary.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/glossary.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,13 +1,53 @@
+Glossary
+========
+
This is a list of some common words that should have the same meaning throughout Zope. It is not exhaustive.
- 'key' -- See NamesKeysAndIds
+ID
+ The term 'id' should only be used when we are talking about an identifier
+ that is unique in the context of some particular id scheme. Examples include
- 'id' -- See NamesKeysAndIds
+ * A social security number, unique within a country's social secuity
+ bureaucracy
- 'manager' --
+ * A user id consisting of an NT Domain and a username, unique within
+ a Windows NT network
+
+ * A user id, unique within a Windows NT Domain
+
+ * A Windows NT domain, unique within a Windows network
+
+ We could consider the name of an object within a container to be an id within
+ the id scheme of that container, but this is not a particularly useful
+ way of thinking. One reason is that to identify the container, we need to
+ consider it as having an id within the id scheme of *its* container.
+
+ Id schemes should really be well-known points of reference within a system.
+ So, the model of Services in Zope 3 fits; you look up a service by its
+ id within the service manager id scheme.
+
+Key
+ We use an object's name to get it from within a container.
+ The container sees these names as 'keys', so from a container's point
+ of view, a name functions as a key to look up an object.
+
+ When we use the term 'key', we really mean "a name functioning as a
+ key in the context of a container".
+
+Manager
1. A user that configures components, such as a SiteManager. 2. An object that performs through the web configuration, such as a ServiceManager (which allows site managers to configure services.)
Generally, the word 'manager' is inappropriate for objects that don't perform through-the-web configuration. For example, global "service services" are not configurable through the web, but they were once called "service managers", and have now been renamed, since the name caused confusion with through-the-web configurable service managers.
- 'name' -- See NamesKeysAndIds
+Name
+ Objects are given names to help us find them. An object may be found
+ via more than one name. In Zope 3, we use names to guide the process
+ of traversing from a container to a contained object.
+
+References
+----------
+
+Martin Fowler, "Analysis Patterns: reusable object models", Addison Wesley
+1997. Chapter 5 "Referring to Objects" has a good discussion of names, ids
+and id schemes.
Modified: zope3docs/source/codingstyle/index.rst
===================================================================
--- zope3docs/source/codingstyle/index.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/index.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,9 +1,9 @@
-Zope 3 coding style
-===================
+Coding style
+============
-This area explains certain style elements (how to layout code written in
-Zope 3 projects, naming conventions) that are intended to help with
-achieving and maintaining a consistent code base.
+The coding style is intended to support a more consistent code base by
+laying out rules for how to work with Zope 3 code, for example how to
+structure files, format your source code and naming things.
.. note::
TODO This area includes code from the original Zope 3 wiki and needs
@@ -12,16 +12,13 @@
.. toctree::
:maxdepth: 1
- checkin-guidelines
- classesattributesmethods
file-structure
- glossary
interface-style
- nameskeysids
optimizations
- python-naming
python-style
- servicesevents
todocomments
- writingtests
zcml-style
+
+ checkin-guidelines
+ writingtests
+ glossary
Modified: zope3docs/source/codingstyle/interface-style.rst
===================================================================
--- zope3docs/source/codingstyle/interface-style.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/interface-style.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,4 +1,5 @@
Defining Interfaces
+===================
Status: IsDraft
Deleted: zope3docs/source/codingstyle/nameskeysids.rst
===================================================================
--- zope3docs/source/codingstyle/nameskeysids.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/nameskeysids.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,112 +0,0 @@
-Names, Keys and Ids
-
-Author
-
- "Steve Alexander":mailto:steve at cat-box.net
-
-Obligatory quotation::
-
- Everybody has a name, but names are only words
-
- "I'm not built for this"
- The Nilon Bombers
-
-Problem
-
- Sometimes we say 'key', sometimes 'name', and sometimes 'id'. This
- could get confusing, and we should try to be consistent. Here's a
- summary of how these terms are used.
-
- Key
-
- The IContainerPythonification proposal has been implemented, and
- components that are containers have methods to get at contained
- objects that look like '__getitem__(key)', 'get(key, default=None)',
- and 'setObject(key, object)'.
-
- Name
-
- We also have the notion that objects have names. For example the
- code below will give the name we used to traverse from someObject's
- container to 'someObject'::
-
- from Zope.App.Traversing import objectName
- print "someObject's name is ", objectName(someObject)
-
- There's also a view that works similarly to the 'absolute_url' view
- called 'object_name'. This can be used in Page Templates::
-
- <h3>Job #<span tal:replace="context/@@object_name">NN</span></h3>
-
- In this example, '@@object_name' gets you the 'object_name' view, which
- gets the same result as 'getAdapter(someObject, IObjectName)()'.
-
- Various documentation talks about "named objects". We talk informally
- about Services being identified by "name", even though they are really
- identified by an id.
-
- Id
-
- In Zope 2, content objects have a method 'getId()', and containers
- have methods 'objectIds()', '_setId()', and so on.
-
-
-Proposal
-
- This is my explanation, or rationalisation, of when to use the terms 'id',
- 'name', and 'key'.
-
- Id
-
- The term 'id' should only be used when we are talking about an identifier
- that is unique in the context of some particular id scheme. Examples include
-
- * A social security number, unique within a country's social secuity
- bureaucracy
-
- * A user id consisting of an NT Domain and a username, unique within
- a Windows NT network
-
- * A user id, unique within a Windows NT Domain
-
- * A Windows NT domain, unique within a Windows network
-
- We could consider the name of an object within a container to be an id within
- the id scheme of that container, but this is not a particularly useful
- way of thinking. One reason is that to identify the container, we need to
- consider it as having an id within the id scheme of *its* container.
-
- Id schemes should really be well-known points of reference within a system.
- So, the model of Services in Zope 3 fits; you look up a service by its
- id within the service manager id scheme.
-
- Name
-
- Objects are given names to help us find them. An object may be found
- via more than one name. In Zope 3, we use names to guide the process
- of traversing from a container to a contained object.
-
- Key
-
- We use an object's name to get it from within a container.
- The container sees these names as 'keys', so from a container's point
- of view, a name functions as a key to look up an object.
-
- When we use the term 'key', we really mean "a name functioning as a
- key in the context of a container".
-
-
-References
-
- Martin Fowler, "Analysis Patterns: reusable object models", Addison Wesley
- 1997. Chapter 5 "Referring to Objects" has a good discussion of names, ids
- and id schemes.
-
-
-
-<hr solid id=comments_below>
-
-
-bwarsaw (Jun 17, 2002 9:27 am; Comment #1) --
- We also have *message ids* which are unique identifiers for translatable messages within a particular application/product domain.
-
Modified: zope3docs/source/codingstyle/optimizations.rst
===================================================================
--- zope3docs/source/codingstyle/optimizations.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/optimizations.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,3 +1,6 @@
+Optimizations
+=============
+
Although code optimization is not the primary goal in the current development
cycle of Zope3, here are some rules that should make further optimizations and the possible use of unicode less painful.
Deleted: zope3docs/source/codingstyle/python-naming.rst
===================================================================
--- zope3docs/source/codingstyle/python-naming.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/python-naming.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,41 +0,0 @@
-Naming convention Python objects in Zope
-
- by JimFulton
-
- I've resisted establishing naming conventions, but enough people
- have asked that conventions be established (and that I follow them ;)
- that I've decided to write down some. So, here they are:
-
- 1. Use leading underscores as described in the "Python Style Guide",
- http://www.python.org/peps/pep-0008.html
-
- 2. Public global variables names are spelled with CapitalizedWords,
- as in 'Folder' or 'RoleService'.
-
- Interface names always start with a capital 'I', followed by a
- capital letter, as in 'IFactory'.
-
- An exception is made for global non-factory functions, which are
- typically spelled with [mixedCase].
-
- 3. Public attribute names are [mixedCase], as in "getService" or 'register'.
-
- 4. Local variables, including argument names
- LowercaseWithUnderscores, as in 'permission_id', or 'service'.
-
- 5. Single-letter variable names should be avoided unless:
-
- - Their meaning is extremly obvious from the context, and
-
- - Brevity is desireable
-
- The most obviouse case for single-letter variables is for
- iteration variables.
-
- Be tolerant of code that doesn't follow these conventions. We want
- to reuse lots of software written for other projects, which may not
- follow these conventions.
-
- A reasonable goal is that code covered by the ZPL should follow
- these conventions.
-
Modified: zope3docs/source/codingstyle/python-style.rst
===================================================================
--- zope3docs/source/codingstyle/python-style.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/python-style.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,48 +1,162 @@
-Writing Python code
-===================
+Python code
+===========
-Use PEP 8
----------
+The general rule when writing Python code is to follow PEP 8. The rules
+given below override what is said in PEP 8.
-In general any Python code should be written accordingly to PEP 8.
-
.. note::
Please be aware that PEP 8 recommends module-level consistency over blind
- rule-following. Zope 3 has been around for a while and earlier coding style of
- modules might not match thec current rules. In that case, please make a
+ rule-following. Zope 3 has been around for a while and older code may have
+ been written with a different set of rules.
+ modules might not match the current rules. In that case, please make a
conscious decision about a reasonable level of consistency.
-Additional rules
-----------------
+.. note::
+ TODO Provide link to PEP 8.
-Attribute names
-~~~~~~~~~~~~~~~
+License statement and module docstring
+--------------------------------------
+Python files should always contain the most actual license comment at the top followed by the
+module documentation string.
+
+The docstring will contain a reference about version control status. The
+example given is valid for at least CVS and Subversion.
+
+Here is the template::
+
+ ##############################################################################
+ #
+ # Copyright (c) 2009 Zope Corporation and Contributors.
+ # All Rights Reserved.
+ #
+ # This software is subject to the provisions of the Zope Public License,
+ # Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
+ # THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
+ # WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ # WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
+ # FOR A PARTICULAR PURPOSE
+ #
+ ##############################################################################
+ """One-line summary goes here.
+
+ Module documentation goes here.
+
+ $Id$
+ """
+
+
+Interface names
+---------------
+
+Interface names adhere to PEP 8's naming of classes, except that they
+are prefixed with a capital ``I``, as in ``IMagicThing``.
+
+
+Attribute and method names
+--------------------------
+
The naming of attributes as recommended by PEP 8 is controversial. PEP 8
-prefers `attribute_name` over `attributeName`. Zope 3 has been built originally
-with the latter rule and many APIs still use this meme.
+prefers ``attribute_name`` over ``attributeName``. Newer code tends to
+prefer the use of underscores over camel case. However, Zope 3 has been
+built originally with the latter rule and a lot of code still use this
+meme.
-Newer packages usually prefer to use underscores instead of camel case.
+Boolean-type attributes should always form a true-false-question,
+typically using "has" or "is" as prefix. Example: ``is_required`` instead
+of ``required``.
+Method names should always start with a verb that describes the action.
+
+Examples::
+
+ good:
+ first_name
+ is_required
+ execute_command()
+ save()
+ convert_value_to_string()
+
+ bad:
+ FirstName
+ required
+ command()
+ string()
+
+
+.. note::
+ TODO This rule needs clarification.
+
+
+Global variable names
+---------------------
+
+Public global variables names are spelled with CapitalizedWords, as in
+``Folder`` or ``RoleService``.
+
+An exception is made for global non-factory functions, which are
+typically spelled with ``mixedCase``.
+
+.. note::
+ TODO This rule needs clarification.
+
+
+Avoid single-letter variables
+-----------------------------
+
+Single-letter variable names should be avoided unless:
+
+ - Their meaning is extremly obvious from the context, and
+
+ - Brevity is desireable
+
+The most obviouse case for single-letter variables is for iteration
+variables.
+
+.. note::
+ TODO Does PEP 8 talk about this already?
+
+
Import ordering
-~~~~~~~~~~~~~~~
+---------------
-XXX Jim recommended ordering imports not as PEP 8 does (by creating blocks)
-but by simply using the output of `sort` on the block.
+All imports should be at the top of the module, after the module
+docstring and/or comments, but before module globals.
-This rule has not been officially agreed upon.
+It is sometimes necessary to violate this to address circular import
+pronlems. If this is the case, add a comment to the import section at
+the top of the file to flag that this was done.
+Order your imports by simply ordering the lines as `sort` would. Don't
+create blocks of imports with additional empty lines as PEP 8 recommends.
-Catch specific errors, keep try blocks minimal
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. note::
+ TODO This rule has been recommended by Jim but hasn't been
+ officially established.
-If you are converting a value to an `int`, and you want to catch conversion
-errors, you need only catch `ValueError`. Be sure to do the minimum possible
-between your `try:` and `except ValueError:` statements.
+Catch specific errors, write small ``try`` blocks
+-------------------------------------------------
-No trailing whitespace
-~~~~~~~~~~~~~~~~~~~~~~
+If you are converting a value to an ``int``, and you want to catch
+conversion errors, you need only catch ``ValueError``. Be sure to do the
+minimum possible between your ``try:`` and ``except ValueError:``
+statements.
-Trailing whitespace should not occur, nor should blank lines at the end of
-files.
+
+Don't leave trailing whitespace
+-------------------------------
+
+Trailing whitespace should not occur, nor should blank lines at the end
+of files.
+
+
+Be tolerant
+-----------
+
+Be tolerant of code that doesn't follow these conventions. We want to
+reuse lots of software written for other projects, which may not follow
+these conventions.
+
+A reasonable goal is that code covered by the ZPL should follow these
+conventions.
Deleted: zope3docs/source/codingstyle/servicesevents.rst
===================================================================
--- zope3docs/source/codingstyle/servicesevents.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/servicesevents.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,36 +0,0 @@
-Services and Events
-
- A common pattern is where you have a persistent Service that uses
- subobjects as plugins.
-
- An example of this is the CachingService which contains Caches.
- The CachingService does not need to subscribe to events.
- The Caches need to subscribe to ObjectModifiedEvents.
- (They don't subscribe to moves or deletions, because the cache will
- time-out anyway before too long.)
-
- The Caches should not be subscribed directly to the EventService because
- the CachingService they are within may or may not be bound as a service.
- They should only be subscribed to the EventService when the CachingService
- is an active service.
-
- One way around this is to make the CachingService binding-aware, and also
- make the Caches binding-aware, and have the CachingService pass on such
- binding change notifications to the Caches.
-
- Another solution is to make the CachingService binding-aware, and also
- make it an EventChannel. There is a base-class that can be mixed into the
- CachingService implementation to make it a binding-aware EventChannel that
- subscribes to and unsubscribes from the EventService as required.
-
- In this case, a Cache can simply subscribe to its CachingService when it
- is added, and unsubscribe if it is removed.
-
-
-
-<hr solid id=comments_below>
-
-
-stevea (Nov 22, 2002 12:53 pm; Comment #1) --
- A note from the pope: services such as this on generally shouldn't have subobjects that do work. The subobjects should be added to a persistent package, and the service should be configured to use them from there. This page will be refactored to take this into account soon.
-
Modified: zope3docs/source/codingstyle/todocomments.rst
===================================================================
--- zope3docs/source/codingstyle/todocomments.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/todocomments.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,4 +1,5 @@
TO-DO Comments
+==============
Occassionally you may need to note places in code that need to be
revisited later. There are three standard codes used in Python
Modified: zope3docs/source/codingstyle/writingtests.rst
===================================================================
--- zope3docs/source/codingstyle/writingtests.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/writingtests.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,3 +1,6 @@
+Writing tests
+=============
+
For any module 'somepkg.somemod' there should be a corresponding
unit test module 'somepkg.somemod.tests.testSomemod'. Or if more than one
set of unit tests is desired, multiple test modules of the form
Modified: zope3docs/source/codingstyle/zcml-style.rst
===================================================================
--- zope3docs/source/codingstyle/zcml-style.rst 2009-02-19 09:24:17 UTC (rev 96726)
+++ zope3docs/source/codingstyle/zcml-style.rst 2009-02-19 09:24:19 UTC (rev 96727)
@@ -1,3 +1,6 @@
+ZCML style conventions
+======================
+
ZCML file naming conventions
zcml configuration for a package should, in general, be placed in a
More information about the Checkins
mailing list