Skip to content

Commit 63ef7a1

Browse files
Nader ThomasThomasNaderBMW
authored andcommitted
Fullfilled a rebase with sign off.
Signed-off-by: Nader Thomas <a442105@europe.bmw.corp>
1 parent 1637dd7 commit 63ef7a1

File tree

2 files changed

+165
-0
lines changed

2 files changed

+165
-0
lines changed

doc/interfaceconventions.rst.orig

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -42,10 +42,14 @@ All messages that are intended to be exchanged as a stand-alone message, i.e. no
4242
Field Message Naming
4343
---------------------
4444
<<<<<<< HEAD
45+
<<<<<<< HEAD
4546
After defining a message fields can be added to it in snake_case format. This means every letter is lower case and the words are connected through an underline character. See example below:
4647
=======
4748
After defining a message fields can be added to it in snake case format. This means every letter is lower case and the words are connected through an underline character. See example below:
4849
>>>>>>> Documentation/interface convention (#380)
50+
=======
51+
After defining a message fields can be added to it in snake_case format. This means every letter is lower case and the words are connected through an underline character. See example below:
52+
>>>>>>> Fullfilled a rebase with sign off.
4953

5054
.. code-block:: protobuf
5155

@@ -64,10 +68,14 @@ All field numbers of 10000 and above are reserved for user-defined extensions an
6468
Enum Naming
6569
------------
6670
<<<<<<< HEAD
71+
<<<<<<< HEAD
6772
The naming of an enum should be PascalCase. See example below:
6873
=======
6974
The naming of an enum should be camel case. See example below:
7075
>>>>>>> Documentation/interface convention (#380)
76+
=======
77+
The naming of an enum should be PascalCase. See example below:
78+
>>>>>>> Fullfilled a rebase with sign off.
7179

7280
.. code-block:: protobuf
7381

@@ -83,10 +91,14 @@ The naming of an enum should be camel case. See example below:
8391
Enum Field Naming
8492
------------
8593
<<<<<<< HEAD
94+
<<<<<<< HEAD
8695
The naming of an enum field should be all in upper case. The start should be converted from the enum name PascalCase to UPPER_CASE_SNAKE_CASE. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
8796
=======
8897
The naming of an enum field should be all in upper case. The start should be converted from the enum name camel case to upper case snake case. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
8998
>>>>>>> Documentation/interface convention (#380)
99+
=======
100+
The naming of an enum field should be all in upper case. The start should be converted from the enum name PascalCase to UPPER_CASE_SNAKE_CASE. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
101+
>>>>>>> Fullfilled a rebase with sign off.
90102

91103
.. code-block:: protobuf
92104

@@ -109,13 +121,17 @@ Summary
109121
Here a small summary for the naming conventions:
110122

111123
<<<<<<< HEAD
124+
<<<<<<< HEAD
125+
=======
126+
>>>>>>> Fullfilled a rebase with sign off.
112127
Messages: PascalCase
113128

114129
Message Fields: snake_case
115130

116131
Enum: PascalCase
117132

118133
Enum Fields: Name of enum converted in UPPER_CASE_SNAKE_CASE and then following the specified name
134+
<<<<<<< HEAD
119135
=======
120136
Messages: camel case
121137

@@ -125,5 +141,7 @@ Enum: camel case
125141

126142
Enum Fields: upper case, name of enum converted in upper case snake case and then following the specified name
127143
>>>>>>> Documentation/interface convention (#380)
144+
=======
145+
>>>>>>> Fullfilled a rebase with sign off.
128146

129147
After defining the messages do not forget to comment them. See also the `section for commenting <https://opensimulationinterface.github.io/osi-documentation/open-simulation-interface/doc/commenting.html>`_ of fields and messages.
Lines changed: 147 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,147 @@
1+
.. _iconventions:
2+
3+
Interface Conventions
4+
======================
5+
6+
When adding new messages, enums, field messages and field enums to OSI we enforce a few naming conventions for each type like in the `style guide <https://developers.google.com/protocol-buffers/docs/style>`_ from protobuf.
7+
8+
Message Naming
9+
---------------
10+
<<<<<<< HEAD
11+
A message definition should always be in PascalCase. This means that the first letter of each word in a message should be upper case without any spaces. See example below:
12+
=======
13+
A message definition should always be in camel case. This means that the first letter of each word in a message should be upper case without any spaces. See example below:
14+
>>>>>>> Documentation/interface convention (#380)
15+
16+
.. code-block:: protobuf
17+
18+
message EnvironmentalConditions
19+
{
20+
}
21+
22+
Top-Level Messages
23+
-------------------
24+
All messages that are intended to be exchanged as a stand-alone message, i.e. not required to be embedded in another message, like e.g. ``SensorView`` or ``SensorViewConfiguration``, are required to carry an ``InterfaceVersion`` field as their first field, and a ``Timestamp`` field as their second field, e.g.:
25+
26+
.. code-block:: protobuf
27+
28+
message TopLevel
29+
{
30+
// The interface version used by the sender (simulation environment).
31+
//
32+
optional InterfaceVersion version = 1;
33+
34+
// The data timestamp of the simulation environment. Zero time is arbitrary
35+
// but must be identical for all messages. Zero time does not need to
36+
// coincide with the UNIX epoch. Recommended is the starting time point of
37+
// the simulation.
38+
//
39+
optional Timestamp timestamp = 2;
40+
}
41+
42+
Field Message Naming
43+
---------------------
44+
<<<<<<< HEAD
45+
<<<<<<< HEAD
46+
After defining a message fields can be added to it in snake_case format. This means every letter is lower case and the words are connected through an underline character. See example below:
47+
=======
48+
After defining a message fields can be added to it in snake case format. This means every letter is lower case and the words are connected through an underline character. See example below:
49+
>>>>>>> Documentation/interface convention (#380)
50+
=======
51+
After defining a message fields can be added to it in snake_case format. This means every letter is lower case and the words are connected through an underline character. See example below:
52+
>>>>>>> Fullfilled a rebase with sign off.
53+
54+
.. code-block:: protobuf
55+
56+
message EnvironmentalConditions
57+
{
58+
optional double atmospheric_pressure = 1;
59+
}
60+
61+
Field Numbering
62+
----------------
63+
64+
Fields should be numbered consecutively starting from 1 on first definition. During maintenance, the rules of backward/forward-compatibility require that fields are never renumbered, and field numbers never re-used unless a major release is performed.
65+
66+
All field numbers of 10000 and above are reserved for user-defined extensions and will thus never be used by OSI message fields.
67+
68+
Enum Naming
69+
------------
70+
<<<<<<< HEAD
71+
<<<<<<< HEAD
72+
The naming of an enum should be PascalCase. See example below:
73+
=======
74+
The naming of an enum should be camel case. See example below:
75+
>>>>>>> Documentation/interface convention (#380)
76+
=======
77+
The naming of an enum should be PascalCase. See example below:
78+
>>>>>>> Fullfilled a rebase with sign off.
79+
80+
.. code-block:: protobuf
81+
82+
message EnvironmentalConditions
83+
{
84+
optional double atmospheric_pressure = 1;
85+
86+
enum AmbientIllumination
87+
{
88+
}
89+
}
90+
91+
Enum Field Naming
92+
------------
93+
<<<<<<< HEAD
94+
<<<<<<< HEAD
95+
The naming of an enum field should be all in upper case. The start should be converted from the enum name PascalCase to UPPER_CASE_SNAKE_CASE. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
96+
=======
97+
The naming of an enum field should be all in upper case. The start should be converted from the enum name camel case to upper case snake case. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
98+
>>>>>>> Documentation/interface convention (#380)
99+
=======
100+
The naming of an enum field should be all in upper case. The start should be converted from the enum name PascalCase to UPPER_CASE_SNAKE_CASE. It is mandatory to add to the first enum field name the postfix ``_UNKNOWN`` and to the second the postfix ``_OTHER``. After that the naming can be decided by the user. It is often mentioned that the value ``_UNKNOWN`` should not be used in a ``GroundTruth`` message as there are now uncertanties by definition in ``the truth``. These values are mostly used in messages like ``SensorData`` where the content is subject to interpretation. See example below:
101+
>>>>>>> Fullfilled a rebase with sign off.
102+
103+
.. code-block:: protobuf
104+
105+
message EnvironmentalConditions
106+
{
107+
optional double atmospheric_pressure = 1;
108+
109+
enum AmbientIllumination
110+
{
111+
AMBIENT_ILLUMINATION_UNKNOWN = 0;
112+
113+
AMBIENT_ILLUMINATION_OTHER = 1;
114+
115+
AMBIENT_ILLUMINATION_LEVEL1 = 2;
116+
}
117+
}
118+
119+
Summary
120+
--------
121+
Here a small summary for the naming conventions:
122+
123+
<<<<<<< HEAD
124+
<<<<<<< HEAD
125+
=======
126+
>>>>>>> Fullfilled a rebase with sign off.
127+
Messages: PascalCase
128+
129+
Message Fields: snake_case
130+
131+
Enum: PascalCase
132+
133+
Enum Fields: Name of enum converted in UPPER_CASE_SNAKE_CASE and then following the specified name
134+
<<<<<<< HEAD
135+
=======
136+
Messages: camel case
137+
138+
Message Fields: snake case
139+
140+
Enum: camel case
141+
142+
Enum Fields: upper case, name of enum converted in upper case snake case and then following the specified name
143+
>>>>>>> Documentation/interface convention (#380)
144+
=======
145+
>>>>>>> Fullfilled a rebase with sign off.
146+
147+
After defining the messages do not forget to comment them. See also the `section for commenting <https://opensimulationinterface.github.io/osi-documentation/open-simulation-interface/doc/commenting.html>`_ of fields and messages.

0 commit comments

Comments
 (0)