2024-05-10, 23:17
Excuse me if this has been proposed before.
I assume that it is well known that when the Doxygen tags contain syntax errors, the resulting documentation can be malformed (I have been responsible for this on more than 1 occasion). I have noticed that this malformation usually manifests as Doxygen tags being visible in the final HTML code.
![Full sized picture Image](https://i.imgur.com/pFFCdWe.png)
I’d like to suggest that part of the PR pre-flight processes on GitHub includes building the documentation and then running a simple:
If the result is not equal to zero, then the documentation may need to be reviewed manually.
Something like this:
Can identify the HTML file name, but not the source code from which it originated.
I’m sure that malformed documentation can result from other Doxygen syntax errors and as they are discovered they could be added to the test.
I assume that it is well known that when the Doxygen tags contain syntax errors, the resulting documentation can be malformed (I have been responsible for this on more than 1 occasion). I have noticed that this malformation usually manifests as Doxygen tags being visible in the final HTML code.
![Full sized picture Image](https://i.imgur.com/pFFCdWe.png)
I’d like to suggest that part of the PR pre-flight processes on GitHub includes building the documentation and then running a simple:
Code:
grep -r -i "\\\table_row"|wc -l
If the result is not equal to zero, then the documentation may need to be reviewed manually.
Something like this:
Code:
grep -r -i "\\\table_row"|awk '{print $1}'
Can identify the HTML file name, but not the source code from which it originated.
I’m sure that malformed documentation can result from other Doxygen syntax errors and as they are discovered they could be added to the test.