Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Bugzilla 165578

Revision as of 06:49, 12 December 2006 by Bsubram.us.ibm.com (Talk | contribs)

Discuss this feature

Link to bug on TPTP (this is not part of the template): [1]

TPTP feature: 165578

Author: Arun Shivaswamy
email: ashivasw@in.ibm.com
Committer email: bsubram@us.ibm.com(Balan Subramanian)
Last updated:


Rough workload estimate for design/code/test in person weeks:

ProcessSizing
Design0.5
Code2.5
Test1
Documentation0
Total 4

Rough workload estimate for build and infrastructure in person days: 0.0


Requirement summary

  • 1. Internal/Provisional packages
  • Today we have a lot of violations in our code where we use eclipse internal apis when we are not supposed to. Either we need to rewrite the code or get rid of these violations in some other way. Also, we need to clearly come out with a list of provisional packages.

  • 2. Junits
  • There needs to be Junits for every provisional class and also sufficient Junits for every possible testcase the developer or the tester can think of. Need to focus on code coverage while writing Junits and also test all the functional apis in the code. Also, we need to write Junits to take care of the boundary conditions if not already done.

  • 3. Testing
  • - Make sure that the testcases already written against each component work fine before adding any new ones and testing them. - Make sure the Junits execute 100% successfully. - Test plan(s) need to be aligned on the lines of Use cases.

  • 4. Copyrights
  • All source code files must have copyrights in it. Balan to guide us on the correct copyright statement. You can use the following tool to add correct TPTP copyrights - its an Eclipse plugin: http://fullmoon.torolab.ibm.com/downloads/drops/R-3.2-200606291905/index.php Scroll down to the bottom and you will see the download for the org.eclipse.releng.tools plug-in.

  • 5. Javadoc
  • Make sure all the public methods in your code are documented. Also please add doc at the top which explains fully what the class does. Leave the author specification empty.

  • 6. Error handling
  • Please handle all exceptions you can think of, as individually as possible. All exceptions must be logged to the error log and either thrown or handled appropriately. Also please use discretion on what you mark errors and what you mark warnings or information. We should aim to not put anything out on the console. Make sure exceptions are handled at the proper layer of code.

  • 7. Internationalization
  • - Verify that all possible translatable strings have been recorded under the NLS plugin component-wise. - If the strings happens to be an error message, then it needs have a error ID prefixed to it. The ID can be generated using: http://cvs.opensource.ibm.com/viewcvs/*checkout*/deptrnd/home/messageIDGenerator.html - Also see TPTP requirements @ http://www.eclipse.org/tptp/home/documents/process/development/translation_rules_of_thumb.html

  • 8. Coding conventions
  • We need to Check for the following in the code: - Class and method names should be clear and unabbreviated, unless the name contains an acronym. - Acronyms should have the first letter capitalized (XmlUtils) unless the acronym is the end of the identifier (convertToXML). - Private fields should have a leading underscore (_). Static fields should be all capitals. - Getter/setter methods should not be created unless they are really needed, and class design should consider whether direct access is needed or if indirect get/set methods may be more appropriate. Curly brackets go on a separate line. Don't leave a history of previous code in comments - use CVS commit comments to explain what was removed and why. Create interfaces and factories judiciously - if something cannot reasonably be expected to have more than one implementation, make it a class. If you make an interface/factory, make sure there is a clear description of how a user could easily add a replacement for your implementation class(es).

  • 9. Legal issues need to be resolved.

User interactions

User interface

TBD

Extension points

Code interfaces

Design summary

Back to the top