Coding Conventions

Views 2493 Votes 0 2010.04.14 21:25:10
Stephanos *.26.166.80

Operating System IX, Coding Conventions

#000004, Stephanos S. Io, 14/04/2010, Rev 1.

 

1. Summary

This document defines all the standard coding conventions for the OSIX and third-party software developers. These coding conventions are used in the OSIX kernel and the system applications. All third-party software are recommended to follow this standard for the code-level compatibility.

The following coding conventions are defined in this document:

  General Object Naming : defines how definitions, constants and variables are named and consistently classified.

  General Procedure Naming : defines how procedures (aka. functions) are named.

  C++ Coding : defines C++ language-specific conventions.

  NASM Assembly Coding : defines Netwide Assembler Assembly language-specific conventions.

2. General Object Naming

1. Structure

PrefixName

Prefix – specifies the variable type and range.

Name – describes the variable.

 

Exceptions: Object Types do not have prefixes.

2. Prefixes

Prefix

Description

g

Global variable

l

Private/Protected (class) variable

p

Parameter variable

(no)

No prefix Local (procedure) variable

_

Constant/Definition

3. Name

All object names are written in the CamelCase without any underscores (_). If there is a word that is specified in the 'Standard Abbreviations' document in a variable name, the word should be abbreviated as specified in the document (depending on situations, some words may be kept  unabbreviated.).

Object names are usually in one of the following forms:

1.    simply consists of a description (ex: Password)

2.    consists of a general description and a specific description (ex: PasswordLength).

 

Exceptions: Definitions may include underscores in its name.

4. Exceptional Names

Name

Description

i/j/k/l

Iterator

 

3. General Procedure Naming

1. Structure

PrefixNameSuffix

Prefix – specifies the range of the procedure.

Name – describes the procedure.

Suffix – specifies the type of the procedure.

2. Prefixes

Prefix

Description

l

Private/Protected (class)

(no)

Public (class)

Note: In the non-object-oriented languages, use of the prefixes is not compulsory.

3. Name

Basically, the General Procedure Naming conventions are the same as the General Object Naming conventions.

Procedures are usually in one of the following forms:

1.    simply consists of a verb (ex: Add).

2.    consists of a verb and an object (ex: AddItem).

3.    SIMD forms (ex: AddSubPackedDouble).

4. Suffix

The following are the list of the most occasionally used suffixes. Suffixes that are not listed on this table may also be used. However, the developers are highly recommended to use one of the listed suffixes unless there is absolute no adequate suffixes.

Suffix

Description

Callback

Callback procedure

Handler

Handler procedure

Dispatcher

Dispatcher procedure

4. C++ Coding

This part defines the C++ Coding conventions. Since C++ is an object-oriented programming language, it is very important to keep the source code structure consistent and comprehensive.

1. Basic Rules

I.    All C++ default types are replaced with the following type system.

C++ Default Type

Standard Type

char (8-bit integer)

Int8

short (16-bit integer)

Int16

int (32-bit integer)

Int32

long (64-bit integer)

Int64

unsigned char (8-bit unsigned integer)

UInt8

unsigned short (16-bit unsigned integer)

UInt16

unsigned int (32-bit unsigned integer)

UInt32

unsigned long (64-bit unsigned integer)

UInt64

char (1-byte character/ASCII)

SChar

wchar_t (2- or 4-byte character/Unicode)

Char

bool

Boolean

void

Void

II.  When declaring pointers, * is always spaced from the type name (ex: Address *Pointer1, *Pointer2;).

2. Case Study

#include <Common.h>

 

Void Main(UInt32 pArgumentsCount, SChar **pArguments)

{

    SChar WelcomeMessage[] = { 'W', 'e', 'l', 'c', 'o', 'm', 'e', 0 };

    Console::WriteLine(“{0:S}! {0:D} arguments are passed.”, WelcomeMessage, pArgumentsCount);

    SChar **Arguments = new SChar *pArgumentsCount;

    for (UInt32 i = 0; i < pArgumentsCount; i++)

    {

        Console::Write(“Argument{0:D} \”{0:S}\” ”, i, pArgumentsi);

        Argumentsi = new SCharString::Length(pArguments[i)];

        String::Copy(pArgumentsi, Argumentsi);

        Console::WriteLine(“has successfully been copied to the local storage.”);

    }

}

Case 1. General Programming

 

#include <Common.h>

 

// Definition

class TestClass

{

private:

    UInt32 lTestValue;

 

public:

    Void SetTestValue(UInt32 pTestValue);

    UInt32 GetTestValue();
}

 

// Implementation

Void TestClass::SetTestValue(UInt32 pTestValue) : lTestValue(pTestValue)

{ }

 

UInt32 GetTestValue()

{

    return lTestValue;
}

 

// General Procedures

Void Main()

{

    TestClass *Class1 = new TestClass();

    TestClass *Class2 = new TestClass();

 

    Class1->SetTestValue(0x12345678);

    Class2->SetTestValue(0x9ABCDEF0);

 

    Console::WriteLine(“0x{0:X} + 0x{1:X} = 0d{2:U}”, Class1->GetTestValue(), Class2->GetTestValue(), Class1->GetTestValue() + Class2->GetTestValue());

 

    delete Class1;

    delete Class2;

 

    Main();

}

Case 2. Class Programming

5. NASM Assembly Coding

global Entry

extern Main

 

StackSize                equ 0x2000

 

section .text

align 4

Entry:

    ; Initialise the segment registers

    mov ax, (1 << 3)

    mov ds, ax

    mov ss, ax

    ; Initialise the stack

    mov esp, Stack + StackSize

    ; Jump to the C routine

    jmp Main

 

section .bss

align 32

Stack:

    resb StackSize

Case 1. General Programming


profile

Stephanos

2010.04.06 22:53:15
*.26.166.80

Operating System IX, Coding Conventions

#000004, Stephanos S. Io, 05/04/2010, Rev 0.

Attachment
profile

Stephanos

2010.04.14 21:25:10
*.26.166.80

Operating System IX, Coding Conventions

#000004, Stephanos S. Io, 14/04/2010, Rev 1.

 

Use of the type 'Address' is now deprecated. First, we are not willing to port this kernel into other processor architectures. Second, it is meaningless to specify 'Address' since we will not see the 128-bit processor in about 20 years from now (even if it comes out, we will have to write the whole kernel again then.) and we have absolutely no intentions of supporting the 32-bit or 16-bit architectures.

Attachment