diff --git a/CODING b/CODING
index 74438e7c..d0673e7e 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 37c963ed..0afa733b 100644
--- a/doc/developer-guidelines.sgml
+++ b/doc/developer-guidelines.sgml
@@ -14,15 +14,8 @@
2013
Monitoring Plugins Development Guidelines
-
-
- 1796
- 2007-09-24 14:51:07 -0400 (Mon, 24 Sep 2007)
-
-
-
- 2000 - 2013
+ 2000 - 2024
Monitoring Plugins Development Team
@@ -34,7 +27,7 @@
the plugin developers and encourage the standardization of the
different kind of plugins: C, shell, perl, python, etc.
- Monitoring Plugins Development Guidelines Copyright (C) 2000-2013
+ Monitoring Plugins Development Guidelines Copyright (C) 2000-2024
(Monitoring Plugins Team)
Permission is granted to make and distribute verbatim
@@ -383,13 +376,6 @@
It is up to third party programs to convert the Monitoring Plugins
performance data into graphs.
-
- Translations
- If possible, use translation tools for all output to respect the user's language
- settings. See for guidelines
- for the core plugins.
-
-
System Commands and Auxiliary Files
@@ -727,19 +713,18 @@ setup the tests. Run "make test" to run all the tests.
Coding guidelines
See GNU
- Coding standards for general guidelines.
+ Coding standards for general guidelines.
+ Some parts of the guidelines (namely and explicitly the coding style)
+ are not seen as best practice by us.
C coding
- Variables should be declared at the beginning of code blocks and
- not inline because of portability with older compilers.
-
You should use the type "bool" and its values
"true" and "false" instead of the "int" type for booleans.
Crediting sources
- If you have copied a routine from another source, make sure the licence
+ 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.
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.
All commits will be written to a ChangeLog at release time.
-
- Translations for developers
- To make the job easier for translators, please follow these guidelines:
-
-
- Before creating new strings, check the po/monitoring-plugins.pot file to
- see if a similar string
- already exists
-
-
- For help texts, break into individual options so that these can be reused
- between plugins
-
- Try to avoid linefeeds unless you are working on a block of text
- Short help is not translated
- Long help has options in English language, but text translated
- "Copyright" kept in English
- Copyright holder names kept in original text
- Debugging output does not need to be translated
-
-
-
- Translations for translators
- To create an up to date list of translatable strings, run: tools/gen_locale.sh
-
-
Submission of new plugins and patches