Changes

The community around Sugar is very diverse and only a small part of it is directly involved in software development. Of those, an even smaller part is personally responsible for the quality of the software, its growth, and its availability to translators, distributors and deployers. See [[Development Team/Release/Modules]] for a list of modules with their maintainers and peers.

The community around Sugar is very diverse and only a small part of it is directly involved in software development. Of those, an even smaller part is personally responsible for the quality of the software, its growth, and its availability to translators, distributors and deployers. See [[Development Team/Release/Modules]] for a list of modules with their maintainers and peers.

But this smaller group of people aren't the only ones that can contribute to the development of Sugar itself. Anyone with some spare time and enough skills and passion can make significant contributions to Sugar, but in order to bound to a limit the maintenance work, the submitted code needs to have some characteristics, explained in this page.

But this smaller group of people aren't the only ones that can contribute to the development of Sugar itself. Anyone with some spare time and enough skills and passion can make significant contributions to Sugar, but in order to bound to a limit the maintenance work, the submitted code needs to have some characteristics, explained on this page.

Please take these recommendations with a grain of salt, they are intended to make the life of your fellow developers easier, and are not intended to be general rules of "good programming".

Please take these recommendations with a grain of salt, they are intended to make the life of your fellow developers easier, and are not intended to be general rules of "good programming".

== It's all about communication ==

== It's all about communication ==

== Dependencies ==

== Dependencies ==

Dependencies need to be fulfilled on all platforms running Sugar (i.e. they need to be available at all and need to be installed which means occupying disk space), so think twice before introducing new ones. It's a always a good idea to check whether sufficiently recent versions of your proposed dependencies are already packaged for all (stable releases of the) major distributions, on '''all''' of their (semi-)supported architectures (e.g. ARM and PowerPC). If not, start requesting them (at the distribution bug trackers) ASAP and also mention it during [[Development Team/Code Review|Code Review]].

Dependencies need to be fulfilled on all platforms running Sugar (i.e., they need to be available for all and need to be installed, which means occupying disk space), so think twice before introducing new ones. It's always a good idea to check whether sufficiently recent versions of your proposed dependencies are already packaged for all (stable releases of the) major distributions, on '''all''' of their (semi-)supported architectures (e.g., ARM and PowerPC). If not, start requesting them (at the distribution bug trackers) ASAP, and also mention it during [[Development Team/Code Review|Code Review]].

== Code style ==

== Code style ==

Follow [http://www.python.org/dev/peps/pep-0008/ PEP 08], but as it is quite broad, it's not enough in itself to guarantee a minimum of consistency. Some more comments below.

Follow [http://www.python.org/dev/peps/pep-0008/ PEP 08], but as it is quite broad, it's not enough in itself to guarantee a minimum of consistency. Some more comments below.

Use inline comments sparingly. If you feel your code needs an inline comment, consider instead splitting the method in two, with a reasonable name and API comment. API comments should say '''what''' the code does, not '''how''' it does it. How your code works should be clear from the code structure, refactor until the code structure is a clear reflection of its purpose.

Use inline comments sparingly. If you feel your code needs an inline comment, consider instead splitting the method in two, with a reasonable name and API comment. API comments should say '''what''' the code does, not '''how''' it does it. How your code works should be clear from the code structure—refactor until the code structure is a clear reflection of its purpose.

Python is a very expressive language that allows for different programming models, before using the more exotic features consider readability over compactness and think that we want people to be able to contribute to Sugar without needing to be familiar with the whole Python syntax.

Python is a very expressive language that allows for different programming models, before using the more exotic features consider readability over compactness, and think that we want people to be able to contribute to Sugar without needing to be familiar with the whole Python syntax.

== Miscellaneous ==

== Miscellaneous ==

* Use logging.debug('foo %r bar', x) instead of logging.debug('foo %r bar' % x). This is more robust and formatting only happens if we actually log something.

* Use logging.debug('foo %r bar', x) instead of logging.debug('foo %r bar' % x). This is more robust and formatting only happens if we actually log something.

* When you catch an exception and want to log it, use logging.exception(), this will print the whole backtrace and exception information which is very useful when debugging.

* When you catch an exception and want to log it, use logging.exception(), this will print the whole backtrace and exception information, which is very useful when debugging.

== Tools ==

== Tools ==

When possible use tools to check your code, this will save lots of time for everybody involved.

When possible use tools to check your code, this will save lots of time for everybody involved.

Please try to use [http://www.logilab.org/857 pylint] to verify your patch for things like exceeding 80 columns etc., unused imports and unused variables. Pylint is not a tool you can rely on 100% but it helps to follow some guidelines and to avoid the most stupid errors like typos. sugar-jhbuild contains a pylintrc you can use in the <code>scripts/data</code> directory: [http://git.sugarlabs.org/projects/sugar-jhbuild/repos/mainline/blobs/master/scripts/data/pylintrc pylintrc] (follow "raw blob data").

Please try to use [http://www.logilab.org/857 pylint] to verify your patch for things like exceeding 80 columns etc., unused imports and unused variables. Pylint is not a tool you can rely on 100%, but it helps to follow some guidelines and to avoid the most stupid errors like typos. sugar-jhbuild contains a pylintrc you can use in the <code>scripts/data</code> directory: [http://git.sugarlabs.org/projects/sugar-jhbuild/repos/mainline/blobs/master/scripts/data/pylintrc pylintrc] (follow "raw blob data").

[http://svn.browsershots.org/trunk/devtools/pep8/pep8.py pep8.py] catches more style errors than pylint, so make sure to run that one, too.

[http://svn.browsershots.org/trunk/devtools/pep8/pep8.py pep8.py] catches more style errors than pylint, so make sure to run that one, too.