You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These guidelines are aspirations, and do not describe the system as it stands. The project has been written over a period of several years, and it is only quite recently I've decided to set out some guidelines.
54
+
55
+
In general, we try and follow the original texts: [PEP 8](https://peps.python.org/pep-0008/) and [clean code](https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29).
56
+
57
+
### General
58
+
59
+
- Unless there is a single parameter, parameters should be explicit.
60
+
- Type hints should be used, with Unions if required `from typing import Union`
61
+
62
+
63
+
### Naming conventions
64
+
65
+
- For classes, I prefer mixedCase to CamelCase, but single word names should always be Camels.
66
+
- Common methods are `get`, `calculate`, `read`, `write`.
67
+
- There is a specific procedure for naming objects which form part of the data heirarchy, see [here](https://github.com/robcarver17/pysystemtrade/blob/master/docs/data.md#part-2-overview-of-futures-data-in-pysystemtrade). If this is not followed, then the [automated abstraction of data inside Data 'blob' instances](https://github.com/robcarver17/pysystemtrade/blob/master/docs/data.md#data-blobs) won't work.
68
+
- Although arguably redundant, I am a fan of describing eg objects that inherit from dicts with a dict_ prefix. This gives hints as to how they behave without having to look at their code.
69
+
70
+
71
+
### Error handling
72
+
73
+
- Production code should not throw an error unless things are completely unrecoverable; if it does throw an error it must also log.critical which will email the user
74
+
75
+
76
+
### Caching
77
+
78
+
FIXME This is a bit of a mess - Update when a unified cache system setup
79
+
80
+
81
+
### Testing
82
+
83
+
Doc tests should be removed from class methods, since they often require a lot of setup, and make the code harder to read. Unit tests are preferable.
84
+
Doc tests make more sense for seperate, standalone, functions.
0 commit comments