angrygoats
/
binancej
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
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.
15 Commits
1 Branch
0 Tags
80 KiB
 
Branch: master
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'master'
${ noResults }
binancej/CONTRIBUTING.md

3.4 KiB
Raw Permalink Blame History

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

Overall Requirements

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:

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:

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. 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.