Skip to main content.

About the Guidelines

Although most open source projects do not enforce a coding style on its developers, the TinyKRNL project recognizes the importance of a rigid and commercial-like organization and structure which sets the project apart from most other typical FOSS environments. The project believes that by enforcing a limited amount of rules to aspects such as code style and quality, this will increase code readability, aid in bug hunting and documentation, as well as resolve many issues which other projects face.

The guidelines used by the project are standard C coding styles and should be familiar to most Windows developers. However, they may be surprising to UNIX-style developers, which use an entirely different set of rules. In any case, we have found these rules to be generally well liked by most people, and extremely readable for all involved.

^ TOP

Function Style

Function style is defined by two things: the actual function declaration, and, for TinyKRNL, the obligatory comment header describing the function.

  1. Function declaration: The generic template for any function is as follows:

    RETURN_TYPE
    FunctionName(PARAMETER_ANNOTATIONS PARAMETER_TYPE ParameterName1,
                 PARAMETER_ANNOTATIONS PARAMETER_TYPE ParameterName2)
    {
        <function starts here>;
    }

    In Windows style coding, almost all types are in CAPS. Therefore, void is VOID and int is INT. TinyKRNL also enforces the use of CamelCase (sometimes called PascalCase) for function names, parameter names and local variable names. Parameter annotations refer to another Windows-centric style in which parameters are marked as IN and/or OUT and OPTIONAL, if necessary. These annotations are readable cues on wether this function uses the parameters for input or output, and wether or not they are optional. Here is a complete example for a function which returns the number of apples in a tree, and can optionally also return the number of branches in the tree.

    ULONG
    CountApples(IN PTREE_OBJECT TreeWithApples,
                OUT PULONG NumberOfBranches OPTIONAL)
    {
        <function starts here>;
    }
  2. Comment header: The comment header for the CountApples function would be as follows:

    /*++
    * @name CountApples
    *
    * The CountApples routine counts the number of apples in a tree and, optionally,
    * returns the number of branches.
    *
    * @param TreeWithApples
    * Pointer to a tree object containing the apples.
    *
    * @param NumberOfBranches
    * Optional pointer to the value where to return the number of branches.
    *
    * @return The number of apples in this tree.
    *
    * @remarks To count the apples in an entire forest, use the CountApplesInForest
    * routine instead.
    *
    *--*/

    If there are no parameters and/or return value and/or remarks, simply write "None."
^ TOP

Code Style

Code style refers to the ensemble of rules that must be respected when writing code inside TinyKRNL. Here is a generic overview:

^ TOP

Header Style

Header style refers to how function prototypes, type definitions and other information present in headers should be organized.

For prototypes or function types, the CountApples function would be defined as follows:

ULONG
CountApples(
    IN PTREE_OBJECT TreeWithApples,
    OUT PULONG NumberOfBranches OPTIONAL
);

The TREE_OBJECT type would be defined like this:

typedef struct _TREE_OBJECT
{
    ULONG Branches;
    ULONG Apples;
} TREE_OBJECT, *PTREE_OBJECT;

Additionally, the following rules apply:

^ TOP

Generic Rules

Finally, the following rules apply to TinyKRNL components in general: