OpenFHE Style Guide
General Style Guidelines
Try to follow the style of surrounding code, and use variable names that follow existing patterns. Pay attention to indentation and spacing.
Configure your editor to use 4 spaces per indentation level, and never to use tabs.
Avoid introducing trailing whitespace
Limit line lengths to 80 characters when possible
Give meaningful variable names to all variables.
Every reused discrete block of code has its own method
Every discrete line of code, or discrete group of code lines for each task has its own comment.
OpenFHE coding style is based on the official Google C++ Coding Style Guide.
We explicitly note:
Write comments to explain non-obvious operations within the code, both in header or source files.
All classes, member variables, methods, and constants should have Doxygen-style comments
Please document all input and output data characteristics (required lengths of vectors,
restrictions on combinations of variables) as well as any conditions that generate exceptions.
e.g comment lines starting with
//!or comment blocks
Avoid defining non-trivial functions in header files
Header files should include an ‘include guard’
Operator overloading is allowed, especially for binary operations
coutshould never be used for exception handling and should never be used in committed code in the core OpenFHE library.
std::logic_erroris the standard exception for all exceptions not caught by the OpenFHE exception handling subsystem (which has not yet been universally implemented in the library at this time).
Code may make use of most C++11 features. The minimum required compiler versions are listed in the main README.md file.
Avoid manual memory management (i.e.
delete), preferring to use standard library containers, as well as
std::shared_ptrwhen dynamic allocation is required.
Portions of Boost which are “header only” may be used. If possible, include Boost header files only within
.cppfiles rather than other header files to avoid unnecessary increases in compilation time. Boost should not be added to the public interface unless its existence and use is optional. This keeps the number of dependencies low for users of OpenFHE. In these cases,
OpenFHE_API_NO_BOOSTshould be used to conditionally remove Boost dependencies
Protected and private member variable names are generally prefixed with
m_. For most classes, member variables should not be public. Data member should generally use
Variable names use
Class, struct, typedef, and enum names use
Class Methods use
Global variable names:
Class accessor names:
Constant names and macros use
Do not indent the contents of namespaces
While OpenFHE does not specifically follow these rules, the following style guides are useful references for possible style choices and the rationales behind them.
We have automated syntax checking on commit using
so many of the above formatting rules will be automatically made.
Style generally follows PEP8
.pyxfiles needs to be written to work with Python 3
The minimum Python version that OpenFHE supports is Python 3.4, so code should only use features added in Python 3.4 or earlier
Code in the Python examples should be written for Python 3