Difference between revisions of "Preparing Code"
m (→Comments: & →Give Yourself Credit!: <code /> markup for paths, filenames and actual code) |
m (Text replacement - "http://lecs.opensource.secondlife.com/" to "http://lecs-opensource.secondlife.com/") |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 12: | Line 12: | ||
* Understand and use the [[Project Snowstorm#Processes|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. | * Understand and use the [[Project Snowstorm#Processes|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 [http:// | * You ''must'' complete and sign the [http://lecs-opensource.secondlife.com/SLVcontribution_agmt.pdf contribution agreement]. | ||
== Coding Standard == | == Coding Standard == | ||
Please read and follow the coding standard: [[Coding_standard|Second Life coding standard]] | Please read and follow the coding standard: [[Coding_standard|Second Life coding standard]]. Several common problems can be avoided by running the checks provided by our [[Mercurial Tools]]. | ||
== Comments == | == Comments == | ||
| Line 28: | Line 28: | ||
== Give Yourself Credit! == | == Give Yourself Credit! == | ||
While names and JIRAs shouldn't appear in source, they do belong in <code>doc/contributions.txt</code>. Please don't be shy about adding the issue label and adding your name. If you already have one or more entries in <code>contributions.txt</code> add new ones at the appropriate positions | While names and JIRAs shouldn't appear in source, they do belong in <code>doc/contributions.txt</code>. Please don't be shy about adding the issue label and adding your name. If you already have one or more entries in <code>contributions.txt</code>, add new ones at the appropriate positions (sorting yours, if desired). | ||
== One Change For One Issue == | == One Change For One Issue == | ||
Revision as of 14:16, 6 July 2017
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. Several common problems can be avoided by running the checks provided by our Mercurial Tools.
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. If you already have one or more entries in contributions.txt, add new ones at the appropriate positions (sorting yours, if desired).
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.