The Last Bikeshed #11
Description
| Name | Type | Property | Function | Argument / Variable |
|---|---|---|---|---|
| Buffer | Uint8Array | - | toBytes() | bytes |
| Address | Address | address | toAddr() | addr / payAddr / changeAddr |
| - | AddressToPubKeyHash | - | addrToPkh() | - |
| Public Key | PublicKey | publicKey | toPublicKey() | pubBytes / pubHex |
| - | PublicKeyToPubKeyHash | - | pubkeyToPkh() | - |
| PubKey Hash | PubKeyHash | pubKeyHash | toPkh() | pkh |
| Private Key | PrivateKey | privateKey | toPrivKey() | privBytes / privHex |
| Sighash Type | SighashType | sighashType | - | sighashByte |
1. Descriptive Type and Property Names
public_key and publicKey are fantastic property names. Descriptive. Easy-to-read. Wonderful.
And PublicKeyToPubKeyHash is a fine Type name. It's very descriptive. When it pops up with Tooling, it makes sense.
2. Functions, however, need shorter names
DashKeys.publicKeytoPublicKeyHash(pubBytes) is not only long, it's actually hard to read.
DashKeys.pubKeyToPkh(pubBytes) is actually easier to see at-a-glance.
3. Is it pubKey or pubkey?
It's definitely either public_key (JSON, DB) or publicKey (code).
I'm not so sure when it comes to functions though...
It's actually easier to distinguish between pubkeyToPkh than pubKeytoPkh - too many humps vying for attention isn't as easy to read as fewer humps.
4. This is an ecosystem concern
- Dash Keys
- Dash HD
- Dash Tx
- Dash Wallet
I want the exact same styles across the entire ecosystem.
- All functions are stylized like X
- All function arguments are stylized like X'(?)
- All properties are stylized like Y
- All types are stylized like Z