A java implementation of the Binance API Specification
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

94 lines
3.4 KiB

# Contributing to the BinanceJ Project
### Welcome to BinanceJ!
The goal of this project is to provide the de-facto standard Binance API in Java.
---
#### Sections
> * [Getting Started](#getting-started)
> * [Branch Naming](#branch-naming)
> * [Testing](#testing)
> * [Code Standards](#code-standards)
> * [Versioning](#versioning)
> * [Submitting Pull Requests](#submitting-pull-requests)
> * [Submitting Issues](#submitting-issues)
---
## Getting Started
### Overall Requirements
* Java 8
* Gradle
* [Sonarlint](https://www.sonarlint.org/)
It is highly suggested you use something like Intellij IDEA when developing this project though
there is no strict enforcement on that.
To get started with the project, do as follows:
```sh
git clone git@github.com:angrygoats/binancej.git
cd binancej
gradle clean && gradle build
```
## Branch Naming
An often overlooked aspect of repository management is naming of branches. In order to make branches easier to prune,
maintain, and track please use the format `<name-id>-<ticket-or-feature-name>`.
* `<name-id>`: I could use either `ag` (for "angrygoats") or `tb` (for "Taylor Bockman"). Both allow someone to quickly know who owns the branch.
* `<ticket-or-feature-name>`: If the ticket/feature has an associated issue/ticket number please include it in the branch name. Otherwise an accurate description of the feature is sufficient.
## Testing
We operate a strict TDD shop here. As a result, any PR submitted without tests for anything but _the most trivial_ of
features will be rejected immediately. 100% code coverage is not necessary (but desirable where possible). You should
aim to cover all major conditions your code can go through thoroughly.
The tools we primarily use are Junit4 and Mockito. Since the API is so simple this all we really need.
To run the tests, simple run:
```sh
gradle test
```
from the root of the project.
## Code Standards
Clean Java is good Java. As all of us know Java can get unnecessarily verbose at times, and in order to keep readability
in view at all times good code standards should be followed:
1. Run Sonarlint and follow it's suggestions
2. 4 spaces (not tabs)
3. Keep a space between each member of a class for readability
4. Javadoc every function you write with the exception of already documented functions you are `@Override`'ing
5. Javadoc classes that are not obvious from their name
6. __Absolutely no wild card importing__
7. Clean up your imports - do not leave unused imports in any code you write
8. You should make an effort to clean up all code you touch if the clean up will not take too long
* Any thing that will take long should be made into an issue
9. Make use of Lombok wherever you can to reduce boilerplate as much as possible
10. Take advantage of Java 8 features such as streams to simplify your code where possible
11. If you are using IntelliJ, take advantage of code formatting under `Code -> Reformat Code`
## Versioning
The BinanceJ project uses [Semantic Versioning](https://semver.org/). In the `build.gradle` you will find a line
to adjust the semantic versioning of the library.
## Submitting Pull Requests
Please be sure to follow the supplied pull request template. PRs will be rejected if they lack tests or the test
coverage isn't sufficient.
## Submitting Issues
Please be sure to follow the supplied issue template. If the template does not contain fields you need, feel free
to add them if they provide more context to the issue you are experiencing.