Best practices added + coding guidelines moved

develop/best_practices/Best_practices.md

@@ -8,3 +8,9 @@ In this section:
 
 - [Unit testing](xref:Unit_testing)
 - [XML documentation comments](xref:Xml_Documentation_Comments)
+
+> [!TIP]
+> See also:
+>
+> - [Best practices for protocol development](xref:CodingGuidelines)
+> - [Best practices for Automation script development](xref:Automation_best_practices)

develop/codingguidelines/CodingGuidelines.md

@@ -2,28 +2,13 @@
 uid: CodingGuidelines
 ---
 
-# DataMiner Protocol Development Guidelines
+# Best practices for protocol development
 
-The guidelines specified in this section are designed to uphold the level of quality of DMS protocols by improving readability, maintainability, and performance.
+This section lists best practices and guidelines designed to uphold the quality level of DataMiner protocols (a.k.a. connectors) by improving readability, maintainability, and performance.
 
-By adhering to these guidelines, we can ensure that protocols have a consistent look, and thereby increase maintainability and readability. The guidelines also increase reusability, stability and performance.
+By adhering to these best practices and guidelines, you can ensure that protocols have a consistent look and thereby increase maintainability and readability, and you will also increase the reusability, stability, and performance of the protocols you develop.
 
-When a new protocol version is created, you must verify every item in the protocol development checklist and specify "OK", "Fail" or "NA" every time.
+A checklist is available [on DataMiner Dojo](https://community.dataminer.services/protocol-development-downloads/), which should be used whenever a new protocol version is created. In the checklist, verify every item and specify "OK", "Fail", or "NA", as appropriate.
 
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (see <https://www.ietf.org/rfc/rfc2119.txt>).
-
-In this section:
-
-- [General](xref:CODGeneral#general)
-
-- [Administrative metadata](xref:CODAdminMetadata#administrative-metadata)
-
-- [User interface](xref:CODUserInterface#user-interface)
-
-- [Monitoring](xref:CODMonitoring#monitoring)
-
-- [Protocol](xref:CODProtocol#protocol)
-
-- [Validation](xref:CODValidation#validation)
-
-- [Points of attention](xref:CODAttention#points-of-attention)
+> [!NOTE]
+> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this section are to be interpreted as described in RFC 2119 (see <https://www.ietf.org/rfc/rfc2119.txt>).

develop/codingguidelines/Protocol/Saving_parameters.md

@@ -4,4 +4,14 @@ uid: Saving_parameters
 
 # Saving parameters
 
-- Parameters must only be saved when necessary. When a parameter is saved, it is saved in the database, leading to additional processing and memory usage.
+To make sure your on-premises databases remain in good shape and do not get cluttered with unnecessary data, or to ensure a cost-efficient solution in case you make use of Storage as a Service, it is important to avoid storing unnecessary data. As a consequence, parameters must only be saved when this is really necessary.
+
+Here are some things you can do to make sure no more data is saved than necessary:
+
+- Only add a [save](xref:Protocol.Params.Param-save) attribute to a parameter if it is really necessary.
+
+- If you know a parameter will change frequently, but it definitely needs to be saved, specify a [saveInterval](xref:Protocol.Params.Param-saveInterval) attribute.
+
+- By default, the keys of a table are saved. Avoid fully cleaning and repopulating a table when updating values.
+
+- Consider using a [volatile table](xref:AdvancedDataMinerDataPersistencePersistingTables#volatile-tables). Table that do not contain any monitored parameters could be a good fit for this.

develop/codingguidelines/Protocol/StyleCop.md

@@ -4,8 +4,7 @@ uid: StyleCop
 
 # StyleCop
 
-- StyleCop does not indicate any warnings. For an overview of the StyleCop rules that need to be adhered to, refer to [C code conventions](xref:C_code_conventions).
+- StyleCop does not indicate any warnings. For an overview of the StyleCop rules that need to be adhered to, refer to [C code conventions](xref:General_COD).
 
 > [!TIP]
-> See also:
-> <https://github.com/Visual-Stylecop/Visual-StyleCop/wiki>
+> See also: <https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/DOCUMENTATION.md>

develop/codingguidelines/UserInterface/Displayed_text.md

@@ -4,7 +4,7 @@ uid: Displayed_text
 
 # Displayed text
 
-- All displayed textual items, e.g. parameter descriptions, button values, discrete values, tooltips, element wizard text etc. that will be displayed in DataMiner must be user-friendly and adhere to the following rules.
+All displayed textual items, e.g. parameter descriptions, button values, discrete values, tooltips, element wizard text, etc. that will be displayed in DataMiner must be user-friendly and adhere to the following rules:
 
 - [Title case](xref:Title_case)