Fixing code formatting in README files.

arobenko · arobenko · commit 967a780fa7f9 · 2025-05-09T08:30:34.000+10:00
diff --git a/howtos/howto11/README.md b/howtos/howto11/README.md
@@ -6,7 +6,7 @@ the [tutorial27](../../tutorials/tutorial27) presented sub-protocols definition.
 to define variant fields from the [tutorial4](../../tutorials/tutorial4) as sub-protocol messages.
 
 The `KeyValueProp` `<variant>` field is replaced by the sub-protocol defined in the `var1` namespace.
-```
+```xml
 <ns name="var1">
     <fields>
         <enum name="PropKey" type="uint8" semanticType="messageId">
@@ -44,7 +44,7 @@ The frame is implemented as a pair of `<id>` and `<payload>` layers. Every prope
 separate `<message>` with a single **Val** field.
 
 Similarly the `TlvProp` `<variant>` field is replaced by the sub-protocol defined in the `var2` namespace.
-```
+```xml
 <ns name="var2">
     <fields>
         <enum name="PropKey" type="uint8" semanticType="messageId">
@@ -87,7 +87,7 @@ Similarly the `TlvProp` `<variant>` field is replaced by the sub-protocol define
 The frame in this case is implemented as `<id>`, `<size>` and `<payload>` triplet.
 
 The original protocol definition was moved into the `prot` namespace.
-```
+```xml
 <ns name="prot">
     <fields>
         <string name="Msg1Name" defaultValue="Message 1" />
@@ -127,7 +127,7 @@ decode the sub-protocol messages, it just echoes back raw data.
 
 The [client](ClientSession.cpp) on the other hand has to introduce some extra smarts. The
 original `Msg1` is defined having a count prefixed list of the `KeyValueProp` `<variant>` field.
-```
+```xml
 <message name="Msg1" id="MsgId.M1" displayName="^Msg1Name">
     <list name="F1" element="KeyValueProp">
         <countPrefix>
@@ -171,7 +171,7 @@ void ClientSession::handle(Msg2& msg)
 ```
 
 Another important aspect to notice is the way the protocol options are defined.
-```
+```cpp
 using ProtOpts =
     howto11::options::DataViewDefaultOptionsT<
         howto11::options::ClientDefaultOptions
diff --git a/tutorials/tutorial10/README.md b/tutorials/tutorial10/README.md
@@ -127,7 +127,7 @@ Note that passing multiple options are supported via bundling them in `std::tupl
 
 **SIDE NOTE**: All the options inside [include/&lt;namespace&gt;/options](include/tutorial10/options)
 folder are implemented to allow their combinations. For example:
-```
+```cpp
 using BareMetalServerOptions = 
     tutorial10::options::BareMetalDefaultOptionsT<
         tutorial10::options::ServerDefaultOptions
@@ -205,6 +205,7 @@ protected:
     {
         return comms::ErrorStatus::NotSupported;
     }
+};    
 ```
 In case `comms::option::app::NoWriteImpl` is passed to the 
 [comms::MessageBase](https://commschamp.github.io/comms_doc/classcomms_1_1MessageBase.html) when
diff --git a/tutorials/tutorial12/README.md b/tutorials/tutorial12/README.md
@@ -102,6 +102,11 @@ struct BareMetalDefaultOptionsT : public TBase
 };
 
 using BareMetalDefaultOptions = BareMetalDefaultOptionsT<>;
+
+} // namespace options
+
+} // namespace tutorial12
+
 ```
 As was explained earlier, the `comms::option::app::InPlaceAllocation` option passed to
 the `Id` framing layer results in placement rather than dynamic memory allocation.
diff --git a/tutorials/tutorial18/README.md b/tutorials/tutorial18/README.md
@@ -164,9 +164,11 @@ struct DataViewDefaultOptionsT : public TBase
     struct frame : public TBase::frame
     {
         struct FrameLayers : public TBase::frame::FrameLayers
+        {
             using Data = std::tuple<
                 comms::option::app::OrigDataView,
                 typename TBase::frame::FrameLayers::Data
+            >;
             
         }; // struct FrameLayers
     }; // struct frame
diff --git a/tutorials/tutorial2/README.md b/tutorials/tutorial2/README.md
@@ -280,7 +280,7 @@ public:
 
 Just by using these member functions it is possible to access the fields while
 providing the index of the field.
-```
+```cpp
 auto& msgFields = msg.fields();
 auto& f1 = std::get<0>(msgFields);
 auto& f2 = std::get<1>(msgFields);
@@ -653,7 +653,7 @@ on the right side of the assignment operation to appropriate type and assigns it
 to the value specified on the left side. It eliminates the necessity to explicitly specify
 cast type. To use the `comms::cast_assign()` function it is necessary to
 include [comms/cast.h](https://commschamp.github.io/comms_doc/cast_8h.html) header file.
-```
+```cpp
 #include "comms/cast.h"
 ```
 
diff --git a/tutorials/tutorial24/README.md b/tutorials/tutorial24/README.md
@@ -59,7 +59,7 @@ can be used for messages, not only fields.
 
 The generated [Msg1](include/tutorial24/message/Msg1.h) class uses **comms::option::def::FailOnInvalid** option in the
 message class definition.
-```
+```cpp
 template <typename TMsgBase, typename TOpt = tutorial24::options::DefaultOptions>
 class Msg1 : public
     comms::MessageBase<
diff --git a/tutorials/tutorial26/README.md b/tutorials/tutorial26/README.md
@@ -3,15 +3,15 @@ Stateful messages sequence.
 
 There are protocols that don't differentiate messages by their IDs. Instead, the sequence of the messages is pre-determined.
 In this particular tutorial (see [schema](dsl/schema.xml)) all the messages are the same, i.e. have the same ID and without any fields.
-```
+```xml
 <message name="Msg1" id="0" order="0" displayName="^Msg1Name" />
 <message name="Msg2" id="0" order="1" displayName="^Msg2Name" />
 <message name="Msg3" id="0" order="2" displayName="^Msg3Name" />
 ```
 Please note usage of the `nonUniqueMsgIdAllowed="true"` in the schema definition as well as **order** property for each `<message>`
 
 The frame is defined like this:
-```
+```xml
 <frame name="Frame">
     <size name="Size">
         <int name="SizeField" type="uint16" />
diff --git a/tutorials/tutorial27/README.md b/tutorials/tutorial27/README.md
@@ -3,7 +3,7 @@ Sub-protocols (using namespaces)
 
 Some protocols can be divided to two or more sub-protocols with usually different framing and different messages.
 It is recommended to use different namespaces (using `<ns>` XML node) in the schema definition (see [schema](dsl/schema.xml)).
-```
+```xml
 <ns name="sub1">
     ...
 </ns>
@@ -14,7 +14,7 @@ It is recommended to use different namespaces (using `<ns>` XML node) in the sch
 ```
 When using namespaces in the schema definition, the [CommsDSL Specification](https://commschamp.github.io/commsdsl_spec) requires
 full path when referencing fields or other components even if the referenced element resides in the same namespace:
-```
+```xml
 <message name="Msg1" id="sub1.MsgId.M0" order="0" displayName="^Msg1Name" />
 ...
 <message name="Msg4" id="sub2.MsgId.M4" displayName="^Msg4Name" />
