Basic Do's and Don'ts
- don't use tabs
- don't use lines longer than 80 characters
- don't leave trailing whitespace
don't name functions or classes with Uppercase, CamelCase or lots_of_under_bars
- don't make helper functions prefixed with do_
- don't use underscores in identifiers in new code
in general, don't make mpm use his shift key any more than he has to
- don't use default arguments without a good reason
- don't use a class unless it makes your code smaller and easier to read
don't use Unicode strings unless you really grok Mercurial's charset philosophy
- don't put OS-specific hacks outside of util.py and friends
- don't use Python features from 2.5 or later (so no conditional expressions, unified try/except/finally)
- use single quotes rather than double quotes
- use a single underscore prefix for private methods and functions
- use a single underscore prefix for a helper function
- add a linebreak after a colon
- add docstrings
- use _() to mark things for i18n
- add testcases to the test suite
- run the test suite
follow the HelpStyleGuide when adding help texts
Rules for tabs and spaces in C
The source includes a helper script, contrib/check-code.py, to check code for 'style errors'.
Throughout the code, the following variables usually refer to the same thing:
a context.filectx instance
a python file(like) object
Status and error messages
Short messages should look like this:
Note the following:
it starts with a lower-case word.
it has no trailing full-stop (.).
Some existing strings don't follow this style and are kept like that for backwards compatibility reasons. But please write all new strings in this style.
The above message should look like this in your code:
ui.status(_('adding %s\n') % filename)
The _ function is used to mark the string as translatable. Import it from the i18n module.
The string interpolation is done after the call to the _ function.