aboutsummaryrefslogtreecommitdiff
path: root/doc/coding.txt
blob: cc41850a5c7ead6359fa2a16d222bead194c0e96 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
Please be consistent with the existing coding style.

Block style:

bool Function(char* psz, int n)
{
    // Comment summarising what this section of code does
    for (int i = 0; i < n; i++)
    {
        // When something fails, return early
        if (!Something())
            return false;
        ...
    }

    // Success return is usually at the end
    return true;
}

- ANSI/Allman block style
- 4 space indenting, no tabs
- No extra spaces inside parenthesis; please don't do ( this )
- No space after function names, one space after if, for and while

Variable names begin with the type in lower-case, like nSomeVariable.
Please don't put the first word of the variable name in lower-case like
someVariable.

Common types:
n       integer number: short, unsigned short, int, unsigned int,
            int64, uint64, sometimes char if used as a number
d       double, float
f       flag
hash    uint256
p       pointer or array, one p for each level of indirection
psz     pointer to null terminated string
str     string object
v       vector or similar list objects
map     map or multimap
set     set or multiset
bn      CBigNum

-------------------------
Locking/mutex usage notes

The code is multi-threaded, and uses mutexes and the
CRITICAL_BLOCK/TRY_CRITICAL_BLOCK macros to protect data structures.

Deadlocks due to inconsistent lock ordering (thread 1 locks cs_main
and then cs_wallet, while thread 2 locks them in the opposite order:
result, deadlock as each waits for the other to release its lock) are
a problem. Compile with -DDEBUG_LOCKORDER to get lock order
inconsistencies reported in the debug.log file.

Re-architecting the core code so there are better-defined interfaces
between the various components is a goal, with any necessary locking
done by the components (e.g. see the self-contained CKeyStore class
and its cs_KeyStore lock for example).

-------
Threads

StartNode : Starts other threads.

ThreadGetMyExternalIP : Determines outside-the-firewall IP address,
sends addr message to connected peers when it determines it. 

ThreadIRCSeed : Joins IRC bootstrapping channel, watching for new
peers and advertising this node's IP address. 

ThreadSocketHandler : Sends/Receives data from peers on port 8333.

ThreadMessageHandler : Higher-level message handling (sending and
receiving).

ThreadOpenConnections : Initiates new connections to peers.

ThreadTopUpKeyPool : replenishes the keystore's keypool.

ThreadCleanWalletPassphrase : re-locks an encrypted wallet after user
has unlocked it for a period of time. 

SendingDialogStartTransfer : used by pay-via-ip-address code (obsolete)

ThreadDelayedRepaint : repaint the gui 

ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been used
in 500ms.

ThreadRPCServer : Remote procedure call handler, listens on port 8332
for connections and services them.

ThreadBitcoinMiner : Generates bitcoins

ThreadMapPort : Universal plug-and-play startup/shutdown

Shutdown : Does an orderly shutdown of everything

ExitTimeout : Windows-only, sleeps 5 seconds then exits application