Inconsistent format in the specification

[jdacoello]

Currently, there is no tool/script checking the correctness of the formats included in the specification files. For example: trilling spaces, letter capitalisation, blank spaces, indentation, quotation mark style, etc.

What about including a Lint step to check the YAML before merging a PR? The yamllint or similar libraries could do the job.

[erikbosch]

A pull request would be appreciated :-)

There might be some minor challenges in that we do not use "pure" yaml, like we use the *.vspec suffix and our own #include syntax, so currently it complains on every #include it seems. One also needs to discuss what line length limit we would like to use - if we should use 80 or something else.

If we would introduce it I would recommend the same approach as we have used for linters and checkers in vss-tools:

• First add it to CI, but let it always pass even if errors/warnings are reported
• Then start discussing rules/configuration, change rules as needed or fix the reported problems.
• When no errors exist we could make it mandatory that no errors are reported.

[jdacoello]

@erikbosch , what does CI stand for in your reply? I am not familiar with that term

[erikbosch]

Continuous Integration, i.e. the actions triggered by https://github.com/COVESA/vehicle_signal_specification/blob/master/.github/workflows/buildcheck.yml for each pull request. There one could have an entry for yamllint similar to what we have for mypy for vss-tools in https://github.com/COVESA/vss-tools/blob/master/.github/workflows/buildcheck.yml#L62