This article will repost these principles in detail in the classic book contributing to eclipse. The version is very old and almost out of print in China. In plug-in development, I personally use the most common contribution rules,Sample rules, Adaptation rules.
Extended
Contribution rule: Everything is contribution.
Conformance rule: the plug-in must follow the expected interface.
Sharing rule: add, do not replace.
Sample rules (monkey see/monkey do rule): in case of a problem, first copy a structure similar to the plug-in.
Relevance rule: displays your contribution only when the operation is successful.
Intergration rule: to integrate and not split.
Responsibility rule: clearly states that your plug-in is the source of the problem.
For API contract programming rules (program to API contract rule): first check the eclipse API contract, and then
For contract programming.
Other rule: allows users to select everything, but puts options that are usually not used in the current world
Other dialog box.
Iresource adaptation rules (adapt to iresource rule): define the iresource suitability for domain objects as much as possible.
.
Layered rule (strata rule): separates language-independent functions from functions specific to specific languages, and separates core functions from the UI
Functions are separated.
Use user continuity rule: the user interface status should be consistent between multiple sessions.
Promoter
Invitation rule: invites others to contribute to your work as much as possible.
Lazy loading rule: the plug-in is loaded only when it is actually needed.
Safe platform rule: As the extension point provider, you must protect yourself and do not allow extension
Your misoperation may cause losses to you.
Fair play rule: All Users follow the same game rules, including myself.
Explicit Extension Rule: specifies where the bottle cap can be expanded.
Diversity rule: an extension accepts multiple extensions.
Good fences rule: if you want to surrenderProgramFirst, protect yourself.
User arbitration rule: if there are multiple options, the user determines which one to use.
Explicit rule: separates APIs from classes used in the plug-in.
Stability rule: if you have already begun inviting others to contribute, do not change the rules of the game.
Defensive API rule: Only APIs with confidence are exposed, but you should also be prepared to expose them.
More APIs, because the user will ask you to do so
Publisher
License rule: a license is required for each contribution.