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
69
70
71
|
# Style Guide
Plaso follows the [log2timeline style guide](https://github.com/log2timeline/l2tdocs/blob/master/process/Style-guide.md).
## Plaso specific style points
### Event data attribute containers
#### Data types
Every event data attribute container defines a data type (DATA_TYPE).
Conventions for the data type names are:
1) If the data type is operating system (or operating system convension such as
POSIX) specific start with the name of operating system or convention.
Currently supported prefixes:
* android
* chromeos
* ios
* linux
* macos
* windows
Otherwise skip the operating system prefix.
2) Next is the name of the application, sub system or data format for example
'chrome', 'windows:registry' or 'windows:evtx'.
TODO: describe which one is preferred and why.
3) What follows are application, sub system or data format specific type
information for example 'windows:evtx:record'.
#### Value types
Values stored in an event data attribute container must be of certain types
otherwise event filtering or output formatting can break. Supported Python types
are:
* bool (also see note below)
* int
* str
A list, of the types previously mentioned types, are supported. **Do not use
dict or binary strings.**
Use a bool sparsely. For now it is preferred to preserve the original type.
For example if -1 represents False and 0 True, store the value as an integer
not as a bool. The message formatter can represent the numeric value as a
human readable string.
### Tests
* Use the test functions available in the local test_lib.py as much as possible
nstead of writing your own test functions. If you think a test function is
missing please add it, or mail the developer list to see if you can get someone
else to do it.
* Use `self.CheckTimestamp` for testing timestamp values.
Common test code should be stored in "test library" files, for example. the parser test
library is `tests/parsers/test_lib.py`.
We do this for a few reasons:
* to remove code duplication in "boiler plate" test code;
* to make the tests more uniform in both look-and-feel but also what is tested;
* improve test coverage;
* isolate core functionality from tests to prevent some future core changes
affecting the parsers and plugins too much.
|
