My Coding Styles

Namings
Formatting Source Files
Definitions for compatibility

Namings

Redefined external primitive types

The first character is the under-score and the other characters are lower-case characters or underscores. For example,

typedef short _integer2; /* 2 bytes signed integer */

External structures

The first character is the underscore which means 'tag', and the other characters are camel-case chracters without underscore. For example,

struct _IOTextLocation {
	...;
};

And, I don't use typedef for structure itself.

Internal structures

The first character is the underscore which means 'tag', and the other characters are lower-case chracters or underscores. For example,

struct _mem_debug {
	...;
};

External definitions

This rule is applied to external macros or enumeration constants. Upper-case characters and underscores are used, but the first character is not the underscore. For example,

#define IO_END 0

Internal definitions

This rule is applied to internal macros or enumeration constants. Upper-case characters and underscores are used, and the first character is the underscore. For example,

#define _IO_DEFAULT_BUFFER 512

External functions

Started with lower-case characters which represent the function category, and the other characters are camel-case characters without underscore. For example,

int ioReadHierarchy( struct _IOContext* io, char** excl, int nexcl, char** current_key );

Internal functions

With lower-case charcters and underscores, i.e.,

void* mem_alloc( long size );

Local variables

With lower-case characters and underscores, simple and short if possible. For example,

int i, count /* or cnt */; /* an index and counter */
void* context /* or ctx */; /* a context */

Global variables

With lower-case characters and underscores, names should be clearly understood. It is preferable to use the category name as a prefix. For example,

int dl_init_count; /* initializer counter for dynamic loader function */

Formatting Source Files

Indentation

Tabs are 4 characters.

Blocks

I follow the K&R style for blocks.

Function name on its body

GNU style is used for this case, i.e.

void
iotextRead

So the regular expression '^iotextRead' will move cursor to the place where the function is implemented.

Definitions for compatibility

To maintain source compatibility, some macros are defined in coral/compat.h and major definitions are introduced here. I use these definitions in my libraries that maximum source compatibility is needed.

Far and huge pointers

Far and huge pointers are obsolete features in 16 bits platforms but I maintain portabilities for them.
__F, far keyword
__H, huge keyword

For example,

char __F* p; /* far pointer */
char __H*__F* ph; /* far pointer of a huge pointer */

Defining a function

To split the source codes into several parts using a proper utility, I use __MODULEBEGIN__( "srcname" ) __MODULEEND__ macros. To jump to the position where the function is defined by finding '* function_name' in an editor, I use the comment which contains the function name.

__MODULEBEGIN__( "mresize.c" )
/* memResize */

__MODULEEND__

Function Calling Convention

To use standard calling conventions for each platforms, __API macro is defined. For example,

void __API
doSomething

Function parameters

I support both K&R and standard function definitions using some macros. For example,


void __F* __API memResize P_A(( void __F* p, long size ));

void __F* __API
memResize
	P_B(( p, size ))
	P_1		void __F* p
	P_N		long size
	P_E
{
	...;
}

Previous | Gate | Korean