647
edits
Changes
Jump to navigation
Jump to search
Line 42:
Line 42: + +
Development Team/Code guidelines (view source)
Revision as of 11:50, 3 January 2010
, 11:50, 3 January 2010→Code style
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.