File: HACKING

package info (click to toggle)
hocr 0.10.18-3
  • links: PTS, VCS
  • area: main
  • in suites: buster, sid
  • size: 3,296 kB
  • sloc: ansic: 18,153; sh: 11,473; python: 1,422; makefile: 190; cpp: 19
file content (49 lines) | stat: -rw-r--r-- 1,697 bytes parent folder | download | duplicates (3)
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.