... | ... | @@ -83,6 +83,10 @@ Such a function must contain the description of the returned values. Otherwise, |
|
|
|
|
|
All public typescript functions and classes MUST be documented. Private functions MUST be documented when they have non-trivial implementation. The developers should follow the [TSDoc](https://tsdoc.org) style for documenting the code.
|
|
|
|
|
|
### Python
|
|
|
|
|
|
We use Python for system tests. Python-specific coding guidelines are currently TBD.
|
|
|
|
|
|
## User's guide
|
|
|
|
|
|
The [Stork ARM](https://stork.readthedocs.io/en/latest/) SHOULD be updated when a new feature is added. Again, the description doesn't have to be complex or extensive. A paragraph of text briefly announcing new feature or capability will help users (and other developers) a lot.
|
... | ... | @@ -237,6 +241,10 @@ Stork build system provides the `rake fmt:ui` command to format the Typescript c |
|
|
|
|
|
Developers should avoid using the `any` type because it disables type checking and may lead to errors. Whenever possible, explicit types should be used instead. In some cases, using `any` (e.g., in the unit tests) can be practical to avoid defining new types just for mocking a response. In the production code, the use of `any` SHOULD be avoided.
|
|
|
|
|
|
# Python Style
|
|
|
|
|
|
We use Python for system tests. Python-specific coding guidelines are currently TBD.
|
|
|
|
|
|
# HTML & CSS Style
|
|
|
|
|
|
## Style vs Class
|
... | ... | |