|
|
# ENOSAR development guidelines
|
|
|
|
|
|
## Coding
|
|
|
### IDE
|
|
|
We are using Spring Tool Suite as an IDE for Java development: https://spring.io/tools
|
|
|
|
|
|
### Project naming
|
|
|
The project name should be a complete identifier for the project. For example, the EnOcean Sample Client is developed in the workspace project `at.entrust.enosar.showcase.io.enocean.sample.client`. For more details see: [Eclipse Workspace Naming Convetions](https://wiki.eclipse.org/Naming_Conventions#Eclipse_Workspace_Projects)
|
|
|
|
|
|
### Namespace
|
|
|
The default namespace for projects within the core is located under ```at.entrust.enosar```. If you create a new project, just use the namespace within core. For example the project is called *communication* then the code will be located within the namespace ```at.entrust.enosar.communication```
|
|
|
|
|
|
### Coding conventions - style guide
|
|
|
Every major project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style.
|
|
|
|
|
|
“Style” covers a lot of ground, from “use camelCase for variable names” to “never use global variables” to “never use exceptions.” Our project will lean on the style guidelines which are used at Google code.
|
|
|
|
|
|
Here you find the [Java Style Guide](https://google.github.io/styleguide/javaguide.html)
|
|
|
|
|
|
#### Eclipse Code Formatter profile
|
|
|
Download the [Eclipse XML Configuration](https://raw.githubusercontent.com/google/styleguide/gh-pages/eclipse-java-google-style.xml) and
|
|
|
import the configuration in Eclipse. Go to ```Window -> Preferences -> Java -> Code Style -> Formatter``` and click on ```Import...``` (Hint: accept warnings if there are any)
|
|
|
#### Add default file header
|
|
|
Goto ```Window -> Preferences -> Java -> Code Style -> Code Templates -> Comments -> Files -> Edit``` and paste this snippet [New Java file code template v1.0.0](http://ressel.fh-salzburg.ac.at/snippets/1). Check ```Automatically add comments for new methods ant types``` click ```Apply``` and you are done.
|
|
|
|
|
|
## Releasing
|
|
|
Releases have to be tagged with a version number tag ```v0.1.0``` within the master branch. Those release tags are created within the gitlab webinterface, because there also release informations can be added. Versioning will follow the semantic schema, as described here: http://semver.org/ . For example ```2.0.0 2.0.0-rc.2 2.0.0-rc.1 1.0.0 1.0.0-beta```
|
|
|
|
|
|
# Documentation
|
|
|
To document your work is a very important thing. Try to think about, what is important for a newbee to get started with your code. Always document which functionality is working, which bugs are known and what is not working. Also explain the main ideas behind your code to get started easier.
|
|
|
|
|
|
For documentation use the `README.md` within your project. If you have a more complex documentation work, use the Wiki of the Project. |