To ensure that the Enlightenment Project's code base is as approachable as possible all contributors are asked to adhere to the following conventions on style and layout. All contributed code should adhere to the following guidelines; those new to the Enlightenment Project and looking to contribute their first patches are advised to spend some time reading through the existing code first to get a further feel for the style and layout.
When modifying or extending existing code, always maintain the existing coding style - even where the existing coding style goes against the conventions outlined in this document. If unsure, send different or sequential patches. If contributing new code, keep to the coding style of its immediate surroundings.
When writing code, adhere to the following:
if
, for
, while
, do
, switch
, case
and so forth.case
- This comes after the switch
brace.if
, for
, while
and switch
.sizeof()
.if (cond) action
are fine as single linelike_this
, as an example.typedef
ed with capitalization separated by an underline - typedef struct _Like_This Like_This
, as an example.{module}_{object}_{specializations}_{action}
. For example evas_object_color_get()
makes it clear that you're getting the color of an object from the evas
module.evas_object_color_get()
, not evas_object_get_color()
.static
when local to the file and EAPI
when publicly exported. Non marked symbols tend to be exported exclusively to the containing module by means of the linker -fvisibility=hidden
.const
- This applies to getters or when it should not be modified, in both arguments and the return.o
for object, x/y/w/h
for geometry, r/g/b/a
for colors and so forth.+
, -
, /
and *
.evas_object_color_set(obj, 255, 255, 255, 255)
.Short statements can be in single line, which is good for error checking purposes:
if (!p) return;
if (!p) return -EINVAL;
Longer statements with a single operation are in separated lines without braces:
if (!module_object_initialized())
module_object_initialize();
Multiple statements are in separate lines with braces, and note the indentation change:
if (!module_object_initialized())
{
module_object_initialize();
EINA_LOG_DBG("module was initialized");
}
Place the smallest branch first to assist with reading the code:
if (cond < 0)
do_something_about_it_long();
else
{
int i;
for (i = 0; i < cond; i++)
call_cond(i);
}
if (cond < 0) handle_negative();
else
{
int i;
for (i = 0; i < cond; i++)
call_cond(i);
}
Add parentheses around multi-variable conditions:
if ((a - b) < ((b / a) + c))...
Avoid parentheses around single-variable conditions:
if (!a && b)...
Use common sense when following these rules; the following is obviously not acceptable:
if (a - 1 * 3 / 18 | 2 < v % 3 * 6 && x == 2 - z)....
Other statements are handled similarly to If Statements, as per the following example:
while (lst) lst = eina_list_remove_list(lst, lst);
while ((lst != lst_last) && (lst != lookup))
lst = lst_find_something(lst);
for (i = 0; ((i < 10) && (i * 10 < something()); i++)
{
if (i % 2) proc_even(i);
else proc_odd(i)
}
do
{
process_fds();
process_timers();
process_idlers();
}
while (run);
switch (action)
{
case ACTION_NEW: return _new();
case ACTION_DEL:
{
free(xyz);
return NULL;
}
};
Structures should be handled as per the following example:
typedef struct _My_Class My_Class;
struct _My_Class
{
void *base;
unsigned int references;
};
Forward declarations in functions should be avoided where possible, while the style should follow this example:
static void my_class_ref(My_Class *cls);
static void
my_class_ref(My_Class *cls)
{
if (!cls) return;
cls->references++;
}
Always use parentheses to indicate the order of operation, even where operator precedence seems obvious.
a = (b * c) / d;
a = b * (c / d);
a = (b * c) + d;
a = (b / c) - d;
a = ((b * c) + d) / e;
a = (b & 0xf) << 8;
a = (b << 8) & 0xf0;
a = (b | c) ^ d;
a = ((b & c) | d) & 0x00ff00;