Code Style

Since the kernel has switched to C++, coding style has changed and has been updated here also.

Naming Types

Transparent types must be named in the following fashion -

struct KernelThread;
struct Runnable;
class RBTree;
class BuddyAllocator;

But opaque types should be aliased like this -

struct ObjectHandle;
typedef ObjectHandle HANDLE;

C & C++ Integration

Although the kernel is built using C++, the C coding style is allowed (for non-core code) and is supported using function-attribute macros -

decl_c void Main(args);// C-style function
import_asm unsigned long ReadMSR(args);// Function implemented in assembly
export_asm unsigned long DbgInt(args);// Function exported to another .asm file

Here,

• decl_c means the function is to declared in "C" style and to be used in *.c files.
• import_asm means the function is implemented in assembly files.
• export_asm means the function will be used by assembly files.

Structures

A structure is always typedef-ed, if it is abstract, and is declared as -

/**
 * Given a brief description about this data structure. Use structs
 * whenever you are talking about PODs (public ctors & static functions
 * allowed in "structs").
 *
 * @version 1.0
 * @since Silcos 3.02
 * @author <Author Ka Naam>
 *
typedef// (optional)
struct DataTypeName
{
     TYPE var0;//! what is this
     ChildStruct var1;//! wow, what is it
} ABSTRACT_TYPE;/* Used only if the type is opaque! */

Structures are a fundamental part of the coding style, as only they are supported in data structures. The kernel does not (like) use of templates for widely-used classes, thus, the Void *pointer (instead of template-types). All stuff that needs to be stored in a data structure should be organized into a struct declaration.

Global Functions

A global function is defined as

 function_attribute retType PlainCFunctionName(args);

All function names are written in PascalCase for differentiating with C++ class functions which are in camelCase.

Class Definition

A class is defined as (source or header) -

   /**
    * Give a brief description about what your class abstracts all
    * about. Is it a device/software-component/connector/etc.? Tell
    * how other code should use it.
    *
    * @version 1.0
    * @since Silcos 3.02
    * @author Shukant Pal
    */
   class ClassName
   {
   public:
       varType variable;
       retType functionName(args);

       inline ReturnType InlineMethod(Args...) {
           // You should notice the braces of this inline method
       }
   protected:
       ClassName(args);
   private:
       void someMethodMan();
   };

Method Declaration

Above each method implementation, the programmer should document what and how the method does what it does. It should be concise and summarize the function. Care should be taken to reduce the number of characters per line to be less than 80 in the documentation and the body. Doxygen syntax is used for documenting now.

 /**
  * What does your method do? Any errors/exceptions. How do users use
  * it and when should they?
  *
  * @param argName - what is this arg?
  * @return - what does this function return?
  * @version 1.0
  * @since Silcos 3.02
  * @author Shukant Pal
  */
 retType Class::method(argType argName)
 {

 }