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.
E4/Search Console/Coding Guidelines
< E4 | Search Console
Revision as of 08:29, 26 January 2012 by Danail.branekov.sap.com (Talk | contribs)
General coding guidelines in Search Console
Productive code
- There must be clear separation between business and user interface logic. The search console makes use of the Model-view-presenter pattern where the user interface is a passive component managed by a controller.
- Good coding practices must be followed:
- SOLID principles
- Code duplication is avoided (DRY principle)
- Methods and classes are short with cyclomatic complexity below 2
- Names of methods, classes and interfaces describe the intended behavior; code is self-documented and readable
- Classes are recommended to communicate with each other via interfaces. This results in loose coupling and makes testing easier
- Javadoc for public API is mandatory
- Each feature must be complemented by automated tests which provide code coverage of above 70% (the more, the better)
- Test driven development is the preferred implementation style
Test code
- All tests must be automated
- Tests are isolated (prefer unit tests over integration tests)
- Mocking frameworks are used when implementing tests. Existing tests use Jmock 1.2, EasyMock, Mockito (all available in Orbit). Having experience with all these three frameworks, we recommend Mockito
- User interface tests
- Use SwtBot to simulate user interaction
- Make use of the page object paradigm in order to isolate test implementation from the UI test framework (SwtBot). See package org.eclipse.platform.discovery.ui.test.comp.internal.pageobjects for examples of page objects
- Use a dedicated test shell to embed the user interface under test
- Productive code guidelines have to be kept for test code as well