From a98807f9ca34aed70c45ef15e598c724e92f73d3 Mon Sep 17 00:00:00 2001 From: Maciej Kaszynski Date: Thu, 20 Aug 2026 12:30:21 +0100 Subject: [PATCH 1/2] Adding inital coding guidelines doc --- coding_guidelines.md | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 coding_guidelines.md diff --git a/coding_guidelines.md b/coding_guidelines.md new file mode 100644 index 0000000000..5e67fd9c8f --- /dev/null +++ b/coding_guidelines.md @@ -0,0 +1,44 @@ + + +# Lifecycle Coding Guidelines + +## `Create` Method + +When a class can fail in the constructor create a static Create method that +returns a `Result`. + +## `auto` Usage + +Only use `auto` when it is obvious what the type will be. + +e.g. +```cpp +// Fine, make_shared says what it is. +auto something = std::make_shared(1); + +// Fine, It's understood that T::Create() creates a Result. +auto something = SomeType::Create(); + +// Not allowed, you'd have to look at the definition of the method to see what +// the type is. +auto something = someMethod(); +``` + +## No Yoda Conditions + +```cpp +if (42 == value){} // Bad + +if (value == 42){} // Good +``` From a41cabe37f98658b0f22faeae27cf2e4fa546e30 Mon Sep 17 00:00:00 2001 From: Maciej Kaszynski Date: Mon, 24 Aug 2026 09:23:32 +0100 Subject: [PATCH 2/2] Adding more details --- CONTRIBUTING.md | 182 +++++++++++++++++++++++++++++++++++++++++++ CONTRIBUTION.md | 48 ------------ coding_guidelines.md | 44 ----------- 3 files changed, 182 insertions(+), 92 deletions(-) create mode 100644 CONTRIBUTING.md delete mode 100644 CONTRIBUTION.md delete mode 100644 coding_guidelines.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000000..628b19fa59 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,182 @@ + + +# Eclipse Safe Open Vehicle Core (SCORE) + +The [Eclipse Safe Open Vehicle Core](https://projects.eclipse.org/projects/automotive.score) +project aims to develop an open-source core stack for Software Defined Vehicles +(SDVs), specifically targeting embedded high-performance Electronic Control +Units (ECUs). +Please check the [documentation](https://eclipse.dev/score/) for more +information. +The source code is hosted at [GitHub](https://github.com/eclipse-score). + +The communication mainly takes place via the +[`score-dev` mailing list](https://accounts.eclipse.org/mailing-list/score-dev) +and GitHub issues & pull requests (PR). +And we have a chatroom for community discussions here +[Eclipse SCORE chatroom](https://chat.eclipse.org/#/room/#automotive.score:matrix.eclipse.org). + +Please note that for the project the +[Eclipse Foundation’s Terms of Use](https://www.eclipse.org/legal/terms-of-use/) +apply. +In addition, you need to sign the [ECA](https://www.eclipse.org/legal/ECA.php) +and the [DCO](https://www.eclipse.org/legal/dco/) to contribute to the project. + +## Contributing + +### Getting the source code & building the project + +Please refer to the [README.md](README.md) for further information. + +### Getting involved + +#### Bug Fixes and Improvements + +Improvements are adding/changing processes and infrastructure, bug fixes can be +also on development work products like code. + +In case you want to fix a bug or contribute an improvement, please perform the +following steps: +1) Create a PR by using the corresponding template + ([Bugfix PR template](.github/PULL_REQUEST_TEMPLATE/bug_fix.md) or + [Improvement PR template](.github/PULL_REQUEST_TEMPLATE/improvement.md)). + Please mark your PR as draft until it's ready for review by the Committers + (see the [Eclipse Foundation Project Handbook](https://www.eclipse.org/projects/handbook/#contributing-committers) + for more information on the role definitions). + Improvements are requested by + the definition or modification of [Stakeholder Requirements](docs/stakeholder_requirements) + or [Tool Requirements](docs/tool_requirements) and may be implemented after + acceptance/merge of the request by a second Improvement PR. + The needed reviews are automatically triggered via the + [CODEOWNERS](.github/CODEOWNERS) file in the repository. +2) Initiate content review by opening a corresponding issue for the PR when it + is ready for review. + Review of the PR and final merge into the project repository is in + responsibility of the Committers. + Use the + [Bugfix Issue template](.github/ISSUE_TEMPLATE/bug_fix.md) or + [Improvement Issue template](.github/ISSUE_TEMPLATE/improvement.md) for this. + +Please check here for our Git Commit Rules in the +[Configuration_Tool_Guidelines](https://eclipse-score.github.io/score/process_description/guidelines/index.html). + +Please use the [Stakeholder and Tool Requirements Template](https://eclipse-score.github.io/score/process_description/templates/index.html) +when defining these requirements. + +![Contribution guide workflow](./docs/_assets/contribution_guide.svg "Contribution guide workflow") + +# Additional Information + +Please note, that all Git commit messages must adhere the rules described in +the [Eclipse Foundation Project +Handbook](https://www.eclipse.org/projects/handbook/#resources-commit). + +Please find process descriptions here: [process description](https://eclipse-score.github.io/score/process_description/). + +## Coding Guidelines + +### `Create` Method + +When a class can fail in the constructor create a static Create method that +returns a `Result`. + +### `auto` Usage + +Only use `auto` when it is obvious what the type will be. + +1. The full expression already specifies the type. + ```cpp + auto something = std::make_shared(1); + ``` +1. The right hand side of the assignment is a standard (ISO C++, POSIX, SCORE) + function. + ```cpp + // Fine, this is a std function so it's understood what the types are. + std::unordered_map data {}; + auto res = data.insert(...); + + // Fine, same as above + std::vector other_data {} + for(auto& val: other_data) + {...} + ``` +1. Creating a lambda function. +1. The type wraps another type, and is only used to check validity before + unwrapping to an object of another type. + ```cpp + auto something_res = SomeType::Create(); + if (!something_res) + {...} + SomeType something = something_res.value(); + ``` + +Not allowed: +```cpp +// Not allowed, you'd have to look at the definition of the method to see what +// the type is. +auto something = someMethod(); +``` + +### No Yoda Conditions + +https://en.wikipedia.org/wiki/Yoda_conditions#Criticism + +```cpp +if (42 == value){} // Bad + +if (value == 42){} // Good +``` + +### Namespaces + +For the namespace you shall use the following + +``` +score/ +├── health_monitor // namespace score::mw::health +│   └── src +│   └── cpp // Public API score::mw::health +│   └── details // Private API score::mw::health::internal:: +└── launch_manager // namespace score::mw::lifecycle + └── src + └── alive // Public API namespace score::mw::lifecycle + └── details // Private API namespace score::mw::lifecycle::internal:: +``` + +### Class Mocking + +The projects chosen method of mocking is dependency injection. +And so all classes shall be designed such that they allow injecting mocks +classes. + +### Bazel Visibility & Folder Structure + +The following rules shall be followed: + +1. Component directory (e.g. `osal`) can be visible to any target **inside** + the module. +1. The visiblity in the Component directory shall be as strict as + possible. +1. The `details` directory shall only be visible to the parent component. + +``` +score/launch_manager/src/daemon/src/ +└── osal <- visibility = ["//score:__subpackages__"], +    └── details <- visibility = ["//score/launch_manager/src/daemon/src/osal:__subpackages__"], +``` + +### File Naming Conventions + +* All mocks shall be called `mock_.hpp`. +* Headers with an interface shall have the `i` prefix. e.g. `icomponent.hpp` diff --git a/CONTRIBUTION.md b/CONTRIBUTION.md deleted file mode 100644 index 739aec3bbc..0000000000 --- a/CONTRIBUTION.md +++ /dev/null @@ -1,48 +0,0 @@ - - -# Eclipse Safe Open Vehicle Core (SCORE) -The [Eclipse Safe Open Vehicle Core](https://projects.eclipse.org/projects/automotive.score) project aims to develop an open-source core stack for Software Defined Vehicles (SDVs), specifically targeting embedded high-performance Electronic Control Units (ECUs). -Please check the [documentation](https://eclipse-score.github.io) for more information. -The source code is hosted at [GitHub](https://github.com/eclipse-score). - -The communication mainly takes place via the [`score-dev` mailing list](https://accounts.eclipse.org/mailing-list/score-dev) and GitHub issues & pull requests (PR). And we have a chatroom for community discussions here [Eclipse SCORE chatroom](https://chat.eclipse.org/#/room/#automotive.score:matrix.eclipse.org). - -Please note that for the project the [Eclipse Foundation’s Terms of Use](https://www.eclipse.org/legal/terms-of-use/) apply. -In addition, you need to sign the [ECA](https://www.eclipse.org/legal/ECA.php) and the [DCO](https://www.eclipse.org/legal/dco/) to contribute to the project. - -## Contributing -### Getting the source code & building the project -Please refer to the [README.md](README.md) for further information. - -### Getting involved - -#### Setup Phase -This phase is part of the eclipse Incubation Phase and shall establish all the processes needed for a safe development of functions. Only after this phase it will be possible to contribute code to the project. As the development in this project is driven by requirements, the processes and needed infrastructure incl. tooling will be established based on non-functional Stakeholder_Requirements. During setup phase the contributions are Bug Fixes and Improvements (both on processes and infrastructure). - -#### Bug Fixes and Improvements -Improvements are adding/changing processes and infrastructure, bug fixes can be also on development work products like code. -In case you want to fix a bug or contribute an improvement, please perform the following steps: -1) Create a PR by using the corresponding template ([Bugfix PR template](.github/PULL_REQUEST_TEMPLATE/bug_fix.md) or [Improvement PR template](.github/PULL_REQUEST_TEMPLATE/improvement.md)). Please mark your PR as draft until it's ready for review by the Committers (see the [Eclipse Foundation Project Handbook](https://www.eclipse.org/projects/handbook/#contributing-committers) for more information on the role definitions). Improvements are requested by the definition or modification of [Stakeholder Requirements](docs/stakeholder_requirements) or [Tool Requirements](docs/tool_requirements) and may be implemented after acceptance/merge of the request by a second Improvement PR. The needed reviews are automatically triggered via the [CODEOWNERS](.github/CODEOWNERS) file in the repository. -2) Initiate content review by opening a corresponding issue for the PR when it is ready for review. Review of the PR and final merge into the project repository is in responsibility of the Committers. Use the [Bugfix Issue template](.github/ISSUE_TEMPLATE/bug_fix.md) or [Improvement Issue template](.github/ISSUE_TEMPLATE/improvement.md) for this. - -Please check here for our Git Commit Rules in the [Configuration_Tool_Guidelines](https://eclipse-score.github.io/score/process_description/guidelines/index.html). - -Please use the [Stakeholder and Tool Requirements Template](https://eclipse-score.github.io/score/process_description/templates/index.html) when defining these requirements. - -![Contribution guide workflow](./docs/_assets/contribution_guide.svg "Contribution guide workflow") - -#### Additional Information -Please note, that all Git commit messages must adhere the rules described in the [Eclipse Foundation Project Handbook](https://www.eclipse.org/projects/handbook/#resources-commit). - -Please find process descriptions here: [process description](https://eclipse-score.github.io/score/process_description/). diff --git a/coding_guidelines.md b/coding_guidelines.md deleted file mode 100644 index 5e67fd9c8f..0000000000 --- a/coding_guidelines.md +++ /dev/null @@ -1,44 +0,0 @@ - - -# Lifecycle Coding Guidelines - -## `Create` Method - -When a class can fail in the constructor create a static Create method that -returns a `Result`. - -## `auto` Usage - -Only use `auto` when it is obvious what the type will be. - -e.g. -```cpp -// Fine, make_shared says what it is. -auto something = std::make_shared(1); - -// Fine, It's understood that T::Create() creates a Result. -auto something = SomeType::Create(); - -// Not allowed, you'd have to look at the definition of the method to see what -// the type is. -auto something = someMethod(); -``` - -## No Yoda Conditions - -```cpp -if (42 == value){} // Bad - -if (value == 42){} // Good -```