Merge pull request #858 from braydonf/docs/header-titles
Fixed capitalization in headers
This commit is contained in:
commit
6e88efbe51
|
@ -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.
|
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.
|
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.
|
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.
|
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.
|
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`.
|
* 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.
|
* 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
|
### 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".
|
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.
|
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.
|
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');
|
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
|
## Pull Request Workflow
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue