Development Team/Code guidelines - Revision history

Sascha silbe: /* Miscellaneous */ add guidelines on strings, highlight code, add hint on string logging

2010-11-09T17:46:54Z

Miscellaneous: add guidelines on strings, highlight code, add hint on string logging

← Older revision		Revision as of 13:46, 9 November 2010
Line 48:		Line 48:

	== 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 <code>logging.debug('foo %r bar', x)</code> instead of <code>logging.debug('foo %r bar' % x)</code>. This is more robust and formatting only happens if we actually log something.
			* When logging strings, consider using <code>%r</code> instead of <code>%s</code> because <code>%r</code> will take care of quoting and escaping the string as needed
	* 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.
			* "Short" string literals should use single quotes (<code>'</code>) unless the string contains a single quote (that would need to be escaped)
			* "Long" string literals should use three double quotes (<code>"""</code>)

	== Tools ==		== Tools ==

Patrol: moved Walter is a wanker 12/Code guidelines to Development Team/Code guidelines over redirect: revert

2010-02-24T01:33:03Z

moved Walter is a wanker 12/Code guidelines to Development Team/Code guidelines over redirect: revert

← Older revision		Revision as of 21:33, 23 February 2010
(No difference)

Page move vandal: moved Development Team/Code guidelines to Walter is a wanker 12/Code guidelines: Walter is a wanker

2010-02-24T00:21:18Z

moved Development Team/Code guidelines to Walter is a wanker 12/Code guidelines: Walter is a wanker

← Older revision		Revision as of 20:21, 23 February 2010
(No difference)

Patrol: moved Anal bleaching 15/Code guidelines to Development Team/Code guidelines over redirect: revert

2010-02-21T22:41:56Z

moved Anal bleaching 15/Code guidelines to Development Team/Code guidelines over redirect: revert

← Older revision		Revision as of 18:41, 21 February 2010
(No difference)

Anal bleaching: moved Development Team/Code guidelines to Anal bleaching 15/Code guidelines: Anal bleaching

2010-02-21T22:22:28Z

moved Development Team/Code guidelines to Anal bleaching 15/Code guidelines: Anal bleaching

← Older revision	Revision as of 18:22, 21 February 2010
(No difference)

Sascha silbe: /* Tools */ more detailed examples of how to run pylint / pep8

2010-01-31T11:46:31Z

Tools: more detailed examples of how to run pylint / pep8

← Older revision		Revision as of 07:46, 31 January 2010
Line 55:		Line 55:
	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. ~~To run it~~: "./sugar-jhbuild run pylint ~~sugar~~ jarabe".		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. It gets called with the name of the (installed) Python module to check, e.g. for sugar:
			./sugar-jhbuild build -n jarabe
			./sugar-jhbuild run pylint jarabe

	[http://github.com/cburroughs/pep8.py pep8.py] catches more style errors than pylint, so make sure to run that one, too.		You can also run it on individual files so you don't need to install first (doesn't work well for sugar-base and sugar-toolkit because they use the same module name):
			./sugar-jhbuild run pylint source/sugar-datastore/src/carquinyol/*.py

			[http://github.com/cburroughs/pep8.py pep8.py] catches more style errors than pylint, so make sure to run that one, too:
			./sugar-jhbuild run pep8 --repeat source/sugar-datastore/src/carquinyol/*.py

	In the sugar packages use 'make distcheck' to make sure all files are included and the POTFILES.in is up to date.		In the sugar packages use 'make distcheck' to make sure all files are included and the POTFILES.in is up to date.

Sascha silbe: /* Buildbot */ currently buildbot is only running the test suites (no style checks), reflect that in the wording and show how to do the same

2010-01-31T11:36:00Z

Buildbot: currently buildbot is only running the test suites (no style checks), reflect that in the wording and show how to do the same

← Older revision		Revision as of 07:36, 31 January 2010
Line 65:		Line 65:
	We are running periodic builds of Sugar using [http://buildbot.sugarlabs.org Buildbot]. If you break the build you are responsible to get it fixed. If you don't, the release team will take care of it, most likely by reverting your patch. More in detail:		We are running periodic builds of Sugar using [http://buildbot.sugarlabs.org Buildbot]. If you break the build you are responsible to get it fixed. If you don't, the release team will take care of it, most likely by reverting your patch. More in detail:

	* Every change that causes build or ~~check~~ failures should be immediately fixed or reverted.		* Every change that causes build or test suite failures should be immediately fixed or reverted.
	* Every change that causes ~~check~~ warnings should be fixed or reverted within 24 hours.		* Every change that causes pylint or PEP8 warnings should be fixed or reverted within 24 hours.

	You can ~~use~~ the check ~~command in jhbuild~~ to execute the same checks that [http://buildbot.sugarlabs.org/ Buildbot] is doing.		You can pass the <code>--check</code> option to [[Development Team/Jhbuild\|Jhbuild]] to execute the same checks that [http://buildbot.sugarlabs.org/ Buildbot] is doing:
			./sugar-jhbuild buildone -n --check sugar-artwork

	== References ==		== References ==

Tomeu: /* Tools */

2010-01-31T09:34:44Z

Tools

← Older revision		Revision as of 05:34, 31 January 2010
Line 55:		Line 55:
	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. To run it: "./sugar-jhbuild run pylint sugar jarabe".

	[http://github.com/cburroughs/pep8.py pep8.py] catches more style errors than pylint, so make sure to run that one, too.		[http://github.com/cburroughs/pep8.py pep8.py] catches more style errors than pylint, so make sure to run that one, too.

Tomeu: /* References */

2010-01-03T15:51:24Z

References

← Older revision		Revision as of 11:51, 3 January 2010
Line 75:		Line 75:

	http://developer.gnome.org/doc/guides/programming-guidelines/index.html		http://developer.gnome.org/doc/guides/programming-guidelines/index.html

	https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide		https://developer.mozilla.org/En/Mozilla_Coding_Style_Guide

	http://code.google.com/p/soc/wiki/PythonStyleGuide		http://code.google.com/p/soc/wiki/PythonStyleGuide

Tomeu: /* Code style */

2010-01-03T15:50:33Z

Code style

← Older revision		Revision as of 11:50, 3 January 2010
Line 42:		Line 42:

	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.

			Take your time when choosing names for variables and other identifiers, it's your best chance to make your code understandable along with code organization. The cost of interpreting abbreviated identifiers is most often not worth the less typing.

	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.