Elaborate coding guidelines in the HACKING file
This commit is contained in:
parent
38d0022ec8
commit
e2bb41b1f2
1 changed files with 50 additions and 3 deletions
53
HACKING
53
HACKING
|
@ -1,10 +1,57 @@
|
||||||
This file is licensed under the terms of the expat license, see the file EXPAT.
|
This file is licensed under the terms of the expat license, see the file EXPAT.
|
||||||
|
|
||||||
It is 4 spaces, no tabs, preferrably at 80 columns per line.
|
+++ Hacking guide for Midori +++
|
||||||
|
|
||||||
The preferred coding style is explained by example.
|
Indentation is 4 spaces, no tabs, preferrably at 80 to 120 columns per line to
|
||||||
|
avoid automated line-breaks. Trailing whitespace is not desirable.
|
||||||
|
|
||||||
Source file example:
|
Variable and function names should be animal, animal_shelter or animalsc in
|
||||||
|
case it would otherwise be very long. Loop counters may be single letters.
|
||||||
|
Type names should be Animal, AnimalShelter or AnimalSC.
|
||||||
|
|
||||||
|
There is a space between functions or keywords and round brackets, and curly
|
||||||
|
brackets always go on separate lines, at the indentation level of the
|
||||||
|
function, conditional or loop expression.
|
||||||
|
The type of a function goes on a separate line before the function.
|
||||||
|
Preprocessor instructions are indented with the code they relate to.
|
||||||
|
|
||||||
|
Code history is precious, so one should avoid renaming a lot of functions at
|
||||||
|
once or moving whole paragraphs only to add or remove a level of indentation.
|
||||||
|
Moving blocks of code around is also undesriable because it makes patches less
|
||||||
|
readable since the result looks like new code.
|
||||||
|
|
||||||
|
|
||||||
|
+++ Source files in the project +++
|
||||||
|
|
||||||
|
Core:
|
||||||
|
Files prefixed with "midori-" in the folder "midori" make up the core. They
|
||||||
|
are essential to running the browser and mostly tailored to the browser.
|
||||||
|
All header files prefixed with "midori-" are considered supported API and
|
||||||
|
can be used to implement extensions.
|
||||||
|
"sokoke" is a collection of very specialized helper functions which change
|
||||||
|
from time to time as needed. In the past some of the code was moved to
|
||||||
|
"katze" when it was considered generally useful.
|
||||||
|
"socket" is a socket implementation with no dependency on other parts of
|
||||||
|
the core, which is used if Midori is built without an external single
|
||||||
|
instance support library.
|
||||||
|
Panels:
|
||||||
|
Files in the "panels" folder are classes that implement MidoriViewable and
|
||||||
|
which are loaded into the MidoriPanel at startup. These panels are in
|
||||||
|
principle optional.
|
||||||
|
Katze:
|
||||||
|
Re-usable classes and utility functions that don't depend on the core and
|
||||||
|
some of that code indeed found its way into other projects.
|
||||||
|
Extensions:
|
||||||
|
These are extensions, written in C, which are loaded optionally if the user
|
||||||
|
so chooses. Extensions can use API from "midori-" and "katze-" headers. Each
|
||||||
|
module consists of either a single .c file or a folder with .c files.
|
||||||
|
Tests:
|
||||||
|
Unit tests are run regularly to verify possible regressions or measure
|
||||||
|
performance of implementations. Except for select cases code changes should
|
||||||
|
not cause failure of unit tests.
|
||||||
|
|
||||||
|
|
||||||
|
+++ Examplary source code +++
|
||||||
|
|
||||||
/*
|
/*
|
||||||
Copyright
|
Copyright
|
||||||
|
|
Loading…
Reference in a new issue