1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
Working in HOCR
-------------------
When writing HOCR our priorities are
1) Correctness.
2) Maintainable & Documented.
3) Modular and well designed.
When you submit code to me for inclusion in HOCR, or when you modify
the sources directly on the SVN repository, please keep those things in mind.
- Clarity of design and function are paramount
- Please follow the coding style used HOCR.
The HOCR coding style.
--------------------------
Use space for indentation, braces are
unindented and on a seperate line. Use indent utility.
(indent -bad -bap -bbb -bli0 -fca -i2 -l80 -nlp -psl -sc -sob -ss -ts2 -nut)
Use doxygen style documentation.
On top of that, you will have to:
- Follow the hocr namespace convention for function names.
hocr_submodule_operation
- Do not optimize unnecesarly. Do profile, do look for the
weak spots before applying "optimization by feeling".
- It is more important to keep the code maintainable and
readable than to be optimized. If you have a great idea about
optimizing the code, make sure it is implemented cleanly,
that there is a clean and maintainable way to do it.
- Optimized code that is difficult to maintain has no place in
HOCR and will be dropped.
All of this is to ensure the HOCR code will be kept within
reasonable margins of maintainability for the future: Remember, in two
years you will probably be far too busy to maintain your own
contributions, and they might become a burden to the program maintainers.
-----------------------
Cleaning code in HOCR is more important than trying not to break
existing code. By all means, code clean ups are always welcome.
|
