Developer: Style Guide

Formatting

HPN-SSH follows the style guide used by OpenSSH which is based on the BSD Kernel Normal Form (KNF) implementation. See style for more information. Submissions to the HPN-SSH project should, whenever feasible, follow this style.

Development Principles

HPN-SSH is as portable as possible in as much as it meets stated development goals. For example, the inband metrics functionality provides support for Linux and BSD derived kernels but does not support Windows or OS X at this time. While this does lock some users out from this specific functionality it does not prevent users of these systems from using HPN-SSH as a whole. Any code that is platform specific must not break or reduce functionality for other platforms. Platform specific code should address a real and documented of the users of that platform and provide significant benefits to those users. Importantly, any platform specific code must not negatively impact performance on other platforms. In principle, platform specific code should be of benefit to the majority of users of HPN-SSH.

HPN-SSH developers should focus on produce clear, concise, and readable code. When conciseness and readability are at odds developers should weight readability more heavily than conciseness as long there is no performance penalty associated with it. All code should be well documented through the use of inline comments. There is no guarantee that any one developer will be able to support their code indefinitely so developers must write comments with an eye towards maintainability. Developers can contribute to HPN-SSH by providing inline comments for code they have not themselves written. For example, useful contributions can include header comments for functions, descriptions of workflow within a function, and so forth. Header comments for functions should include a synopsis of the function, arguments, and returns.

Variable nomenclature: (how to name variables)

Function nomenclature: (how to name your functions)

File structure: (pertaining to what is included within a code unit and when it should be split off into multiple files)

Scoping: (use of globals and the like)