diff options
author | Jack Lloyd <[email protected]> | 2015-10-05 16:45:18 -0400 |
---|---|---|
committer | Jack Lloyd <[email protected]> | 2015-10-05 16:45:18 -0400 |
commit | 92816309828aece4e23a97bac00bccbd8c5a03ee (patch) | |
tree | 2ceabf71dd73dfaba6541b16ab9419a70265ea59 /doc/hacking.rst | |
parent | d96833adc142c647aca4949f6f897b99480a2d79 (diff) |
Doc updates
[ci skip]
Diffstat (limited to 'doc/hacking.rst')
-rw-r--r-- | doc/hacking.rst | 23 |
1 files changed, 19 insertions, 4 deletions
diff --git a/doc/hacking.rst b/doc/hacking.rst index d9481a4c0..3196faa0a 100644 --- a/doc/hacking.rst +++ b/doc/hacking.rst @@ -19,7 +19,7 @@ Library Layout ======================================== * `base` defines some high level types -* `utils` contains various utility functions +* `utils` contains various utility functions and types * `codec` has hex, base64 * `block` contains the block cipher implementations * `modes` contains block cipher modes @@ -52,6 +52,13 @@ Library Layout Style Conventions ======================================== +When writing your code remember the need for it to be easily +understood by reviewers/auditors, both at the time of the patch +submission and in the future. + +Avoid complicated template metaprogramming where possible. It has its +places but should be used judiciously. + A formatting setup for emacs is included in `scripts/indent.el` but the basic formatting style should be obvious. No tabs, and remove trailing whitespace. @@ -66,6 +73,14 @@ this. Sending patches ======================================== -All contributions should be submitted as pull requests via the github -page. If you are planning a large change email the mailing list or open -a discussion ticket on github before starting out. +All contributions should be submitted as pull requests via the github page. +If you are planning a large change email the mailing list or open a +discussion ticket on github before starting out. + +If you are interested in contributing but don't know where to start +check out todo.rst for some ideas - these are projects we would almost +certainly accept if the code quality was high. + +Also, try building and testing it on whatever hardware you have handy, +especially non-x86 platforms, or especially C++11 compilers other +than the regularly tested GCC, Clang, and Visual Studio compilers. |