Make your own free website on

EuOS Coding Guidelines

By Jeffrey Fielding

August 24, 1999

I am writing these guidelines to maintain EuOS's elegance, stability, and security. Also, I'll try to design these guidelines to encourage modular code which can be re-used easily, and decrease development time.

If anyone has anything to add to this document, send it to me and I'll put it in.

Naming routines, variables, and constants

Euphoria's naming system can be very useful or very frustrating, depending on how it is used. I think the current system is very elegant as long as it is used properly.

All the routines in a program should be non-global so they don't conflict with other programs. They definitely shouldn't conflict with the global names used by the kernel. To guarantee that programs don't conflict with the kernel, make the first letter of each non-constant name capital, and constants shouldn't start with a capital. You can probably get away with a different naming scheme, since it is unlikely that you will pick the same name as a global kernel function.

But names in programs are up to the programmer. In EuOS, however, all the names should have the same format. This makes development of the OS and programs to go with it much easier, and makes the code more elegant.

All variables and routine names start with a lower case word, and any additional words follow with the first letter in uppercase, and the rest in lowercase. For example: addProgram or getTaskData. All constants are completely uppercase, with words separated by an underscore (_). For example, DRIVER or HIGH_STABILITY.

Handling Errors

All simple, recoverable errors should be announced using the generateError routine so that programs can check for errors. The routine should also return, with an error code if possible, or a default value. You should try to make it return an acceptable value that won't cause the program to crash. See how get() works - it returns an error code and a value, so programs can check the error code but won't crash if they don't.

Fatal errors should terminate the program using generateFatalError. Programs should make calls to external routines in separate routines as much as possible.

Type checking should be used internally, but routines that receive values from external programs should accept objects. This way, the system won't crash on a type check error caused by a program. Then check the type later, and generate a fatal error if it is incorrect.