Difference between revisions of "Preparing Code"
m |
|||
| (13 intermediate revisions by 4 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 [ | * You ''must'' complete and sign the [[Linden_Lab_Official:Contribution_Agreement]]. | ||
== Coding Standard == | == Coding Standard == | ||
Please read and follow | Please read and follow our coding standard: [[Coding_standard|Second Life coding standard]]. | ||
== Comments == | == 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 | 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 <code>// PATCH START</code> and <code>// PATCH END</code> 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. | 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. | ||
| Line 28: | Line 28: | ||
== Give Yourself Credit! == | == Give Yourself Credit! == | ||
While names | While names 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 | == 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. | 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 | 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. | ||
==When The Code Is Ready== | |||
See [[How To Submit A Viewer Change]] | |||
Latest revision as of 00:59, 27 January 2024
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 Linden_Lab_Official:Contribution_Agreement.
Coding Standard
Please read and follow our 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 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.