2 files changed, 17 insertions, 71 deletions

diff --git a/CODING b/CODING
index 74438e7..d0673e7 100644
--- a/CODING
+++ b/CODING
@@ -7,33 +7,20 @@ readability in a wide range of environments.
 
 1. C Language Programming
 
-All code should comply with the requirements of the Free Software
+All code should comply with most of the requirements of the Free Software
 Foundation Coding standards (which are currently available at
-http://www.gnu.org/prep/standards_toc.html). We also follow most of
-the FSF guidelines. Developers may suggest deviations from the FSF
+https://www.gnu.org/prep/standards/standards.html ).
+We also follow most of the FSF guidelines, with the huge and explicit
+exception of the style guidelines.
+Developers may suggest deviations from the FSF
 style recommendations, which will be considered by open discussion on
-the Monitoring Plugins devel mailing list. Any such deviations will
-apply to the entire code base to ensure consistency.
-
-Currently, the exceptions to FSF recommendations are roughly equivalent
-to GNU indent with invoked as 'indent -ts 2 -br'. Specifically, the
-exceptions are as follows:
-
-a) leading white space for a statement should be formatted as tabs,
-with one tab for each code indentation level.
-
-b) in statement continuation lines, format whitespace up to the column
-starting the statement as tabs, format the rest as spaces (this
-results in code that is legible regardless of tab-width setting).
-
-c) with the exception of the above, tabs should generally be avoided
-
-d) when tab width is 2 spaces, line-length should not exceed 80
-characters
-
-e) The opening brace of an if or while block is on the same line as
-the end of the conditional expression (the '-br' option).
+the Monitoring Plugins devel mailing list or the Github Pull Request.
+Any such deviations should be
+applied to the entire code base to ensure consistency.
 
+The style guideline is the following:
+Whatever clang-format does with the configuration file available (.clang-format)
+Apart from that, code should naturally be readable and easy to understand.
 
 2. Perl Language Programming
 
diff --git a/doc/developer-guidelines.sgml b/doc/developer-guidelines.sgml
index 37c963e..0afa733 100644
--- a/doc/developer-guidelines.sgml
+++ b/doc/developer-guidelines.sgml
@@ -14,15 +14,8 @@
     <pubdate>2013</pubdate>
     <title>Monitoring Plugins Development Guidelines</title>
 
-    <revhistory>
-       <revision>
-          <revnumber>1796</revnumber>
-          <date>2007-09-24 14:51:07 -0400 (Mon, 24 Sep 2007)</date>
-       </revision>
-    </revhistory>
-
         <copyright>
-                <year>2000 - 2013</year>
+                <year>2000 - 2024</year>
                 <holder>Monitoring Plugins Development Team</holder>
         </copyright>
 
@@ -34,7 +27,7 @@
     the plugin developers and encourage the standardization of the
     different kind of plugins: C, shell, perl, python, etc.</para>
 
-        <para>Monitoring Plugins Development Guidelines Copyright (C) 2000-2013
+        <para>Monitoring Plugins Development Guidelines Copyright (C) 2000-2024
         (Monitoring Plugins Team)</para>
 
         <para>Permission is granted to make and distribute verbatim
@@ -383,13 +376,6 @@
                 <para>It is up to third party programs to convert the Monitoring Plugins
                 performance data into graphs.</para>
                 </section>
-
-        <section><title>Translations</title>
-        <para>If possible, use translation tools for all output to respect the user's language
-                settings. See <xref linkend="translationsdevelopers"> for guidelines
-                for the core plugins.
-        </para>
-        </section>
 </section>
 
 <section id="SysCmdAuxFiles"><title>System Commands and Auxiliary Files</title>
@@ -727,19 +713,18 @@ setup the tests. Run "make test" to run all the tests.
 </section>
 <section id="CodingGuidelines"><title>Coding guidelines</title>
         <para>See <ulink url="http://www.gnu.org/prep/standards_toc.html">GNU
-        Coding standards</ulink> for general guidelines.</para>
+        Coding standards</ulink> for general guidelines.
+        Some parts of the guidelines (namely and explicitly the coding style)
+        are not seen as best practice by us.</para>
         <section><title>C coding</title>
 
-        <para>Variables should be declared at the beginning of code blocks and
-        not inline because of portability with older compilers.</para>
-
         <para>You should use the type "bool" and its values
         "true" and "false" instead of the "int" type for booleans.
         </para>
         </section>
 
         <section><title>Crediting sources</title>
-        <para>If you have copied a routine from another source, make sure the licence
+        <para>If you have copied a routine from another source, make sure the license
         from your source allows this. Add a comment referencing the ACKNOWLEDGEMENTS
         file, where you can put more detail about the source.</para>
         <para>For contributed code, do not add any named credits in the source code
@@ -756,32 +741,6 @@ setup the tests. Run "make test" to run all the tests.
         <para>All commits will be written to a ChangeLog at release time.
         </para>
         </section>
-
-        <section id="translationsdevelopers"><title>Translations for developers</title>
-        <para>To make the job easier for translators, please follow these guidelines:</para>
-        <orderedlist>
-          <listitem><para>
-            Before creating new strings, check the po/monitoring-plugins.pot file to
-            see if a similar string
-            already exists
-          </para></listitem>
-          <listitem><para>
-            For help texts, break into individual options so that these can be reused
-            between plugins
-          </para></listitem>
-          <listitem><para>Try to avoid linefeeds unless you are working on a block of text</para></listitem>
-          <listitem><para>Short help is not translated</para></listitem>
-          <listitem><para>Long help has options in English language, but text translated</para></listitem>
-          <listitem><para>"Copyright" kept in English</para></listitem>
-          <listitem><para>Copyright holder names kept in original text</para></listitem>
-          <listitem><para>Debugging output does not need to be translated</para></listitem>
-        </orderedlist>
-        </section>
-
-        <section><title>Translations for translators</title>
-        <para>To create an up to date list of translatable strings, run: tools/gen_locale.sh</para>
-        </section>
-
 </section>
 
 <section id="SubmittingChanges"><title>Submission of new plugins and patches</title>