Difference between revisions of "Preparing Code"
m (→Less is more) |
m (→Less is more) |
||
| Line 34: | Line 34: | ||
Each submission should do exactly one thing. If you have three different bugs to fix, please submit three different change sets (unless they are very closely related and being treated as one item in the sprint). If you are unsure whether or not it is ok to combine changes into one submission, ask the Lindens. | Each submission should do exactly one thing. If you have three different bugs to fix, please submit three different change sets (unless they are very closely related and being treated as one item in the sprint). If you are unsure whether or not it is ok to combine changes into one submission, ask the Lindens. | ||
== Less | == Less Is More == | ||
Smaller change sets are easier to review and therefore more likely to be integrated quickly. This does not mean that you should omit comments or unit tests, however - adding to those is strongly encouraged. | Smaller change sets are easier to review and therefore more likely to be integrated quickly. This does not mean that you should omit comments or unit tests, however - adding to those is strongly encouraged. | ||
Revision as of 04:41, 7 September 2010
If you have a piece of source code (be it a fix, new feature, or optimization of existing code) prepare your changes in a way that makes it easy for the Lindens to incorporate them into the source code.
Good Change Practice
It's easy for the people who review and apply changes to be the bottleneck in the system. If you can make it easier for Lindens to understand, test, and integrate your change, it is much better for everyone concerned.
Before You Start
- Understand and use the Project Snowstorm Processes; making sure that your change is part of the plan is the most important thing you can do to get it accepted.
- You must complete and sign the contribution agreement.
Coding Standard
Please read and follow the coding standard: Second Life coding standard
Comments
Do not add issue numbers and your name to the code itself. While comments explaining code in a general working context are helpful and strongly encouraged, bracketing a change with comments like "// PATCH START" and "// PATCH END" does not add any information, and is likely to get your change returned for revision.
Do not comment out or use the preprocessor to disable code that you are replacing: just delete it. The source control system can find it again if we need it, and leaving dead code around makes things harder to read and much harder to search.
In short, make your change what is expected to appear in the final source.
Give Yourself Credit!
While names and JIRAs shouldn't appear in source, they do belong in doc/contributions.txt. Please don't be shy about adding the issue label and adding your name.
One Change for one Issue
Each submission should do exactly one thing. If you have three different bugs to fix, please submit three different change sets (unless they are very closely related and being treated as one item in the sprint). If you are unsure whether or not it is ok to combine changes into one submission, ask the Lindens.
Less Is More
Smaller change sets are easier to review and therefore more likely to be integrated quickly. This does not mean that you should omit comments or unit tests, however - adding to those is strongly encouraged.