Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "E4/Search Console/Coding Guidelines"
< E4 | Search Console
| Line 1: | Line 1: | ||
=== Productive code === | === Productive code === | ||
| − | *There must be clear separation between business and user interface logic. The search console makes use of the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter Model-view-presenter pattern] where the user interface is a passive component managed by a controller. | + | *There must be clear separation between business and user interface logic. The search console makes use of the [http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter Model-view-presenter pattern] where the user interface is a passive component managed by a controller.The following sequence diagram demonstrates an example interaction |
| + | |||
| + | [[Image:SearchConsoleMVP.png]] | ||
| + | |||
*Good coding practices must be followed: | *Good coding practices must be followed: | ||
| − | *[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID ]principles | + | :*[http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29 SOLID] principles |
:*Code duplication is avoided ([http://en.wikipedia.org/wiki/Don%27t_repeat_yourself DRY principle]) | :*Code duplication is avoided ([http://en.wikipedia.org/wiki/Don%27t_repeat_yourself DRY principle]) | ||
Revision as of 08:43, 26 January 2012
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.The following sequence diagram demonstrates an example interaction
- 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