Trac Coding Style

Like most Python projects, we try to adhere to ​PEP 8 (Style Guide for Python Code) and ​PEP 257 (Docstring Conventions). Be sure to read those documents if you intend to contribute code to Trac.

Note that there could be that some of the current Trac code violates a couple of the rules stated below. We are always in the process of refactoring the offending modules so that all code uses the same conventions, though it's much better now than it used to be.

Naming conventions

• Package and module names should be all lower-case, words may be separated by underscores.
• Class names use CamelCase
  e.g. TicketModule
• Class names inheriting from trac.core.Interface use mostly CamelCase, but are prefixed by an "I" letter
  e.g. ITimelineEventProvider
• The names of functions, variables and class members use all lower-case, with words separated by underscores
  e.g. do_delete
• Internal methods and variables are prefixed with a single underscore
  e.g. _do_whatever_it_takes_to_delete

Miscellaneous

• Lines shouldn't exceed a length of 79 characters.
  No, it's not because we're mainly using VT100 terminals while developing Trac, rather because the diffs look nicer on short lines, especially in side-by-side mode.
• never use multiple statements on the same line, e.g. if check: a = 0.
• Prefer list comprehension to the built-in functions filter() and map() when appropriate.
• Use raise TracError("message") instead of raise TracError, "message"
• A little difference from ​PEP:0257: we usually don't insert a blank line between the last paragraph in a multi-line docstring and its closing quotes.
• Also, in docstrings, we make quite a liberal usage of WikiFormatting. This is even useful in some case, like for documenting Macros, as the macro classes docstrings are wiki-rendered when using the [[MacroList]].

---

See also: TracDev