Development guidelines

From World Wind Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 23:02, 27 March 2007 (edit)
Bull (Talk | contribs)
m (Developer guidelines moved to Development guidelines: more descriptive)
← Previous diff
Current revision (10:59, 30 January 2018) (edit) (undo)
Bull (Talk | contribs)
m (Reverted edits by Monday (Talk); changed back to last version by Mkpl)
 
(8 intermediate revisions not shown.)
Line 1: Line 1:
==Code policy== ==Code policy==
-* Every function/method must be documented using XML Comments. The documentation should contain:+* Every public function/method must be documented using XML Comments. The documentation should contain:
** Input parameters, including acceptable value ranges if non-obvious ** Input parameters, including acceptable value ranges if non-obvious
** Output values, if any ** Output values, if any
Line 6: Line 6:
** Description of what the function does, including side effects ("also increments current frame number by one") ** Description of what the function does, including side effects ("also increments current frame number by one")
** Name of original author (jira username and/or email address) ** Name of original author (jira username and/or email address)
 +* Please also read the [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp MSDN guidelines]
==SVN policy== ==SVN policy==
Line 12: Line 13:
* If you intend to be an active contributor contact baker99@gmail.com with reasons why you need access, your coding experience, and preferably the first piece of code you want to commit. * If you intend to be an active contributor contact baker99@gmail.com with reasons why you need access, your coding experience, and preferably the first piece of code you want to commit.
===Notes on committing to SVN=== ===Notes on committing to SVN===
-* Every commit must have one corresponding [http://issues.worldwind.arc.nasa.gov/secure/Dashboard.jspa JIRA] issue. This issue code must be the first item in your commit message, followed by a colon. For example, a typical commit message looks like this: ''WW-778: Improved rendering performance with hardware vertex buffers.''+* Every commit must have one corresponding [http://issues.worldwind.arc.nasa.gov/secure/Dashboard.jspa JIRA] issue. This issue code must be the first item in your commit message, followed by a colon. For example, a typical commit message looks like this: ''WW-778: Improved rendering performance with hardware vertex buffers.'' See also: [http://mail.worldwindcentral.com/pipermail/worldwind-dev/2005-May/000071.html New checkins policy: Creating JIRA issues for checkins] from [[Mailing Lists|[Worldwind-dev]]] mailing list.
** Do not bundle up several issue codes in one commit; make a separate commit for each issue. This allows better tracking of what actually changed in response to each issue. ** Do not bundle up several issue codes in one commit; make a separate commit for each issue. This allows better tracking of what actually changed in response to each issue.
** Do not bundle up several bugs/features in one JIRA issue to avoid the rule above. ** Do not bundle up several bugs/features in one JIRA issue to avoid the rule above.

Current revision

Contents

[edit] Code policy

  • Every public function/method must be documented using XML Comments. The documentation should contain:
    • Input parameters, including acceptable value ranges if non-obvious
    • Output values, if any
    • Exceptions thrown, if any
    • Description of what the function does, including side effects ("also increments current frame number by one")
    • Name of original author (jira username and/or email address)
  • Please also read the MSDN guidelines

[edit] SVN policy

[edit] Applying for SVN commit access

  • If you only intend to make a few commits you should post your code on the forums and ask for someone to commit it for you.
  • If you intend to be an active contributor contact baker99@gmail.com with reasons why you need access, your coding experience, and preferably the first piece of code you want to commit.

[edit] Notes on committing to SVN

  • Every commit must have one corresponding JIRA issue. This issue code must be the first item in your commit message, followed by a colon. For example, a typical commit message looks like this: WW-778: Improved rendering performance with hardware vertex buffers. See also: New checkins policy: Creating JIRA issues for checkins from [Worldwind-dev] mailing list.
    • Do not bundle up several issue codes in one commit; make a separate commit for each issue. This allows better tracking of what actually changed in response to each issue.
    • Do not bundle up several bugs/features in one JIRA issue to avoid the rule above.
  • Check that your commit does not break SVN, i.e. World Wind still builds. This is especially important if you also have other, uncommitted changes. If you repeatedly break SVN your commit privileges will be revoked.
    • If you add a new file, be sure to also commit the updated .csproj file for the particular sub-project, and any necessary .resx files.

[edit] Jira policy

  • If you see an unassigned issue you wish to take on you can freely assign it to yourself.
  • If you see an assigned issue you wish to take on or help with contact the current assignee or email baker99@gmail.com. Never assume an issue has been abandoned.
  • Issues with more votes should be prioritised. If you have several issues assigned to you fix the ones with most votes first, or unassign those issues and let someone else fix them.
  • If you believe you have fixed an issue, mark it as resolved, and ask for someone else to verify your fix, they should then select fixed or comment on your issue if there are still problems.
Personal tools