zcash-hackworks
/
bitcore-lib-zcash
mirror of https://github.com/zcash-hackworks/bitcore-lib-zcash.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #858 from braydonf/docs/header-titles 

Fixed capitalization in headers
This commit is contained in:
Esteban Ordano 2014-12-25 16:03:23 -03:00
parent a1556c2cce 47cb6f377d
commit 6e88efbe51
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
CONTRIBUTING.md
View File

@ -51,19 +51,19 @@ Follow this Node.js Style Guide: https://github.com/felixge/node-style-guide#nod
Avoid constants in the code as much as possible. Magic strings are also magic numbers.
### G2 - General: Internal Objects should be Instances
### G2 - General: Internal Objects Should be Instances
If a class has a `publicKey` member, for instance, that should be a `PublicKey` instance.
### G3 - General: Internal amounts must be integers representing Satoshis
### G3 - General: Internal Amounts Must be Integers Representing Satoshis
Avoid representation errors by always dealing with satoshis. For conversion for frontends, use the `Unit` class.
### G4 - General: Internal network references must be Network instances
### G4 - General: Internal Network References Must be Network Instances
A special case for [G2](#g2---general-internal-objects-should-be-instances) all network references must be `Network` instances (see `lib/network.js`), but when returned to the user, its `.name` property should be used.
### G5 - General: Objects should display nicely in the console
### G5 - General: Objects Should Display Nicely in the Console
Write a `.inspect()` method so an instance can be easily debugged in the console.
@ -103,7 +103,7 @@ Usage:
* Whenever a new class is created, add a generic error for that class in `lib/errors/spec.js`.
* Specific errors for that class should subclass that error. Take a look at the structure in `lib/errors/spec.js`, it should be clear how subclasses are generated from that file.
### E2 - Errors: Provide a `getValidationError` static method for classes
### E2 - Errors: Provide a `getValidationError` Static Method for Classes
### I1 - Interface: Make Code that Fails Early
@ -156,7 +156,7 @@ function ImmutableClass(arg) {
}
```
### I5 - Interface: No new keyword for Constructors
### I5 - Interface: No New Keyword for Constructors
Constructors should not require to be called with `new`. This rule is not heavily enforced, but is a "nice to have".
@ -179,7 +179,7 @@ Don't write long tests, write helper functions to make them be as short and conc
Inputs for tests should not be generated randomly. Also, the type and structure of outputs should be checked.
### T3 - Testing: Require 'bitcore' and look up classes from there
### T3 - Testing: Require 'bitcore' and Look up Classes from There
This helps to make tests more useful as examples, and more independent of where they are placed. This also helps prevent forgetting to include all submodules in the bitcore object.
@ -193,9 +193,9 @@ DON'T:
var PublicKey = require('../lib/publickey');
```
### T4 - Testing: Data for tests included in a JSON file
### T4 - Testing: Data for Tests Included in a JSON File
If possible, data for tests should be included in a different JSON file from the test. This improves interoperability with other libraries and keeps tests cleaner.
If possible, data for tests should be included in a JSON file in the `test/data` directory. This improves interoperability with other libraries and keeps tests cleaner.
## Pull Request Workflow