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.
Difference between revisions of "E4/Search Console/Coding Guidelines"
< E4 | Search Console
(New page: = General coding guidelines in Search Console<br> = === Productive code === *There must be clear separation between business and user interface logic. The search console makes use of t...) |
|||
| Line 1: | Line 1: | ||
| − | = General coding guidelines in Search Console<br> = | + | === General coding guidelines in Search Console<br> === |
| − | === 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. | ||
| Line 20: | Line 20: | ||
*Test driven development is the preferred implementation style | *Test driven development is the preferred implementation style | ||
| − | === Test code<br> === | + | ==== Test code<br> ==== |
*All tests must be automated | *All tests must be automated | ||
Revision as of 08:29, 26 January 2012
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