Version 4 (modified by tom.prince, 3 years ago) (diff)


The Way We Do Things Now

What Do You Mean By 'Now'?

The Twisted project has a long history, and we have had several changes in policy throughout the history. If you try to base your changes off of the surrounding code, you may find that you're doing things in a way we've explicitly decided was the bad, old way. So please check this page when authoring a patch.

Why This Page?

Everything on this page really ought to be in the coding standard, but we don't update that often enough. One problem is that the coding standard is published with every major version, so it's easy to google and find the wrong version, and another is that the review process maybe isn't the best for coding changes. If you're updating this page please be aware that you should also eventually be updating the coding standard.

Finally, this page only documents changes in policy that are easy to become confused about by looking at common bad examples, not every policy that we have in the project. So even once we've completely caught up the coding standard and fixed all of its problems we may want to leave this in place as a brief checklist.

The Rules

We should start filling in some rules here.


Here are some rules that we haven't fully decided on yet, but you might want to be aware that we are discussing.

Provide tools for managing new deprecation policy
There should be some clear documentation on how to document tests.
Document when to use L{} and when to use C{}
The way to test the class implement interfaces should be documented.
Doccument why `assert` shouldn't be used.
Document policy regarding naming abbreviations, particularly with reference to RFCs
Document conventions for writting test assertions.
Mention the expectedExceptionTypes argument to failureResultOf