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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
= File & directory content
* gsecuredelete/
Contains the source code of the library.
* utils.vala:
Gneral use utilities.
* async-operation.vala:
The base class for manage (swpawn and watch) the subptocesses.
* securedelete-operation.vala:
Base class for all operations. It is a subclass of AsyncOperation and
it implements all generic stuff for all S* oeprations.
* zeroable-operation.vala:
A superclass of SecureDeleteOperation that implements the -z option
that is common for almost all S* operation but not all.
* delete-operation.vala:
Implements the wrapper for `srm`
* fill-operation.vala:
Implements the wrapper for `sfill`
* mem-operation.vala:
Implements the wrapper for `smem`
* swap-operation.vala:
Implements the wrapper for `sswap`
* main.vala:
A test application for the operations. It is not actual part of the
library.
* gsd-sfill-helper.sh.in:
A wrapper script for `sfill` for it to support file size limits and
possibly run the operation as root.
= Coding style
The code follows something like K&R style, but watch the code and see!
== Brackets
The brackets are in the same line as the conditional branching, errordomain,
properties, locks and so, but in the very next line after function and method
definitions, namespaces, and classes.
== Blank lines
Every blank line must be *indented*.
Outside functions, every "block" is separated by one blank line. It means
between functions, methods, properties, etc.
Inside functions, there is generally 2 blank lines: one right after the variable
declarations, and one right before the ending return statement. You may also add
blank lines inside functions if the function is quite long, but you may not need
it often.
== Commentaries
You must add a documentation for every public function, method, class.. and at
least a short commentary explaining what it does for the private and protected
ones. The documentation and the short commentary is placed on the very top of
the definition.
You may add few commentaries inside functions, methods, etc. when the code is
not clear or if it is a very important detail, but you MUST NOT abuse of these
kind of commentaries. Too much commentaries kills the commentary: it makes the
code itself very hard to follow, then the code's self-explaining is hidden; and
code is more likely the same through programmers than the commentaries, then
it is more easily read in many cases.
You may place a commentary in the line just before what it documents, or, in
case of very short comments, at the en of the line it documents.
=== FIXMEs and TODOs.
If you want to insert FIXME or TODOs, place it in simple comments and place the
"FIXME:" or "TODO:" (with the colon) keyword at the start. Of course, if the
comment contains more than one FIXME/TODO, you must place one of these keywords
before every ones in the comment.
|
