Operating System IX

I worked on the Coding Conventions document today. It is really important to have a good coding style because it improves the code maintainability a lot.

Many programs, especially the open source code programs, have really inconsistent and messy structures and codes. Sometimes, it is just irritating to read those codes.

The coding style is all about consistency. Sometimes, developers who do not have a long experience in the development becomes very inconsistent about their code.

For example, in C++, they sometimes write int* Pointer; and also int *Pointer;. There is a reason that I chose this as the first example. As you can see, technically, both are correct and have no syntax problems.However, in the consistency problems, the former can be inconsistent if there are more than one pointer variables declared at once.

int* Pointer1, *Pointer2; Now you see that. Some developers may think that int* makes all the following symbols int pointers. However, if you write int* Pointer1, Pointer2;, Pointer1 becomes an int *, but Pointer2 becomes only an int. Somehow, this coding style (which is very common to many developers) is very inconsistent. Since the second one becomes *Pointer2, the first one should become *Pointer1, instead of * Pointer1;.

There is another example for you. Some people are not consistent about the { } blocks. They sometimes write

if (somethin) {
}

and sometimes also write

if (somethin)
{
}

They are mixing those two different bracing styles. Experienced developers love to see the consistent code, not that goin' somewhere else and comin' back and goin' again so on kinda code.

The OSIX coding conventions are inspired by the C#/.NET coding conventions (I love the Microsoft developers because they are very consistent about their code.).

The following is an example of the IX standard coding conventions:

-------------------------------------------------------------------------------------------------------------------------------------------------------

#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, pArguments[i]);

        Arguments[i] = new SChar[String::Length(pArguments[i])];

        String::Copy(pArguments[i], Arguments[i]);

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

    }

}

=-----------------------------------------------------------------------------------------------------=

From this, you can see those lovely CamelCase variable/function names, nice spacing between operators (this makes you read the code more easily and, believe it or not, prevents you from harming your eyes? Haha), and variable range differentiations.

This actually looks like C# code if you do not look at it carefully. However, it is written in C++.

Major improvements and differences from the Windows programs' coding conventions are:

1. We do not specify the variable type and size in the variable name anymore (ex: dwCallbackData). Mainly, the reason that we do not specify the variable type and size is that it is usually unnecessary and makes the code look dirty. Usually, people can guess the type from the variable's name and the nice IDEs tell them about it more specifically. Therefore, the variable type and size in the variable names are not necessary.

2. Instead, we specify the variable range in the name. For example, for the global variables, it starts with 'g'. Parameters start with 'p'. Local variables start with no prefixes. Where people usually get confused is the range of the variable, not the size or type of the variable. Especially, it is important when programming with an object-oriented language. Since there is no prefix for the local variables, it makes the code look less dirty.

3. .NET-like type system. Many C-derivated languages use char, short, int, long, etc. to specify the variable size. Sometimes, it can be useful (like porting the code into different system architectures). However, it rather usually creates several compatibility problems or confusions. I would say that this type system is very inconsistent and must not be used anymore. In the OSIX coding conventions, by specifying the exact size of the variable, we make the program more consistent and prevent any further confusions.

4. COMPLETE CamelCasing. The OSIX coding conventions apply the CamelCasing to all kinds of variables. Sometimes, developers make some exceptions to the CamelCasing rules in order to make the code consistent. Since we have our prefix system, we do not need to un-CamelCase some variable types. This makes the code look better. For example, somewhere I write localVariable and elsewhere I write LocalVariable. Doesn't it look somehow inconsistent? I would say 'Yes'.