|
|
Screenshots Download FAQ Compatibility Changelog Current Plans Mailing List Conferences Donate
Icons Bug meter
View Entries Bug Insertion Volunteering
Documentation * Naming&Coding Source repository Dpi1 Spec CSS Spec Authors Security contact
Interview Entrevista ![]() Links Art
|
Dillo's code is divided into modules. For instance: bookmark, cache, dicache, gif. Let's think of a module named "menu", then:
For instance: if the function name is "Menu_create", then it's an internal function, but if we need to call it from the outside, then it should be renamed to "a_Menu_create". Why the "a_" prefix? Another way of understanding this is thinking of "a_" prefixed functions as Dillo's internal library, and the rest ("Menu_" prefixed in our example) as a private module-library.
Source code must be indented with 3 blank spaces, no
Tabs. You can use:
Every single function of the module should start with a short comment that explains its purpose; three lines should be enough, but if you think it requires more, enlarge it.
/*
* Try finding the url in the cache. If it hits, send contents
* from there. If it misses, set up a new connection.
*/
int a_Cache_open_url(const char *url, void *Data)
{
...
...
...
}
We also have the BUG:, TODO: and WORKAROUND: tags.Use them within source code comments to spot hidden issues. For instance: /* BUG: this counter is not accurate */ ++i; /* TODO: get color from the right place */ a = color; /* WORKAROUND: the canonical way of doing it doesn't work yet. */ ++a; ++a; ++a;
Let's try to keep functions within the 45 lines boundary. This eases code reading, following, understanding and maintenance.
It's much easier to follow and maintain functions with a single exit point at the bottom (instead of multiple returns). The exception to the rule are calls like dReturn_if_fail() at its head.
Naming&Coding design by Jorge Arellano Cid |